How to Use Open-Source AI Models in n8n with the OpenAI Node

Learn how to use open-source AI models in n8n through the standard OpenAI Chat Model node by changing the API credentials and Base URL—without custom nodes or rebuilding your workflow.

Most people assume that using open-source AI models in n8n requires a custom node, a community integration, or a completely different workflow.

It often does not.

When an AI provider exposes an OpenAI-compatible API, you can usually keep using n8n’s standard OpenAI Chat Model node. Instead of rebuilding your automation, you change the API credentials and point the node to the provider’s Base URL.

Your workflow stays largely the same. The model running behind it changes.

This gives you a practical way to test lower-cost models, private deployments, specialist models, or open-weight alternatives without redesigning every AI workflow in n8n.

Why this works

The OpenAI Chat Model node communicates with an API using the OpenAI request and response format.

OpenAI is not the only company that supports that format. Many inference providers and model platforms expose endpoints designed to be compatible with OpenAI’s API structure.

That means n8n can send a familiar chat-completions request while the provider routes it to a different model.

The basic flow looks like this:

1. 1.
   n8n sends the prompt through the OpenAI Chat Model node.
2. 2.
   The node sends the request to the Base URL in your credential.
3. 3.
   The provider runs the selected model.
4. 4.
   The response returns in an OpenAI-compatible format.
5. 5.
   The rest of your n8n workflow continues normally.

You are not replacing n8n’s AI tooling. You are changing the model endpoint behind it.

What you need

Before setting this up, confirm that your provider gives you:

• An API key
• An OpenAI-compatible Base URL
• A supported model name or model ID
• Access to a chat-completions or responses-style endpoint supported by the n8n node

Providers may describe this differently. Look for terms such as:

• OpenAI-compatible API
• OpenAI SDK support
• Compatible chat-completions endpoint
• Drop-in OpenAI replacement
• Custom OpenAI Base URL

This method can work with hosted open-model platforms, GPU inference services, model gateways, and some self-hosted inference servers.

Examples may include platforms serving models from families such as Llama, Qwen, DeepSeek, Mistral, GLM, and other open or open-weight models.

The exact setup varies by provider, but the n8n side is usually similar.

Step 1: Add the OpenAI Chat Model node

Open the n8n workflow where you want to use the model.

Add the OpenAI Chat Model node and connect it to the AI Agent, chain, extractor, classifier, or other AI node in your workflow.

You do not need a provider-specific n8n node for this method.

Step 2: Create a new OpenAI credential

Inside the OpenAI Chat Model node, create a new credential.

Use a separate credential for each provider. This makes your workflows easier to maintain and prevents accidental changes to workflows that use the official OpenAI API.

Give the credential a clear name, such as:

• Open models — Provider A
• Qwen inference endpoint
• Self-hosted LLM gateway
• Low-cost model testing

Paste the API key supplied by the provider.

Step 3: Replace the Base URL

In the credential settings, find the Base URL field.

Replace the default OpenAI endpoint with the OpenAI-compatible endpoint supplied by your provider.

A provider may give you a URL shaped like this:

https://api.provider.example/v1

The actual URL will differ. Use the exact endpoint shown in the provider’s documentation.

Be careful with trailing paths. Some providers expect /v1 in the Base URL. Others include additional routing paths. A small mismatch can produce a 404 error even when your API key is correct.

Step 4: Select or enter the model ID

Return to the OpenAI Chat Model node and select the model.

If the model does not appear automatically, use the provider’s exact model identifier where n8n allows manual model entry.

Model IDs are often formatted like:

provider/model-name

or:

model-name-version

Do not assume the public model name is the API model ID. Copy the exact value from the provider’s documentation or model dashboard.

Step 5: Test with a simple prompt

Before connecting the model to a large production workflow, test it with a simple instruction.

For example:

Return the word READY and nothing else.

This helps isolate credential and endpoint issues before you test agents, tools, memory, structured output, or long prompts.

Once the basic request succeeds, test the features your real workflow depends on.

What to test before using it in production

OpenAI-compatible does not always mean feature-for-feature identical.

A provider may support basic chat completions but behave differently when you use advanced capabilities.

Test the following where relevant:

Structured output

Check whether the model consistently returns valid JSON when your workflow depends on parsers, schemas, or downstream database actions.

Tool calling

