Dify says the model is added but Agent nodes won't use its tools — is the model broken?

Almost certainly not the model. When you add an OpenAI-compatible model in Dify, you manually declare its capabilities — Dify never probes this automatically. If the Function/Tool-Call box wasn't checked, Dify treats the model as unable to call tools regardless of what it can actually do. Go back to the model's entry under Model Provider, check the capability boxes, and save again. Vision support and context length work the same way — set them too low and long inputs get silently truncated.

n8n keeps saying credential test failed even though my API key is correct — why?

n8n validates an OpenAI credential by calling /models before it saves, so this error is frequently unrelated to the key — it means that endpoint is unreachable or isn't returning an OpenAI-shaped list. curl /models directly to confirm. If it genuinely can't be made to validate, switch to an HTTP Request node and POST to /chat/completions yourself, building the Authorization header manually — that works identically without ever touching the credential system.

Does base_url need a trailing /v1 or not?

There's no universal answer — it depends on the specific tool and sometimes the specific version, and both can differ silently between releases. Skip the documentation rabbit hole and read the error instead: a 404 means the path doesn't resolve, so toggle the /v1 suffix and retry — one of the two will work. A 401 is a different signal entirely: the path was fine and the problem is the key, not the URL.

Can Coze / 扣子 connect to a third-party model?

Depends entirely on whether your specific plan and version exposes a custom-model or OpenAI-compatible field in its model settings. If it's there, wire it up exactly like Dify or n8n above. If it's genuinely not there, that's a product boundary rather than a missing setting — you're limited to the built-in models regardless of how you configure things. Check the model settings screen directly rather than assuming either way.

My workflow run failed — did that request still get billed?

Depends on where it failed. If the request never left your workflow (401, 404, a bad model name caught before dispatch), nothing was billed. But if a node timed out waiting for a slow model, or the response arrived and failed to parse afterward, the upstream call had already completed and billed on the provider's side — that mismatch is exactly where 'the workflow failed but the bill went up' reports come from. Debug on a cheap model until the pipeline is proven, then switch to your production model.

Is it fine to use one API key across every workflow?

It'll work, but splitting keys per workflow is worth doing anyway — not for cost, but for blast radius. If one workflow's key leaks, or needs to go to an outside collaborator, revoking a workflow-specific key stops only that automation rather than every integration you've built. Most gateway consoles let you create as many keys as you want at no extra cost — split by workflow or by environment, whichever maps more cleanly to how you'll need to revoke access later.

IntegrationUpdated 2026-09

Dify / n8n / Coze: 'Model Not Configured' and Other OpenAI-Compatible Gotchas (2026)

Wiring Dify, n8n or Coze to an OpenAI-compatible endpoint is three fields — base_url, key, model name. What actually breaks people is four gotchas that have nothing to do with those three fields: a silent capability checkbox, a hidden /models call, node-side timeouts that bill anyway, and default concurrency that trips rate limits.

TL;DR: Connecting Dify, n8n or Coze to any OpenAI-compatible endpoint is the same three fields everywhere: API Base URL, API Key, model name. What actually stalls people out isn't those three fields — it's four gotchas none of them explain: ① Dify makes you manually declare a model's capabilities (context length, vision, function/tool calling) when you add it — leave 'Tool Call' unchecked and the model is selectable but Agent nodes simply won't invoke tools with it, which is exactly what 'model is not configured'-style confusion usually turns out to be; ② n8n's credential save calls `/models` first to validate the endpoint — if your gateway doesn't return an OpenAI-shaped model list, the credential won't save even though chat completions work fine; ③ a workflow node's own HTTP timeout is often shorter than a reasoning model's think time — the node fails, but the upstream call already ran and already billed; ④ batch/loop nodes fire requests concurrently by default, so a few dozen iterations commonly trip a 429 that a single call never would. One gateway that speaks Claude, GPT, Gemini and DeepSeek/Qwen/GLM behind one OpenAI-compatible key (cocodot is one option) removes the multi-provider-key juggling; it doesn't remove these four.

1. First, confirm this is a config problem and not a product boundary

Two minutes here saves an evening of searching later. Open the tool's model settings and look for a field literally called 'API Base URL', 'custom endpoint' or 'OpenAI-compatible'. If it exists, the tool lets you route to any compatible endpoint and which provider you reach is entirely up to you. If it doesn't exist, that's not a setting you missed — it's a boundary the product hasn't opened, and no amount of retrying changes that; you're limited to whatever models are built in. Dify and n8n both expose this field. Coze and similarly closed platforms vary by plan and version — check before assuming either way.

2. The three fields that are genuinely the same everywhere

Every tool with a custom-endpoint option wants the same three things: API Base URL (the gateway's address), API Key (the gateway's key), and a model name the gateway actually serves. Because virtually every relay speaks the OpenAI wire format, changing these three fields redirects traffic from the official endpoint to whichever compatible gateway you're using — nothing else in your workflow needs to change. The useful property of these three fields: each one fails with a distinctive error, so the error tells you which field is wrong without guessing. Base URL wrong → typically 404 (the path doesn't resolve). Key wrong → 401. Model name wrong → model not found. Change one field at a time based on the actual error rather than re-entering all three and hoping.

3. Dify: the capability checkboxes it never checks for you

Path: Settings → Model Provider → OpenAI-API-compatible. Beyond base URL, key and model name, Dify makes you manually declare what the model can do — context window, max output tokens, vision support, and function/tool calling. Dify does not probe the model to detect these; leave a box unchecked and Dify treats the capability as absent, full stop. The classic symptom: a model that clearly supports tool calling is selectable in an Agent or workflow tool node, and the tool step simply never fires — because the Tool Call checkbox wasn't ticked when the model was added. Separately, and just as easy to miss: LLM, Text Embedding and Rerank are three independent entries under a provider, not one bundled registration — add only the LLM and your knowledge-base step will have no embedding model to select from when you go to build it.

