Four visual builders for LLM apps, one question: what changes when their model calls go through Router One? The tools stay what they are: Dify builds apps and knowledge bases, Flowise wires LangChain JS nodes into flows, Langflow connects components on a canvas, and n8n runs business workflows in which an AI Agent is one node among many. What changes is the request underneath: one sk- key, exact model IDs from /models, and one trace per model call in Dashboard → Logs with model, tokens, cost, latency, status and request_id. The gateway serves the model calls; the builder runs the flow.
The verdicts. Dify: the OpenAI-API-compatible provider, one entry per model, with the /v1 base URL in its API endpoint field. Flowise: the OpenAI Custom Model node, a free-text Model Name, and Base Path under Additional Parameters. Langflow: Settings → Model Providers → OpenAI Compatible, with models discovered from /v1/models. n8n: the OpenAI credential's Base URL, plus Use Responses API switched off on the OpenAI Chat Model node for any ID outside the GPT and DeepSeek families.
Side by side
| Tool | Where it runs | Point it at the gateway | Protocol sent | Model ID entry | Stays in the tool |
|---|---|---|---|---|---|
| Dify | Dify Cloud, or Docker Compose (setup at http://localhost/install) | Model Provider → OpenAI-API-compatible: Model Name, API endpoint https://api.router.one/v1, API Key | Chat Completions; an API Type field can select Responses | Typed, one provider entry per model | Apps, workflow nodes, Agent strategies, knowledge bases, the app API |
| Flowise | npm (npx flowise start) or Docker Compose; http://localhost:3000 | OpenAI API credential + OpenAI Custom Model node: Model Name, Base Path https://api.router.one/v1 | Chat Completions; LangChain moves three cases to /v1/responses | Free text on OpenAI Custom Model; fixed dropdown on the stock OpenAI node | Chains, agent loops, memory, Document Stores, the Prediction API |
| Langflow | uv pip install langflow, Langflow Desktop or Docker; http://127.0.0.1:7860 | Settings → Model Providers → OpenAI Compatible: Base URL https://api.router.one/v1, API Key | Chat Completions | Discovered from GET /v1/models, enabled per model; Model Name Override takes a typed ID | Components, the Agent loop and tools, the flow API and MCP server |
| n8n | n8n's hosted cloud, or Docker; editor at http://localhost:5678 | Credentials → OpenAI: API Key, Base URL https://api.router.one/v1, selected on the OpenAI Chat Model node | Responses by default on the current OpenAI Chat Model node; Chat Completions with Use Responses API off | From List (loaded from the credential's /models route) or ID (typed) | Triggers and webhooks, workflow nodes, the AI Agent loop, tool and memory sub-nodes |
Chat Completions is the common denominator: /v1/chat/completions serves every chat model in the catalog (GPT, Claude, Gemini, Grok and DeepSeek families), so the same anthropic/claude-sonnet-5 works in all four, prefix included. /v1/responses is served natively only for the currently listed GPT-family and DeepSeek IDs; any other ID sent there gets an HTTP 400 whose message says must be called via. Two of the four reach that endpoint without being asked. Flowise does it through LangChain in three documented cases: a Reasoning Summary chosen on the stock OpenAI node, OpenAI Built-in Tools ticked on an Agentflow V2 Agent node, or a model name that contains codex or gpt-5.2-pro. n8n does it by default, because Use Responses API is on when you add an OpenAI Chat Model node. OpenAI-compatible API lists what each endpoint serves. The last column is the boundary: nothing in it runs on the gateway.
Dify: the OpenAI-API-compatible provider, one entry per model
Choose OpenAI-API-compatible in Dify's model-provider list: Settings → Model Provider in the Dify guide, Integrations → Model Provider in Dify's current docs, where you install the provider and click Add Model. Each model is its own entry and becomes selectable in your apps, LLM nodes and Agent nodes.
# Dify → Settings → Model Provider → OpenAI-API-compatible
Model Name: <exact-model-id-from-/models>
API endpoint: https://api.router.one/v1
API Key: sk-your-router-one-key
The URL field is labeled API endpoint URL in older releases of the provider plugin and API Base URL in current ones (0.0.66 checked); both take the /v1 base, and the plugin appends /chat/completions. Leave API Type on Chat Completions API. Function Call Type defaults to Not Support, which means Dify sends no tools array, so set it to Tool Call before you put a tool-calling model behind an Agent node.
The first failure. Saving an entry sends a small ping chat request, so a wrong value fails on the spot with Credentials validation failed with status code, then the status and the gateway's response body: 404 not_found for a missing or doubled /v1, 401 AUTH_INVALID_API_KEY for the key. A save that succeeds is already a row in Dashboard → Logs. Guide: Dify + Router One.
Flowise: the OpenAI Custom Model node, not the stock OpenAI node
Flowise's two OpenAI nodes both wrap LangChain JS's ChatOpenAI class. The stock OpenAI node's Model Name is a closed dropdown loaded from Flowise's models.json, which lists bare OpenAI names, so it cannot hold a catalog ID. The OpenAI Custom Model node (ChatOpenAI Custom before Flowise 3.1) has a free-text Model Name. Store the key under Credentials → Add Credential → OpenAI API, then fill in the node:
# Flowise 3.1.x canvas → Add Nodes → Chat Models → OpenAI Custom Model
# (3.0.x and the official docs: ChatOpenAI Custom, with BasePath / BaseOptions)
Connect Credential: OpenAI API credential holding sk-your-router-one-key
Model Name: <exact-model-id-from-/models>
Temperature: 0.9
# Additional Parameters
Streaming: on
Max Tokens: (optional)
Timeout: (optional, milliseconds)
Base Path: https://api.router.one/v1
Base Options: (leave empty)
The same node serves Chatflow chains, the Tool Agent, Agentflow V2 nodes and Custom Assistants. It shows neither Reasoning Summary nor OpenAI Built-in Tools, so it stays on Chat Completions.
The first failure. A 404 tagged MODEL_NOT_FOUND, ending in Troubleshooting URL: https://docs.langchain.com/oss/javascript/langchain/errors/MODEL_NOT_FOUND/. LangChain tags every HTTP 404 that way, so read the text before the link: with Base Path set to https://api.router.one, the gateway answers 404 not_found with a message saying the base URL must end in /v1. With Base Path empty, the SDK falls back to https://api.openai.com/v1 and nothing appears in Dashboard → Logs. Guide: Flowise + Router One.
Langflow: one OpenAI Compatible provider, models discovered from /v1/models
Since Langflow 1.11, model access is configured once for the whole instance. On Save, Langflow validates the pair by requesting /v1/models with the key as a Bearer token, then lists what it found under Language Models and Embedding Models.
# Langflow 1.12 → profile icon → Settings → Model Providers → OpenAI Compatible
Base URL: https://api.router.one/v1
API Key: sk-your-router-one-key
# Save → Langflow probes /v1/models and lists the catalog
# Language Models: enable the chat model IDs you use
# Embedding Models: leave off (no /v1/embeddings on the gateway)
# In a flow: Language Model (or Agent) → Language Model field
Provider: OpenAI Compatible
Model: <exact-model-id-from-/models>
On 1.12 a missing /v1 is appended for you; on 1.11.x it is not. A container reads the same two values from OPENAI_COMPATIBLE_BASE_URL and OPENAI_COMPATIBLE_API_KEY. The alternative is the bundled OpenAI component: OpenAI API Base on the /v1 URL, and a Model Name combobox that accepts a typed ID.
The first failure. Saving the provider fails with a fixed message. Authentication failed for the OpenAI-compatible endpoint. Check OPENAI_COMPATIBLE_API_KEY. means the probe got 401 or 403. The OpenAI-compatible endpoint at … returned HTTP 404 for …/models. Check that the base URL points to an OpenAI-compatible API. means the path is off, typically a doubled /v1/v1. If the save works but a model is missing from the dropdown, check the toggles: Langflow marks only the first five discovered IDs as defaults. Guide: Langflow + Router One.
n8n: the OpenAI credential's Base URL, and one toggle on the model node
n8n's OpenAI credential has a Base URL field that defaults to api.openai.com and accepts any OpenAI-compatible endpoint. Open Credentials → Add credential → OpenAI, or create one from the credential dropdown on an OpenAI or AI Agent node:
# n8n → Credentials → Add credential → OpenAI
API Key: sk-your-router-one-key
Base URL: https://api.router.one/v1
# Organization ID: leave blank
# In the node: select this credential, set Model to <exact-model-id-from-/models>
On the OpenAI Chat Model node, the sub-node an AI Agent uses, Model is either From List, loaded from the credential's /models route, or ID, typed by hand. The same node carries Use Responses API, which is on by default in the current node version (checked at n8n 2.39.8) and sends POST /v1/responses; switched off, the node sends Chat Completions.
The first failure. A Claude, Gemini or Grok ID with Use Responses API still on gets the HTTP 400 that says must be called via. Switch the toggle off; the base URL is fine. Other nodes can reuse the credential, but a text-generation request, a Responses request and a file operation have different compatibility requirements, so check each node's selected operation and actual API path. Guide: n8n + Router One.
Embeddings and knowledge bases stay elsewhere
Router One has no /v1/embeddings and no rerank endpoint. Each builder's retrieval feature needs its embedding model on another provider or on a local model, and only the chat or agent node points at the gateway.
- Dify: knowledge bases index and retrieve with an Embedding Model, and a Rerank Model reorders the results; both are separate entries under Default Models. Keep them off Router One.
- Flowise: Document Stores and vector-store nodes call a separate Embeddings node. OpenAI Embedding and OpenAI Custom Embedding have a Base Path of their own, which must not point at Router One; Ollama Embedding runs locally.
- Langflow:
/v1/modelscarries no capability data, so every discovered ID is also offered under Embedding Models. Leave them off; selecting one makes Langflow call/v1/embeddings. - n8n: the Embeddings OpenAI sub-node uses the same OpenAI credential type, Base URL included. Give it a second OpenAI credential on a provider that serves embeddings.
Retrieval happens inside the tool, and only the final prompt with the retrieved chunks reaches the gateway. The knowledge-base apps draw the same line: RAGFlow, FastGPT and AnythingLLM.
One workflow run is many requests
An agent calls the model again after every tool result (tool calling), so one message into a flow is rarely one request. Every builder has a loop bound:
- Dify: Maximum Iterations on the Agent node, 3 by default in the official Agent strategies plugin.
- Flowise: the Tool Agent's Max Iterations is empty by default, which means 15; the Agentflow V2 Agent node has no iteration field. LangChain retries a failed call up to 6 times, but never a 400, 401, 402, 403 or 404.
- Langflow: the Agent's Max Iterations defaults to 15 model calls. The OpenAI client underneath retries twice on the global provider path; the bundled OpenAI component asks for 5.
- n8n: the AI Agent's Max Iterations defaults to 10, and the OpenAI Chat Model node's Max Retries to 2.
None of these is a spend cap, and every attempt that reaches the gateway is its own request, trace and charge. The cap is the key's maxSpend: once it is reached the gateway answers HTTP 402 (error codes), and the wallet and the other keys are untouched. Create one key per instance in Dashboard → API Keys, or one per workflow where credentials are chosen per node, as in Flowise and n8n. Reconcile in Dashboard → Logs by request_id (cost tracking): filter by time window and exact model, and match the rows against the run. A streamed request that the tool disconnects midway is recorded as HTTP 499 client_cancelled.
Each builder also has an API of its own, and none of them is the gateway's /v1: Flowise's Prediction API (POST /api/v1/prediction/:id, a Flowise API key), Langflow's POST /api/v1/run/<flow-id> (a Langflow API key in x-api-key; it also starts with sk-, so label both), Dify's app API (a Bearer app key, https://api.dify.ai/v1 on Dify Cloud) and n8n's Webhook URLs. The Router One key never goes there.
Which one to pick
All four reach the same catalog through the same endpoint, so choose by what surrounds the model call.
- Dify if the deliverable is an app: every published app doubles as a REST API, and knowledge bases are part of the product.
- Flowise if you think in LangChain JS building blocks and want a Node.js install.
- Langflow if you work in Python and want model access configured once per instance, with flows callable over its API or its MCP server.
- n8n if the model call is one step in a larger business workflow with triggers, webhooks and app nodes around it.
To write the loop in code instead, see OpenAI Agents SDK vs Claude Agent SDK vs Pydantic AI vs CrewAI. Every setup guide is on /integrations.
FAQ
Do all four send the same request to the gateway? Almost. Dify, Flowise's OpenAI Custom Model node and Langflow send Chat Completions by default; n8n's current OpenAI Chat Model node defaults to the Responses API until Use Responses API is switched off. /v1/chat/completions serves every chat model in the catalog, while /v1/responses is served natively only for the currently listed GPT-family and DeepSeek IDs.
Where does the exact model ID go in each tool? Dify: the Model Name of a provider entry, one per model. Flowise: the free-text Model Name of the OpenAI Custom Model node. Langflow: the list discovered from /v1/models, or Model Name Override. n8n: the Model field of the OpenAI Chat Model node, From List or ID. Keep the vendor prefix in every case.
Can a knowledge base in these tools use Router One for embeddings? No. Router One has no /v1/embeddings or rerank endpoint, so keep the embedding model on another provider or a local model and point only the chat or agent node at the gateway.
Can one key serve all four tools? Yes. The same Router One key works in every configuration on this page, and calls draw on the same wallet. Separate keys give each instance its own maxSpend cap, so a looping agent stops at its own cap with HTTP 402 and cannot spend what another tool needs.