How to Use n8n with ._Template 138 Llm Router Custo Eficiente

Every AI workflow you run through a single premium model is quietly overpaying. A classification that GPT-class reasoning could handle for a fraction of a cent gets routed to your most expensive endpoint. Multiply that by thousands of executions a month and the bill stops being noise. Template 138 — the cost-efficient LLM router — fixes this by putting a routing layer in front of your models inside n8n, so each request lands on the cheapest model that can actually do the job. This guide shows you how to build and operate it.

The problem: one model for every task is a tax you pay silently

Most n8n automations that touch an LLM wire a single node — usually the biggest, most capable model available — to handle everything: extracting a field from an email, summarizing a ticket, drafting a reply, tagging sentiment. That works, and that's the trap. It works well enough that nobody audits it.

The reality is that model pricing spans more than an order of magnitude. A frontier model can cost 15–30x more per token than a small, fast model that would answer a "positive or negative?" prompt identically. When you send trivial tasks to expensive models you're not buying quality — the small model returns the same answer — you're buying latency and a larger invoice. For an ops team running 50,000 executions a month, the difference between a naive setup and a routed one is frequently the difference between a $2,000 bill and a $300 one, with no measurable drop in output.

The second problem is fragility. A single hardcoded model node means a provider outage, a rate limit, or a deprecated model ID breaks the entire workflow. There's no fallback, no degradation path — just a red execution and a Slack alert at 2 a.m.

The solution: a routing layer that classifies before it calls

Template 138 introduces a decision step between your trigger and your model. Instead of "trigger → LLM → output," the flow becomes "trigger → classify complexity → route → model (cheap / mid / premium) → normalize → output." The router reads each incoming request, decides how much horsepower it genuinely needs, and dispatches accordingly.

Complexity is scored on a few practical signals: input length, whether the task is extraction/classification (cheap) versus generation/reasoning (expensive), the presence of structured-output requirements, and an optional priority flag on the payload. Simple, deterministic tasks go to a small model. Open-ended reasoning goes to the premium tier. Everything in between hits a mid-tier model. You get the quality where it matters and the savings everywhere else.

Crucially, the router also gives you a fallback chain. If the chosen model errors or times out, the workflow retries against the next tier down (or a different provider) instead of failing the whole run.

Step-by-step: building the router in n8n

Here's the node-by-node build. It uses only standard n8n nodes plus the LLM provider nodes you already have credentials for.

1. Trigger. Start with a Webhook node (for API-driven calls) or a queue trigger if you're pulling from a message broker. Set the response mode to "Using Respond to Webhook Node" so you can return the final, normalized answer at the end of the chain.

2. Score the request. Add a Code node named classify_complexity. In it, compute a tier from the incoming payload. A minimal version:

const text = $json.prompt || "";
const len = text.length;
const isGeneration = /write|draft|summar|explain|reason|plan/i.test(text);
let tier = "cheap";
if (isGeneration && len > 800) tier = "premium";
else if (isGeneration || len > 400) tier = "mid";
return [{ json: { ...$json, tier } }];

3. Route. Add a Switch node keyed on {{ $json.tier }} with three outputs: cheap, mid, premium. The Switch is what physically splits the flow — keep its rules as plain string matches for readability.

4. Attach a model per branch. On each Switch output, drop the appropriate provider node — for example a Basic LLM Chain (or the direct OpenAI / Anthropic / HTTP Request node) configured with a different model ID per tier. Cheap branch: a small fast model. Mid branch: a balanced model. Premium branch: your top reasoning model. Set the model, temperature, and max tokens explicitly on each — don't rely on defaults, because defaults are how the cheap branch quietly becomes expensive.

5. Normalize the output. Merge the three branches back with a Merge node (mode: "Choose Branch" / append), then a Set or Code node called normalize that flattens every provider's response into the same shape: { answer, model_used, tier, tokens }. This matters because downstream steps shouldn't care which model answered.

6. Add the fallback. On each model node, open Settings → Continue On Fail and wire the error output to an If node that re-routes to the next tier down. This is your degradation path — a premium timeout falls to mid, mid falls to cheap, and only a total failure returns an error.

7. Respond. Close with a Respond to Webhook node returning the normalized object. If you're logging costs, insert an append-to-sheet or database node before it that records tier, model_used, and tokens per run.

Benefits: what changes once it's live

Cost drops 50–80% on mixed workloads. The exact figure depends on your task distribution, but any workflow where the majority of calls are classification, extraction, or short summaries sees dramatic savings because those calls stop hitting premium pricing.

Latency improves on the common path. Small models respond faster. Since most requests route to the cheap tier, your average and p50 response times drop even though the premium path is unchanged.

Resilience becomes built-in. The fallback chain means a provider incident degrades quality slightly instead of taking the automation offline. For an ops team, that's the difference between a non-event and an incident.

Cost becomes observable. Because every run logs its tier and model, you can finally answer "what is this workflow actually costing us, and why?" — and tune the classifier when the data shows a tier is mis-sized.

Common pitfalls (and how to avoid them)

Over-routing to premium. The most common mistake is a classifier that's too generous — a keyword like "explain" pushing everything to the top tier. Start conservative, log the tier distribution for a week, then loosen. If more than ~20% of traffic lands on premium, your thresholds are wrong, not your workload.

Inconsistent output schemas. Different providers return different JSON structures. If you skip the normalize step, downstream nodes break intermittently and you'll blame the router when the real issue is unshaped data. Never let a raw provider response leave the router.

Silent default models. If you leave a model field blank, some nodes fall back to a default that may be expensive or deprecated. Set every model ID explicitly and pin versions where the provider allows it.

No cost logging. Without the per-run log, you're optimizing blind. The logging node costs nothing to add and turns the router from a guess into a measured system — add it before you ship, not after the surprise invoice.

Testing only the happy path. Trigger a deliberate model error (wrong API key on one branch) before going live to confirm the fallback actually fires. A fallback chain you've never exercised is a fallback chain you don't have.

Set up this way, Template 138 turns your LLM spend from a fixed tax into a variable you control — right-sizing every request without touching the quality of the answers your users see.