Run Dify apps on an OpenAI-API-compatible endpoint.

Quick answer: install the provider, add models by id.

In Dify, open Settings and go to Model Provider. Since Dify 1.0, providers are plugins: find OpenAI-API-compatible (published by langgenius) in the list or install it from the Marketplace, then click Add Model on its card. The dialog is per-model: choose the Model Type (LLM for chat models), enter the exact catalog id in Model Name, paste your key in API Key, and set API Base URL to https://api.apisrouter.com/v1. Leave Completion mode on Chat, then set Model context size and Upper bound for max tokens to the documented limits of the id you are adding. Save, and the model appears in the provider's list, selectable from every app's model dropdown. Repeat the dialog for each id you want; two minutes per model, once.

Model Type:                LLM
Model Name:                claude-sonnet-4-6
API Key:                   sk-YOUR-APISROUTER-KEY
API Base URL:              https://api.apisrouter.com/v1
Completion mode:           Chat
Model context size:        200000
Upper bound for max tokens: 64000

How Dify talks to a compatible provider.

Dify (langgenius on GitHub, roughly 149K stars) is the leading open-source LLM app platform: visual workflows, agent nodes, RAG pipelines over knowledge bases, and published apps with their own API endpoints. Every LLM node in that stack resolves to a model registered under some provider. The OpenAI-API-compatible provider is deliberately generic. Each model you add is a self-contained record, id, endpoint, key, limits, and Dify sends standard chat-completions requests to the configured base URL with your Model Name as the model string. Nothing in the request cares which vendor trained the model, so claude-sonnet-4-6 and deepseek-v4-pro are as valid here as any GPT id, and different models can even point at different endpoints if you ever need that. The per-model registration that feels like friction is also the control surface: the context size and max-tokens values you enter are what Dify's orchestrator uses to budget prompts, trim conversation history, and validate node settings. Enter honest numbers from the model's documentation. Overstating context produces requests the endpoint rejects; understating it silently truncates the context your RAG nodes worked to retrieve.

The fields that do real work.

Model Name is the wire value: it must match the gateway's /v1/models listing character for character, since it travels in every request. The optional model display name only relabels the UI. Completion mode should stay on Chat for every model in the current catalog; the Completion option exists for legacy text-completion endpoints and produces malformed requests against chat models. Model context size and Upper bound for max tokens are the pair people rush. Context size is the model's total window; the upper bound caps how many output tokens a node may request. Dify defaults both to 4096, which is far below what current models support, and leaving the defaults quietly cripples long-document RAG and long-form generation. Set them from the model documentation, not from habit. The capability selectors matter when your apps use them: Vision Support only for ids that accept image input, and the function-call setting to match the model's tool-use support, since agent nodes rely on it. A wrong capability claim fails at runtime inside the workflow, which is a slower place to debug than this dialog. If your workspace also uses embedding or rerank models, the same provider registers them under their own Model Type entries against the same base URL; confirm the specific ids are served by the endpoint before wiring knowledge-base settings to them.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50
# register these ids verbatim as Model Name entries

Choosing models for workflows and agents.

Dify's own overview pages show tokens per app, but the per-key usage view in the APIsRouter console adds the per-model split across all apps on the same page, which is the number that decides which id keeps the slot.

• Workflow LLM nodes are volume: classification, extraction, routing, summarization steps that fire on every run. claude-haiku-4-5-20251001, gpt-5.4-mini, and gemini-3.5-flash keep per-run cost flat.
• Agent nodes and complex reasoning steps earn claude-sonnet-4-6, and its dependable tool use matters more in agents than raw benchmark scores.
• RAG answer nodes carry retrieved context on every call, so input pricing dominates; deepseek-v4-pro is worth testing where retrieval is heavy and answers are long.
• Register a fast id and a strong id for the same role and A/B them per node: in Dify, switching a node's model is a dropdown, not a migration.
• Published apps inherit their nodes' model choices, so the dropdown decision you make in the editor is the unit economics of the app you ship.

Pay-as-you-go · transparent per-model pricing

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Failure modes specific to Dify.

Provider missing from the list means the plugin is not installed: since Dify 1.0 the OpenAI-API-compatible provider ships as a Marketplace plugin, and fresh self-hosted instances start without it. Install it once per workspace. A model that saves but errors on first use is usually one of three things: a Model Name that does not match the catalog spelling, a base URL missing its /v1 (Dify appends route paths like /chat/completions to what you enter), or context/max-token values beyond what the model accepts. The error surfaces in the app or workflow log; the fix is back in the Add Model dialog. Agent nodes failing while plain chat nodes work points at the function-calling capability setting, or at a model whose tool use does not meet what the agent strategy expects. Test agents against claude-sonnet-4-6 first to separate configuration problems from model choice. And on self-hosted instances behind strict egress rules, remember it is the Dify api container that must reach the endpoint, not your browser; a curl from inside that container settles connectivity questions quickly.

Who routes Dify through a gateway.

• Teams building LLM apps who want Claude, GPT, Gemini, and DeepSeek selectable per node without maintaining a vendor account per provider.
• Self-hosters running Dify for internal tools, where one key in one provider keeps the whole workspace's cloud spend on a single usage log.
• Builders comparing models on real workflows: each candidate is an Add Model dialog and a dropdown switch, not a new integration.
• Developers without access to a given vendor's billing. Top-up based access with no card requirement removes the per-provider sign-up dependency.
• Agencies shipping client apps on Dify who need per-project keys so each client's model spend reports itself.

Verify the endpoint and debug the first run.

Curl the models listing first and register ids from its output; hand-typed Model Names are the leading cause of not-found errors because the field is free text. Then run one chat completion against the id you registered, with the same key. Inside Dify, test in a scratch app before wiring production workflows: add an LLM node, select the new model, run once. Authentication errors point at the API Key field; not-found at the Model Name; connection errors at the base URL or container egress; length errors at the context and max-token values. Once runs flow, the APIsRouter console shows per-request model, token counts, and spend. Workflows multiply LLM calls in ways that are hard to eyeball from the editor, and the usage log is where a five-node pipeline's real token profile becomes visible, per model, per day.

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-4-5-20251001",
       "messages":[{"role":"user","content":"ping"}]}'

FAQ