Most teams pick one LLM backend and stick with it. That is backwards.
I use three kinds of backend: a frontier model for the hardest reasoning, a cloud coding model for routine development, and a smaller local model for mechanical work. The useful question is not which model is “best.” It is which tasks benefit enough from the stronger model to justify using it.
Three Tiers in Practice
Tier 1, peak reasoning. Claude Opus, or codex on the GPT-5 family, handles complex refactors, integration work, and architectural decisions. This is where the stronger model earns its place.
Tier 2, routine coding work. A capable cloud coding model can handle standard feature development, test writing, and documentation when the task is well specified and the output will be reviewed.
Tier 3, mechanical edits, local. A small local model can handle single-file mechanical edits, formatting, scratch utilities, and simple transformations when a quick diff review is enough to catch mistakes.
The point is not a universal split. Different workloads produce different distributions. Routing should follow task difficulty, failure cost, and how cheaply the output can be checked.
What a Routed Session Looks Like
In a routed session, the strongest model handles decisions that depend on broad context or architectural judgment. Read-heavy exploration, routine test generation, and mechanical cleanup can go elsewhere when their outputs are easy to inspect. The goal is to keep low-risk churn from crowding out the context needed for harder decisions.
Context Pollution Is the Real Cost
The hidden expense of using a top-tier model for everything is not the per-call price. It is context-window pollution. Every diff that model reads, every test output it scans, every file it opens: that token spend competes with the deep reasoning you need it for. Use Opus for formatting tasks and you are burning the budget you need for architectural decisions. Context windows are finite. The high-end model’s most precious resource is not API credits; it is context capacity.
The Fix: Dispatcher Mode
The solution is not to pick a cheaper model. It is to route work by fit.
Claude becomes the strategist. It looks at the task and decides where it belongs: “deep reasoning, I will handle it,” “standard CRUD work, dispatch to GLM-5.1,” “formatting, dispatch to the local 7b.”
The dispatcher does not replace the high-end model. It preserves the high-end model’s capacity for the work that benefits from its capabilities. Claude’s role shifts from doing everything to directing everything.
This requires structure: the workflow needs to know which backends are available, what each does well, and how their output will be checked.
This post is about one axis of routing: cost tier, or matching the size of the model to the size of the job. A second axis, routing by the kind of job rather than its size, gets its own treatment in a companion piece on routing by role instead of cost.
The Right Framing Question
The “best model” framing is backwards. The right question is which model has the best fit for this task at the cheapest acceptable quality.
A routed setup can preserve the strongest model’s context for the work that needs it. That does not guarantee lower cost or faster delivery; the benefit disappears when handoffs and review cost more than the routing saves.
Your Bill Is Your Failure Rate
Look at cost per completed task, including review and rework. A large bill from the strongest model may be justified by the workload, or it may show that routine work is being routed there by default. The bill alone cannot tell you which.