A Simple Pattern for Switching LLM Models in n8n Workflows

When building LLM workflows, one small problem shows up pretty quickly:

You set up a workflow with one model, test it, get it working, and then later realize you want to compare it with another model. Maybe you want a cheaper model for classification, a stronger one for reasoning, or simply want to test how different model families perform on the same input.

If the workflow is tied too tightly to one provider-specific node, switching models can become annoying fast.

So I wanted to share a simple pattern I use: call an OpenAI-compatible endpoint through the HTTP Request node, and keep the model choice flexible.

Disclosure: I am on the TokenBay team, so the example endpoint below uses TokenBay. The same general workflow pattern should also work with other OpenAI-compatible endpoints.

Use case

Let’s say you have an n8n workflow that sends customer text to an LLM and expects a structured response back.

For example, you may want to:

• summarize a customer message
• classify the user intent
• extract key information
• route the result to another node

Later, you may want to test different model families without rebuilding the whole workflow.

Basic HTTP Request setup

Create an HTTP Request node in n8n.

Use the following setup:

• Method: POST
• URL: https://api.tokenbay.com/v1/chat/completions
• Authentication: Header Auth or custom headers
• Header: Authorization: Bearer YOUR_TOKENBAY_API_KEY
• Header: Content-Type: application/json

Example JSON body:

{  
  "model": "gpt-5.4-mini",  
  "messages": [  
    {  
      "role": "system",  
      "content": "You return concise JSON only. Do not include markdown."  
    },  
    {  
      "role": "user",  
      "content": "Summarize this customer message and classify the intent: {{$json.message}}"  
    }  
  ]  
}  

This keeps the request close to the standard OpenAI Chat Completions format, which makes the workflow easier to move, test, or adjust later.

A typical response you might ask the model to return could look like this:

{  
  "summary": "The customer is asking about a delayed shipment.",  
  "intent": "order_status",  
  "priority": "medium"  
}  

Switching models

To test another supported model, you can keep the same HTTP Request node and change only the model value.

For example:

{  
  "model": "claude-sonnet-4.6",  
  "messages": [  
    {  
      "role": "system",  
      "content": "You return concise JSON only. Do not include markdown."  
    },  
    {  
      "role": "user",  
      "content": "Summarize this customer message and classify the intent: {{$json.message}}"  
    }  
  ]  
}  

That means the overall n8n workflow does not need to change. The input structure, HTTP node, downstream parsing, and routing logic can stay the same.

Using a dynamic model value

In a production workflow, I would avoid hardcoding the model name directly in every node.

A cleaner approach is to store the model name in a variable, environment setting, or earlier configuration node, then reference it inside the request body.

For example:

{  
  "model": "{{$json.model}}",  
  "messages": [  
    {  
      "role": "system",  
      "content": "You return concise JSON only. Do not include markdown."  
    },  
    {  
      "role": "user",  
      "content": "Summarize this customer message and classify the intent: {{$json.message}}"  
    }  
  ]  
}  

For example, your incoming n8n item could include:

{  
  "model": "gpt-5.4-mini",  
  "message": "Hi, I ordered last week but still have not received any shipping update. Can you check what happened?"  
}  

Then the HTTP Request node can use:

{  
  "model": "{{$json.model}}",  
  "messages": [  
    {  
      "role": "system",  
      "content": "Return valid JSON only with the fields: summary, intent, priority."  
    },  
    {  
      "role": "user",  
      "content": "Customer message: {{$json.message}}"  
    }  
  ]  
}  

Expected model output:

{  
  "summary": "The customer has not received a shipping update for an order placed last week.",  
  "intent": "shipping_status",  
  "priority": "medium"  
}  

This makes it easier to test changes without editing multiple nodes manually.

Why this can be useful

This pattern is useful when you want to keep your n8n workflow provider-flexible instead of locking the logic too early.

A few practical examples:

• use a cheaper model for simple classification
• use a stronger model for reasoning-heavy tasks
• compare model quality on the exact same workflow
• keep one billing/key flow while experimenting
• avoid rebuilding provider-specific nodes before you know what model works best

It is not a complicated setup, but that is the point. For many LLM automations, keeping the model layer easy to swap is more valuable than over-engineering the workflow from day one.

Things to check

Before using this pattern seriously, check a few things for whichever endpoint you use:

• pricing
• timeout behavior
• model availability
• rate limits
• data and privacy policy
• response format consistency

Example link:https://www.tokenbay.com/?utm_source=devto&utm_medium=community_content&utm_campaign=week1_free_content

The homepage currently lists 500 free credits, 15% off most models, and referral credits, which should be enough to try a small workflow test before committing real usage.