GPT-5.6: Long context without the token landfill

People keep doing the same thing with a bigger window: point the whole document store at it, skip retrieval because retrieval is work, and get burned when the model answers from the ninth near-duplicate paragraph instead of the one that held the answer.

Nobody catches it right away. The sentence that comes back reads fine and sounds like someone who read the whole file. It's wrong, and stays wrong until a reviewer or an angry customer traces it back to source.

GPT-5.6 lands in the middle of that habit, and a bigger window just makes it tempting again.

Sol, Terra, Luna, and the same old context tax

OpenAI ships GPT-5.6 as three tiers, Sol, Terra, and Luna, each with a 1.05M token window and its own price-performance slot, Terra in the balanced middle. Test against gpt-5.6-sol / terra / luna, and check current docs before committing to code: aliases and prices shift after articles like this go up. None of that is the interesting part. The real question a 1.05M window forces on you: does the extra context supply evidence that bears on the answer, or does it just add cost and prefill latency while the model wades through material it never needed?

Decide what winning looks like before you send anything

Define the unit of success before the first prompt goes out; fluency will lie to you. For extraction that's a schema-valid record whose fields trace to source text. For coding it's a patch that passes tests and survives review. For research it's a claim set where every claim points at something checkable. None of the three care whether the prose reads nicely.

The test itself is boring: bucket prompts by length, plant known evidence at different positions, measure recall, and compare against retrieval-based loading. Keep the full request intact: system instructions, tool schemas, files, sampling and reasoning settings, and output cap, since a model looks different when one harness gets native tools and another gets pasted terminal output. Hold the workflow steady and let each provider use its own documented format. What you log along the way:

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

The window doesn't vet what's inside it

The expensive mistake is treating the advertised maximum as an architecture decision, then discovering the fact you needed drowned among six copies of the same paragraph. Frontier models make this hard to catch: almost every answer looks plausible on a skim. Measure what ordinary code can verify, get a reviewer to label real defects instead of vibes, and keep the wrong outputs around. A pile of failures teaches more about routing than another folder of clean successes.

Capacity does not remove prefill time, reduce retrieval noise, or separate trusted instructions from documents pulled off the web. If the API supports caching, put stable prefixes first and keep volatile metadata off the cache boundary; skip a full conversation history when a structured checkpoint says the same thing for fewer tokens. Ask for restraint on the way out too: a short decision plus evidence costs less to generate and review than a document the model decided you wanted.

Tool use raises the stakes, not lowers them. A better model might pick the right function more often, but your app still validates arguments, authorizes the caller, caps side effects, and records what happened. Web pages, files, emails, and tool output are data, not instructions, however well-formatted. A sharper model is no substitute for a narrower interface, and I wouldn't trust one to be, this year or next.

Escalate on evidence, not on vibes

The rule worth keeping is small: retrieve the smallest evidence set that answers the question, and reserve the huge window for tasks that prove, on your own eval set, they need it. Put that in configuration, not in whoever likes the newest name. Log model identity, phase timings, token categories, and pass/fail results, and skip storing sensitive prompt content by default.

Run a cheap, fast lane for routine traffic and a real escalation condition for the rest. The top tier earns its keep on tasks its extra reasoning changes the outcome of; sending it everything the gateway can route is just an expensive way to be thorough. I wouldn't run the frontier tier against a task the mid tier already clears, that's paying for reassurance, not capability. A cheap tier stops being cheap once its retries and review outrun the inference bill it was meant to save.

Treat migration as routine maintenance, not a special event: pin dated versions where stability matters, watch deprecation notices, canary any alias before it touches all traffic, and keep a known-good fallback wired up, because model migrations tend to go worse than the release notes promise. Re-run your eval set whenever the model, prompt, or reasoning default changes underneath you.

So here's the trade, made on purpose: you give up shoveling every document you own into the window and trusting the model to sort it out. In exchange you get a system that fails visibly and cheaply instead of invisibly and expensively, at the cost of the retrieval work and the hours spent catching outputs nobody flagged the first time. I'd rather pay that cost up front than hear about it from a customer.