GPT-5.6: Migrating without changing behavior by accident

A context window of 1.05 million tokens does not shrink prefill time, and it does not scrub noise out of whatever documents you dump into it.

That's the fact GPT-5.6 does nothing to change, and it's worth saying before anyone opens a diff. OpenAI ships the family as three tiers, Sol, Terra, and Luna, each carrying that same 1.05M window with its own price and throughput position: Sol for frontier reasoning, Terra for balanced production traffic, Luna for cost-sensitive volume. The identifiers worth pinning and testing are gpt-5.6-sol, gpt-5.6-terra, and gpt-5.6-luna. Check OpenAI's current docs before any of this lands in a config file. Aliases, prices, and availability move after an article like this one goes out.

Swapping the identifier is easy. What actually burns you is trusting a well-formed response as proof the swap worked.

Write the contract before you swap the model

Decide what a pass looks like, in writing, before the first prompt goes out. For extraction that's a schema-valid record whose fields trace back to source evidence. For coding it's a patch that passes tests and review, the same bar Codex holds GPT-5 to. For research it's a claim set with sources you can follow. None of those three depend on the output sounding confident.

The test itself is mechanical: pin the old and new versions, replay real traffic, diff the structured outputs, inspect the tool calls, and canary behind a route you can flip back. Keep the full request identical between runs: system instructions, tool schemas, files, sampling or reasoning settings, output limit, all of it. Skip that and you're not comparing models, you're comparing harnesses, because a model looks different when one integration hands it native tools and another pastes in terminal output. This discipline isn't specific to GPT-5.6, it's what any model migration requires if you want the swap reversible.

Worth logging while you run that comparison:

Fluent is not the same as correct

The expensive mistake is editing a model alias in production and calling it done because nothing threw an error. Frontier models make this easy to miss: almost every response reads as plausible. Measure things ordinary code can check, have a reviewer label concrete defects instead of vibes, and keep the wrong outputs. A page of failures teaches you more about routing and guardrails than another page of successes.

Long context earns extra suspicion, for the reason I opened with: a bigger window doesn't remove prefill cost, doesn't filter retrieval noise, and doesn't separate trusted instructions from whatever untrusted document lands in it. If the API supports caching, put your stable prefix first and keep volatile metadata away from the cache boundary. Send a structured checkpoint instead of the entire conversation history when a checkpoint will do. Output deserves the same discipline: a short decision plus the evidence behind it is cheaper to generate and easier to check than an essay nobody asked for.

Tool use shifts the risk in a similar direction. A better model might pick the right function more often, but your application still has to validate the arguments, authorize the caller, cap the side effects, catch duplicate calls, and log what happened. Web pages, files, emails, and tool results are data, never authority, no matter which tier generated the request. I wouldn't bother chasing tight parity on open-ended or creative tasks, there's no schema to diff against, so spend the harness effort where a claim can be checked.

Give the router a rule, not a vibe

The rule that holds up is unglamorous: a migration ships only after contract tests and task evaluations pass, with a rollback path that's been tested, not assumed. Put that in configuration, not in a team's collective memory of which model was fashionable last sprint. Log model identity, phase timings, token categories, tool outcomes, and evaluation results, and skip retaining sensitive prompt content by default.

Keep a cheap, fast lane for routine work and a sharp escalation condition for the hard cases. Send the strongest tier the requests that benefit from it, not everything the gateway touches, and drop a low-cost tier the moment its retries and review overhead cost more than the inference it saved. Pin dated versions wherever stability matters, watch the deprecation notices, canary a new alias before it takes all the traffic, and keep a known-good fallback ready. Re-run the eval set every time the model, the prompt, the tool contract, or a reasoning default changes.

Nothing gets promoted past canary until the eval set passes and the rollback has been exercised, not just declared. That's the rule.