GPT-5.6 Rewrote Its Own GPU Kernels. The Reviewer Was a Floating-Point Sanitizer.

OpenAI cut GPT-5.6 Luna 80 percent on July 30, to $0.20 and $1.20 per million input and output tokens, about three weeks after general availability. Terra fell 20 percent. Sol, the flagship, did not move.

The efficiency that paid for it came from Sol itself, driven through Codex: production kernels rewritten in Triton and Gluon for 20 percent off end-to-end serving cost, plus a redesigned speculative-decoding draft model worth more than 15 percent in token-generation efficiency.

The part worth copying is not the discount. It is FpSan, the floating-point sanitizer OpenAI built to validate kernels that no human wrote line by line.

What actually changed on the invoice

Luna was $1 in and $6 out per million tokens. It is now $0.20 and $1.20. Terra went from $2.50/$15 to $2/$12. Sol stayed at $5/$30.

The cuts apply across batch, cached input, and long-context requests, so this is a repricing rather than a promotional rate with conditions buried in it. Bedrock customers get whatever Amazon decides to bill.

The day before the price change, OpenAI published the engineering post explaining where the money came from. That post is the more interesting document.

The model optimized the stack that serves it

OpenAI pointed GPT-5.6 Sol, running under Codex, at its own production GPU kernels. Kernels are the low-level code that executes the matrix operations a model is made of. Sol was trained specifically to write them in Triton and Gluon, the two GPU languages OpenAI maintains. It rewrote and optimized them, and combined with broader kernel work, end-to-end serving cost dropped 20 percent.

Sol also redesigned its own speculative-decoding draft model. Speculative decoding runs a small model to guess the next few tokens and the large model to check the guesses, and the draft model's design determines how often a guess survives. Sol ran hundreds of experiments on that design. OpenAI credits the result with more than 15 percent better token-generation efficiency.

Twenty percent off serving and 15 percent more throughput is a lot of margin to find in a stack that a well-paid infrastructure team has already been over several times.

Kernels are the worst possible thing to hand an agent

That is what makes the story useful rather than just impressive.

Most code fails loudly. A kernel fails quietly. A rewritten attention kernel that is correct to six decimal places and wrong at the seventh will pass every unit test you have, ship, and turn up eight weeks later as a small quality regression that you will spend a month blaming on your data pipeline. There is no stack trace. There is no failing assertion. The output looks like output.

Reviewing that by reading the diff does not work, and it does not work for a senior engineer either. You cannot eyeball numerical drift in a fused CUDA kernel.

So OpenAI did not try. It built FpSan, an open-source floating-point sanitizer, to check the numerical behaviour of kernels the model produced. The model writes, a tool proves. Nobody sits in the middle reading Gluon at the rate an agent can emit it.

This is the bar problem, in production

The human job in this setup splits cleanly. Someone decided what correct means for a kernel, in machine-checkable terms. Someone else, or the same person, built the thing that enforces it on every candidate. Specify before, verify after. The middle went to the agent.

The generalizable lesson is not "use agents on your infrastructure." It is that once generation is faster than review, review is the only thing left to engineer. You do not solve that by reading faster or by adding a second reviewer. You solve it by converting review into something executable.

For a normal team that means the unglamorous list: property tests, differential testing against the implementation you are replacing, invariant assertions on the boundaries, golden outputs on real traffic. It is boring work and it is now the actual work.

There is an important asymmetry to notice before copying this wholesale. Kernels have a ground truth. A kernel either computes the same numbers as the reference or it does not, and that question has a mechanical answer. Most application code has no such oracle. Whether a checkout flow is right is not a floating-point comparison.

So the question to ask about your own codebase is which parts do have a checkable invariant. Data transformations, migrations, parsers, serializers, pricing calculations, anything with an old implementation still running next to it. That is where agent-written code can go first, because that is where you can hold the bar without reading every line. Everywhere else, the review bottleneck is still real and pretending otherwise is how you get the quiet failure.

What the price cut does to your architecture

The spread between the cheapest and most expensive tier went from 5x to 25x. That number does more to your design than the headline percentage does.

Take a workload doing 10 million input and 2 million output tokens a day. All Sol, that is $110 a day. Move 70 percent of it to Luna and Sol costs $33 while Luna costs $3.08, so about $36 a day.

Under the old prices, the same split cost roughly $48, of which Luna was $15. Luna's share of the bill went from about a third to under 9 percent.

That is the shift. The decision is no longer mainly whether to route between tiers, which was already worth doing at 5x. It is what you can now afford to do redundantly on the cheap tier. Running Luna three times and taking the majority answer costs less than a single Terra call. Pre-filtering every inbound request through Luna before it reaches anything expensive is close to free. Reranking retrieval results with a model instead of a heuristic stops being a line item. Cached input and batch get the same discount, so an overnight Luna job on a warm cache is now priced like nothing.

Repeated sampling on a small model has been the quiet winner in several results this year. This price makes it the default rather than the clever option.

Price per token is still the wrong number

Simon Willison made the point that price per million tokens tells you less than it used to, because reasoning token counts differ enormously between models on the same task. A model at a fifth of the price that thinks four times as long has saved you nothing.

Before migrating anything, take 200 real requests off your own traffic, run them through both tiers, and count total tokens including reasoning, plus how many answers came back acceptable. Cost per completed task is the number. Cost per call is marketing.

What this does to a twelve-month forecast

Inference prices used to fall roughly when new hardware shipped. That was a cadence you could plan around.

This cut arrived three weeks after general availability, funded by a model rewriting the code that serves it. If a lab can find 20 percent in its own serving stack on an internal schedule, price movement decouples from hardware generations entirely.

Two practical consequences. Be careful signing twelve-month committed spend at today's rates. Be equally careful building elaborate cost optimizations that a repricing makes pointless a month later. The cheapest optimization right now is the one you can undo.

The headline is a discount. The mechanism is that a machine wrote kernels into production and a sanitizer decided they were fit to ship. Once that pattern holds at one lab, the number on your invoice is set by automation you do not control, and the interesting question stops being what it costs and becomes who checked.