GPT-5.6 and the Case for Routing Instead of Upgrading
Picking one model for everything is an architecture decision disguised as a procurement decision. How to route by consequence, escalate on evidence, and price the workflow instead of the call.
There is a reflex in most engineering orgs: a new frontier model ships, someone changes a string in a config file, and the team calls that a model strategy. It is not. It is a purchase.
Model families now deliberately span several capability and cost tiers. That is a design signal. The provider is telling you that one model is not supposed to serve every request in your product, and the teams treating model selection as an architecture problem are getting better economics and better reliability than the teams treating it as a version bump.
Route by consequence, not by prompt length
The most common routing heuristic — long input goes to the big model — is backwards. A four-word request can trigger an irreversible action against a production system. A forty-page document summary can be completely routine.
Classify work on the axes that actually predict failure cost: how ambiguous the request is, whether the result can be undone, what tool permissions are in play, and what happens to the business if the output is wrong. High-consequence planning earns the strongest reasoning tier. Extraction, classification, formatting, and repetitive transformation almost never do.
- Frontier tier: ambiguous planning, hard code changes, and decisions with expensive failure modes
- Balanced tier: most grounded knowledge work and multi-step tool use
- High-volume tier: classification, routing, cleanup, and well-bounded transformations
- Automatic escalation when confidence, validation, or tool output falls outside a safe threshold
The cheap model that costs more
Per-token pricing is the wrong unit and it produces the wrong decisions. A cheaper model that fails validation and retries three times — burning three sets of input tokens, three tool calls, and a human correction at the end — is more expensive than the stronger model that finished on the first attempt. It also delivered a worse experience while doing it.
Instrument the whole workflow. Task completion, correction rate, latency, and total tokens across every turn required to reach a finished outcome. Optimize business outcome per completed task. Optimizing the price of a single call is how teams talk themselves into a system that is cheap and does not work.
Build an escalation ladder, not a switch
Start every class of work at the least expensive tier that consistently passes its evals. Validate the output â schema checks, tool result verification, a cheap grader, whatever fits. Escalate only on a failed check, and record why. Over a few weeks the escalation log becomes the most honest capability map you have, because it is built from your traffic rather than someone else’s benchmark.
Route on your evals, not on the leaderboard
Public benchmarks tell you something about general capability and almost nothing about whether a model can parse your vendor’s malformed invoice PDFs. Keep a small set of representative tasks from your own production traffic, run every candidate model against it, and let that decide the tier assignment. It takes an afternoon to build and it will outlive three model generations.
“The newest model is not automatically the right production model. The right one is the cheapest tier that reliably finishes the job.”
Primary sources
First-party documentation and announcements used to ground this field note.
