The New Model Race Is Really A Routing Problem
OpenAI’s GPT-5.6 announcement is getting attention for the obvious reasons: bigger capability claims, new model tiers, stronger coding and cyber language, and the usual oxygen drain that follows a frontier model launch. The useful part is less glamorous. OpenAI describes GPT-5.6 as a family of models named Sol, Terra, and Luna, with different tradeoffs across capability, speed, and cost, and says the preview is initially limited to selected organizations through the API and Codex rather than ordinary ChatGPT access. That matters because it makes one thing painfully clear: modern AI work is no longer a single-model decision. It is infrastructure.
The official OpenAI preview says GPT-5.6 introduces Sol as the flagship model, Terra as a balanced lower-cost option, and Luna as the fastest and most cost-efficient option, with preview access limited at launch. It also describes additional safeguards and cases where requests may take longer or fail to return content while checks run, especially in sensitive biological or cybersecurity areas. That is not a tiny product footnote. That is the shape of the work now. The more capable the model, the more the surrounding system matters. See OpenAI’s own preview details here: OpenAI GPT-5.6 preview announcement.
The lazy question is, “Should everything use the smartest model now?” The useful question is, “Which jobs deserve the expensive, slower, more heavily guarded model, and which jobs should stay on the cheap one?” If your answer is “we will let the user pick from a dropdown,” congratulations, you have invented the cockpit from a regional jet and bolted it onto a toaster.
One Default Model Is A Bad Product Decision
A default model is convenient until it silently becomes policy. If every request goes to the strongest model, you waste money on routine work, increase latency, and make outages more painful. If every request goes to the cheapest model, you get brittle answers for work where mistakes are expensive. If users choose manually, they usually pick based on vibes, model names, or whatever sounded impressive on social media that morning. A durable AI product needs routing rules, not a beauty contest.
Think of the model layer like database access. You do not give every query the same lock, the same replica, and the same timeout. You route reads, writes, analytics jobs, and migrations differently because the blast radius differs. AI tasks deserve the same treatment. Summarizing a meeting transcript is not the same as editing production code. Extracting invoice fields is not the same as proposing a security patch. Drafting a polite email is not the same as deciding whether a customer account should be suspended.
The model switchboard is the small piece of boring software that decides where the work goes. It does not need to be fancy. It needs to be explicit. A request comes in. The system classifies the task. It checks cost budget, risk level, required tools, latency target, data sensitivity, and evidence requirements. Then it sends the work to the right model tier with the right permissions. Dry? Yes. Also the difference between a useful AI product and a very expensive slot machine.
Route By Failure Cost, Not By Hype
The cleanest routing rule is failure cost. Not benchmark score. Not launch-day excitement. Not whether the model name sounds like a minor Roman deity. Failure cost.
- Low failure cost: rewriting text, brainstorming names, summarizing non-sensitive notes, formatting data, drafting throwaway copy. Use a fast, cheap model. Let the user regenerate. Do not make a ceremony out of it.
- Medium failure cost: customer replies, spreadsheet formulas, internal documentation, first-pass code review, support triage. Use a balanced model. Require citations, file references, or structured output where practical.
- High failure cost: production code edits, legal-adjacent summaries, medical-adjacent summaries, security analysis, financial calculations, account actions, policy enforcement. Use the strongest approved model, add tool limits, log the reasoning trail, and require human approval before anything irreversible happens.
- Unknown failure cost: anything vague. Route to clarification first. The cheapest safe model is often the one that asks one more question before touching the work.
This approach also makes model upgrades less dramatic. When a new frontier model appears, you do not rewrite the whole product. You update the route map. Maybe the high-cost code path gets a new option. Maybe long-context research moves from one tier to another. Maybe nothing changes until the model has passed your own tests. The point is to separate product behavior from model marketing.
The Strongest Model Should Leave The Best Receipts
The more power you give an AI system, the more evidence it should leave behind. This is where a lot of AI tooling still feels backwards. Cheap chat gets logs. High-impact automation gets a cheery “done.” No. Absolutely not. If the model edits files, calls tools, reads private data, or spends real money, it needs a paper trail.
A good receipt includes the original user request, the model chosen, the reason it was chosen, files or records accessed, tools called, network requests made, tokens or cost estimate, generated output, rejected alternatives when relevant, and any human approvals. This is not just for compliance theater. It helps you debug. It helps users trust the result. It helps future you understand why a model touched a thing at 2:14 a.m. and confidently made it worse.
This connects directly to token and usage visibility. If the user cannot see when a task burned through a large context window, retried several times, or escalated to a premium model, the product feels arbitrary. Notavello has already argued for better accounting in AI token usage transparency, and the same rule applies here: powerful tools need visible meters. Hidden consumption is how trust quietly leaves the building.
The receipt does not need to expose every internal prompt. It does need to explain the operational facts. Which model handled it? Why that one? What did it touch? What did it cost? What changed? Can it be rolled back? If a team cannot answer those questions, it does not have an AI workflow. It has an impressive fog machine.
Build Fallbacks Before The Launch Day Traffic Arrives
New models arrive with capacity limits, preview restrictions, latency surprises, safety filters, changing access rules, and pricing details that rarely match the fantasy spreadsheet. That is normal. What is not normal is building an entire product path that assumes the newest model will always be available, fast, cheap, and permissive. That is not engineering. That is sending a wish to production.
Every model route should have a fallback ladder. If the premium model is unavailable, can the task move to the balanced model? If the balanced model cannot use a required tool, can the product switch to read-only mode? If safety checks delay a response, should the user see a progress state instead of a spinning wheel? If the model refuses a sensitive request, should the product offer a safer defensive template instead of dumping the user into a dead end?
Fallbacks should be designed by task type. A marketing draft can fall back freely. A code migration should not quietly downgrade to a weaker model and keep editing files. A cybersecurity task may need a defensive-only route. A finance task may need calculation tools and human confirmation. The right fallback is not always “try another model.” Sometimes it is “stop and ask for approval.” Annoying, yes. Cheaper than an incident report.
Teams should also keep a small offline evaluation set for their own product. Not a grand academic benchmark. Just 50 to 200 real tasks that represent the work users actually do: messy prompts, long files, bad formatting, edge cases, and known traps. Run the new model against those tasks before changing defaults. Public benchmarks can tell you a model is impressive. Your test set tells you whether it breaks your product in a new and exotic way.
A Practical Model Switchboard Checklist
If you are building or buying AI tooling in 2026, the model switchboard should be part of the product spec. It can start as a config file. It can become a policy service later. The important part is that routing decisions are written down and testable.
- Define task classes: writing, extraction, coding, research, support, security, file editing, account actions, and anything else your product actually does.
- Assign risk levels: low, medium, high, blocked. Do this before picking models.
- Set model tiers: fast, balanced, strongest, local, and human-only. The names can map to any provider later.
- Set tool permissions: read-only, file edit, browser, shell, database, payment, email, ticketing, deploy. Never let model choice automatically imply tool access.
- Add cost ceilings: per task, per user, per workspace, per day. If a task escalates, show it or log it.
- Require receipts: model used, data accessed, tools called, changes made, approvals collected, and rollback path.
- Design fallbacks: downgrade, retry, ask for clarification, switch to read-only, require human review, or stop.
- Retest on upgrades: never swap the default model just because a provider shipped a shinier one.
The winner in AI tooling will not be the team that blindly uses the biggest model for everything. That team will mostly win invoices. The real winner will route routine work to cheap models, risky work to stronger guarded models, sensitive work through approvals, and failed work into clear recovery paths. GPT-5.6 is interesting because it shows where the frontier is going. The practical lesson is simpler: the model is no longer the product. The switchboard is.