Chat request that falls back to a second model on error

What it is

This n8n workflow asks one model a question and keeps a second model ready in case the first call fails. A Set node holds the prompt, a system line and the two model IDs. The primary call goes to a chat address, and an error sends the same request to the fallback model. The answer is saved with the name of the model that gave it. Six nodes do the work, beside a sticky note with the setup steps.

Who it suits

Developers who test models, and teams that want a backup when a model is down or refuses a call. Skip it if you want to switch on a slow or a poor answer. The fallback runs only after an error.

You need a little n8n and a DaoXE account: import a file, add one credential and type in two model IDs. Its author puts setup at about 2 minutes.

Where to use it

Any n8n that can reach the gateway will run it. The answer stays in the run, so plan where it goes next.

• n8n Cloud: import the file into a new workflow there
• Your own n8n server: the same file and steps
• A larger workflow: replace the manual trigger with your own and pass on the four fields
• Another service that takes the same chat request: change the address in both calls

Setup

Download saves a zip with workflow.json and Mindket’s setup notes in your downloads folder. One key covers both calls.

1. In n8n, create a workflow, open its menu, choose Import from File and pick workflow.json.
2. Create a Header Auth credential with the name Authorization and the value Bearer <YOUR_DAOXE_API_KEY>, using your own key. Select it in Primary model (DaoXE) and in Fallback model (DaoXE).
3. Open Set inputs and replace YOUR_DAOXE_MODEL_ID and YOUR_DAOXE_FALLBACK_MODEL_ID with two model IDs from your account.
4. Click Test workflow and read the last node’s output.

How to use it

Click Test workflow. The last node shows answer, served_model and via, which reads primary or fallback. For daily use, change the prompt in Set inputs or feed in your own.

Example

A developer puts a large model in primary_model and a cheaper one in fallback_model, then clicks Test workflow with the sample prompt, which asks for three blog titles about automation.

When the large model answers, the result reads via: primary with its name in served_model. When that call returns an error, the second node asks the cheaper model and the result reads via: fallback.

For newcomers and experts

If you are new. n8n draws a workflow as boxes joined by lines, and each box, a node, does one job. This one forks after the first call: one line leads to the answer, and a second line, used only after an error, leads to the backup. Break the first model ID on purpose and run it to see the fork.

For experts. The primary node’s On Error setting sends a failed call to its error output, and the fallback node reads the inputs back from Set inputs by name.

Good to know

The backup runs only after an error, and a model ID left as a placeholder makes both calls fail.

• Errors only: a failed status code or a lost connection starts the fallback. A slow answer or a weak one stays as the answer
• No third model: when the fallback call fails too, the run stops there
• Placeholders: YOUR_DAOXE_MODEL_ID and YOUR_DAOXE_FALLBACK_MODEL_ID stay in the file until you replace them
• Sample prompt: the original asked for titles about the gateway’s own selling points. Mindket’s copy asks for titles about saving time with automation
• The gateway: DaoXE is a third-party service that Mindket does not run. Its own note says it is not available in mainland China, and its terms and prices are its own
• Billing: each call is billed by the gateway, and a run that falls back makes two calls
• Your data: the prompt and the system line go to the gateway
• Credentials: the JSON holds none, so add the Header Auth credential yourself