GPT-5.6: A coding workflow that survives the demo

Three tiers this time: Sol, Terra, and Luna, each with a 1.05M-token context window and its own spot on the price-performance curve. The identifier you actually put in a request is gpt-5.6-sol, gpt-5.6-terra, or gpt-5.6-luna. Go check OpenAI's own model docs before you wire anything up. Aliases and prices on a lineup like this move fast, and whatever I write here will be stale before long.

None of that tells you whether the thing is worth switching to. That question only answers itself against the repositories your team actually maintains: does the model cut verified completion time on real fixes, or does it just read sharper in a chat window. Decide what "verified" means before you send the first prompt. Fluency doesn't count. A schema-valid record that matches the source evidence, for extraction work. A patch that passes tests and survives review, for coding. A claim set you can trace back to a source, for research. None of those care how confident the output sounds.

What I'd actually run before switching

Build a fixture set out of your own repo: bug fixes, refactors, added tests, and a few questions about code nobody on the team wrote recently. Run every tier against the same fixtures with identical tool permissions and identical acceptance checks, and don't let the request drift between runs. Preserve the whole thing: system instructions, the tool schemas, the files, whatever sampling or reasoning settings the API exposes, and the output limit. Change the harness and you change the result, sometimes more than changing the model does. Give one setup native tool calls and hand another pasted terminal output, and the weaker model can win the comparison for reasons that have nothing to do with the weights. Hold the workflow constant and let each provider use its own documented format inside that frame.

What makes the comparison worth trusting is what you log while it runs. I keep a short set of fields on every fixture pass, dated to the API version and the prompt revision, so an old result never gets compared against a silently different model wearing the same name:

model ID + dated API version
prompt and tool-schema revision
input, cached input, reasoning, output tokens
queue time, first token, total completion time
pass, retry, abstain, human repair
provider error and fallback route taken

None of that is exotic. It's the difference between "the new tier felt faster" and a number you can defend to whoever has to sign off on the switch.

Where it quietly falls over

The failure mode that actually costs money is judging coding ability from a single greenfield prompt, the kind that never has to open an existing file or repair a test it broke. Frontier-class output is fluent enough that this is hard to catch by reading; almost everything it writes sounds plausible on first pass. Measure what ordinary code can actually verify. Ask reviewers to flag concrete defects instead of handing back a vibe score. Keep the wrong answers. A pile of failures is worth more than another folder of clean demo transcripts, because the failures are what tell you where to route around the model later.

Long context invites a specific kind of sloppiness, and a 1.05M window doesn't fix it. Capacity doesn't remove prefill time, doesn't filter retrieval noise, and doesn't separate trusted instructions from the documents pasted in below them. If the API supports caching, put the stable prefix first and keep anything that changes per request away from the cache boundary, or you'll pay prefill costs you thought you'd already dodged. Sending the entire chat history because it's easier than a structured checkpoint is a habit worth breaking. The same restraint applies on the way out: a short decision plus its evidence is cheaper to generate and faster to review than an essay nobody asked for.

Tool calling moves the risk somewhere else entirely. A better model might pick the right function more often, but the application still has to validate arguments, check who's actually asking, cap what a call can do, catch duplicate requests, and log what happened. Web pages, uploaded files, emails, and the output of the last tool call are all just data. None of them get to act as instructions, no matter how the new tier formats them. A sharper model is not a replacement for a narrower interface. It just makes a bad interface fail more quietly.

Once the comparison is trustworthy, routing stops being a debate and turns into configuration, treating the model choice as a dial instead of whichever name is fashionable this month:

• route coding tasks by measured repository outcome, not by reputation, and require tests plus a human-readable diff before anything merges
• put that rule in configuration, not in a message asking people to remember which model is in fashion this week
• 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 clear condition for escalating up to the frontier tier
• pin dated versions where stability matters, canary new aliases before they take all the traffic, and keep a known-good fallback ready to go

None of this is unique to OpenAI's naming choices this quarter. Treat a tier swap like any other dependency bump, the kind that regresses silently if nobody's watching, which is most of what migration turns out to mean once you've done it enough times. Re-run the fixture set whenever the model, the prompt, the tool contract, or a reasoning default changes underneath you, not just when the vendor tells you to.

None of this crowns Sol, Terra, or Luna a permanent winner, and it shouldn't. The point is knowing which of your team's actual work this tier completes reliably, what that costs against the alternative, and the exact condition under which the router should stop sending it anything.

If you're setting this up today, the next thing to check is small: pull the hardest patches your team merged recently, run them through Terra with tools wired up for real instead of pasted in as text, and see how many pass on the first attempt without a human rewriting the diff. That number tells you more than any leaderboard will.