Some models support tool or function calling well. Others support it partially, use a different format, or perform inconsistently.

This matters when the model is connected to an n8n AI Agent that can call other workflow tools.

Context length

Confirm the provider’s actual input and output limits. A model may support a large theoretical context window while the hosted endpoint enforces a smaller limit.

Streaming

Some compatible endpoints do not implement streaming in exactly the same way. Disable streaming during troubleshooting if you encounter response errors.

Model parameters

Parameters such as temperature, maximum tokens, response format, frequency penalties, or reasoning controls may not behave identically across providers.

Reliability and rate limits

Test concurrency, timeout behavior, retries, and provider rate limits before sending production volume.

A workflow that works in a manual test may still fail under parallel execution.

Common errors and how to fix them

401 or authentication error

Usually caused by an invalid API key, an expired key, or a credential copied with extra spaces.

Confirm that the key belongs to the same provider as the Base URL.

404 or endpoint not found

The Base URL is often incorrect.

Check whether the provider requires /v1, a regional endpoint, or a special OpenAI-compatible path.

Model not found

The model ID may be wrong, unavailable to your account, or hosted in a different region.

Copy the exact API model name rather than the marketing name.

Invalid request parameters

The provider may not support one of the parameters sent by the node.

Temporarily remove optional settings and test with the simplest possible request.

Tool-calling failures

The selected model may not support tools reliably, even though ordinary chat requests work.

Try a model explicitly documented for function calling or use a simpler chain instead of an autonomous agent.

JSON parsing errors

The model may add commentary around the JSON or return an incomplete object.

Use stricter prompting, a structured-output feature supported by the provider, or a validation and repair step in n8n.

When this approach makes sense

Using an OpenAI-compatible endpoint can be useful when you want to:

• Reduce inference costs
• Compare several models inside the same workflow
• Use a model optimized for coding, reasoning, extraction, or multilingual work
• Route requests through a model gateway
• Keep the workflow portable across providers
• Connect n8n to a private or self-hosted model endpoint
• Avoid waiting for a dedicated n8n integration

It is especially useful during model evaluation. You can duplicate the model node, connect different credentials, and compare outputs without rebuilding the surrounding workflow.

When it may not be the best option

A native provider node may still be better when you need provider-specific features that are not exposed through the OpenAI-compatible layer.

Examples include:

• Proprietary file APIs
• Provider-specific caching controls
• Unique reasoning parameters
• Native batch processing
• Specialized embeddings or reranking endpoints
• Fine-tuning management
• Provider-specific safety settings

The OpenAI-compatible route is best viewed as a portability layer. It is not a guarantee that every feature will behave exactly like OpenAI.

A better way to design multi-model n8n workflows

Do not hard-code one model into every part of a complex automation.

Separate the model configuration from the business logic wherever possible.

For example, store these values in environment variables, workflow variables, a database table, or a configuration sub-workflow:

• Provider name
• Base URL
• Model ID
• Temperature
• Token limit
• Timeout
• Fallback model

This makes it easier to change providers later without editing dozens of workflows.

You can also assign different models to different tasks.

A fast, inexpensive model may handle classification. A stronger reasoning model may handle planning. A specialist model may generate code. A fallback model may run only when the primary endpoint fails.

That is usually more efficient than sending every request to the largest model available.

Cost savings are useful, but quality still matters

Lower model pricing does not automatically mean a lower total workflow cost.

A cheaper model can become expensive when it produces inconsistent output, triggers retries, creates bad records, or requires manual review.

Evaluate models using business-level metrics:

• Successful workflow completion rate
• Valid structured-output rate
• Tool-call accuracy
• Average latency
• Retry rate
• Human correction time
• Cost per successful task

The right model is not necessarily the cheapest model per million tokens. It is the model that completes the task reliably at the lowest practical cost.

Final takeaway

You do not always need a custom n8n integration to use an open-source or open-weight AI model.

When a provider offers an OpenAI-compatible API, you can often:

1. 1.
   Use n8n’s standard OpenAI Chat Model node.
2. 2.
   Add the provider’s API key.
3. 3.
   Replace the Base URL.
4. 4.
   Enter the provider’s model ID.
5. 5.
   Test the features your workflow relies on.

The result is a more portable AI workflow and a much easier way to experiment with different models.

The node stays the same. The endpoint changes. Your automation keeps moving.