4. n8n: why credential save fails even with a correct key

n8n's OpenAI credential has a Base URL field — point it at the gateway, key goes in as usual. The gotcha worth remembering: saving that credential triggers a `/models` request first, purely to confirm the endpoint is reachable and OpenAI-shaped. If your gateway doesn't expose a model-list endpoint in that exact shape, the credential fails to save with 'credential test failed' — and that error has nothing to do with whether your key is valid or whether chat completions actually work. Before assuming the key is wrong, `curl <base>/models` directly and check it returns `{"object":"list","data":[…]}`. If it genuinely won't validate, there's a clean workaround: skip the credential system entirely and POST straight to `<base>/chat/completions` from an HTTP Request node, building the header and body yourself.

5. Coze and everything else that follows the same shape

If Coze (or whatever platform you're on) exposes a custom-model or OpenAI-compatible field in your plan and version, it's the same three-field setup as above. If it doesn't, that's section 1's product boundary again — use its built-in models and stop looking for a setting that isn't there. The same pattern extends to LobeChat, Cherry Studio, OneAPI, FastGPT and essentially every language's official SDK: anywhere you can set a `base_url` parameter, this same approach connects it to a compatible gateway. Get one tool working and the rest follow identically — the setting just lives in a different menu depth each time.

6. Two gotchas unique to workflows, invisible in a single chat request

Neither of these shows up testing a model in a chat window — they only appear once a model is a node inside a bigger pipeline. Timeout-vs-billing mismatch: every node carries its own HTTP timeout, and a reasoning-tier model's think time regularly exceeds it. The node reports failure — but the upstream API call had already been sent and already completed on the provider's side, so it's billed regardless of what the node shows you. The result reads as 'the workflow failed, and the bill went up anyway,' which is confusing until you know why. Fix: raise the node's timeout for anything calling a reasoning model, or route long-running steps to a faster model. Default concurrency: batch and iteration nodes (n8n's Split In Batches, Dify's iteration node) fire every item in a loop concurrently unless told otherwise, and a few dozen items hitting a rate limit at once produces 429s that a single request never would. Fix: drop batch size to single digits, or insert an explicit wait step inside the loop.

7. Model names expire — query the live catalog instead of trusting any article

Any model name printed in an article, including this one, will eventually be wrong — providers rename and retire models on their own schedule. Query the catalog directly instead: a gateway that follows the OpenAI convention exposes `GET /v1/models`, which returns the current OpenAI-shaped list you can paste straight into n8n's or Dify's model field. cocodot's endpoint at `cocodot.co/api/ai/v1/models` is public and needs no auth if you want to see the pattern; it currently lists dozens of models spanning Claude, GPT, Gemini and Chinese models like DeepSeek, Qwen and GLM behind one key, which is the actual point of routing through a gateway in the first place — one set of credentials instead of separately signing up, verifying and billing with every provider you want to call, and DeepSeek/Qwen/GLM specifically without needing a Chinese phone number to register directly with those platforms.

8. A pre-launch checklist before you point production traffic at any of this

Three steps to connect, in order: ① sign up with the gateway and fund a small balance; ② create an API key in its console; ③ set Base URL, Key and model name in the tool per the sections above, using a model name pulled from its live `/models` response. Before scaling up: run the pipeline end-to-end on a cheap model first, and only swap to your production model once the wiring is confirmed — that isolates 'is this a config problem' from 'is this a cost problem' before you're spending real money debugging both at once. Split API keys by workflow rather than sharing one key everywhere — the point isn't saving money, it's blast radius: if one workflow's key leaks or needs to go to an external collaborator, you revoke exactly that key without taking down every other automation. Finally, confirm streaming settings match what the downstream node expects, and manually trigger one full run — including its failure branch — before calling it done.

Symptom → real cause → fix

What you see	Real cause	Fix
404 / not found	base_url path mismatch — almost always a missing or extra /v1	Toggle the trailing /v1 and retry; it's a coin flip resolved in one try
401 / unauthorized	Key wrong, or a hand-built request missing the header	Recheck the key; for a raw HTTP node confirm `Authorization: Bearer <key>` is actually set
model not found	Model name isn't in the gateway's current catalog (names get revised)	curl the gateway's /v1/models and use the name it returns, not one from an old article
n8n: 'credential test failed'	Saving triggers a /models probe first; that endpoint isn't OpenAI-shaped or isn't reachable	curl <base>/models and confirm it returns {"object":"list","data":[…]}; if it won't validate, use an HTTP Request node to POST /chat/completions directly and skip credential validation entirely
Dify: model selectable, tools never fire	Function/Tool-Call capability wasn't checked when the model was added — Dify never probes this itself	Edit the model under Model Provider and check the capability boxes, then save again
Dify: embedding model missing when building a knowledge base	Embedding models are added as a separate entry from LLMs, not bundled automatically	Add a second entry under the same provider, type Text Embedding
Node times out, but the bill still went up	Node HTTP timeout is shorter than the model's actual think time; the upstream call already completed and billed	Raise the node's timeout; avoid reasoning-tier models on latency-sensitive nodes
Batch loop dies with 429 partway through	Batch/iteration nodes fire requests concurrently by default	Drop batch size to single digits, or insert a wait step inside the loop
Streaming turned on, no output arrives	Node streams, but the downstream step isn't parsing SSE chunks	Disable streaming to confirm the pipeline works, then re-enable and fix SSE parsing