GPT-5.6 Sol Rewrote OpenAI's Production GPU Kernels. The Tool They Built to Check It Is the Real Story.

OpenAI credits a 20% serving-cost cut to kernels its own model wrote. The interesting sentence in that post is about a sanitizer, not a savings number.

There is a sentence in OpenAI's July 29 engineering post that most of the coverage skipped over. Right after explaining that GPT-5.6 Sol autonomously rewrote its production GPU kernels, the post adds this: "We've also heavily invested in verification tooling, such as the open-source tool FpSan (Floating-Point Sanitizer), to help validate the correctness of the kernels written by GPT-5.6 Sol."

Read that again with an engineering hat on. A model wrote the low-level code that runs OpenAI's inference stack. Nobody at OpenAI is going to line-review a fleet of Triton kernels the way you review a colleague's pull request. So they built a checker instead. The kernels were the headline. The sanitizer is the actual news, because it tells you what changes when an agent writes the code your system depends on.

The 20% number is not the part you can use

OpenAI's post reports that kernel work by GPT-5.6 Sol, combined with broader kernel advancements, cut end-to-end serving costs by 20 percent, and that improvements to the speculative-decoding draft model raised token-generation efficiency by more than 15 percent. Those are self-reported vendor figures on a proprietary stack. You cannot reproduce them, you cannot audit them, and they landed one day before OpenAI cut Luna's API price by 80 percent, which gives the company an obvious reason to want that framing to stick.

So set the numbers aside and look at the shape of the work, because the shape is portable and free.

Every task OpenAI handed to the model has the same profile. Load balancing: analyze production traffic, find imbalance, test routing strategies, tune heuristics. The forward pass: find work that can be precomputed, avoided, or parallelized. Serving configuration: the post says outright that "the configuration space was previously too large to tune systematically, forcing engineers to rely on broad heuristics." The speculator model: GPT-5.6 Sol "designed and ran hundreds of experiments on its architecture, testing changes in size, structure, and features," then launched the training runs and intervened when hardware failed.

None of that is creative work. All of it is search over a space too large for a person, against an objective that a machine can measure without asking anyone's opinion. Latency went down or it did not. Throughput went up or it did not. That combination, huge search space plus a cheap and unambiguous scoring function, is where agents are currently at their strongest, and it is nothing like "write me a feature."

Here is the trap that comes with it. A wrong kernel is not a crashing kernel. It is a fast kernel that returns numbers slightly off in the last few bits, which propagates through a transformer and shows up weeks later as a model that feels a little dumber on long inputs and passes every unit test you own. Floating-point arithmetic breaks in exactly the silent way that agent-written code needs it not to. That is why the verification tool is named for floating point specifically and lives in the Triton toolchain, alongside the language OpenAI trained the model to write.

The bottleneck moved from writing to checking

If a person writes a kernel, the review is the diff. Someone who understands memory movement reads the code and forms a judgment. That process does not survive contact with a model that can propose a hundred candidate kernels a day. Volume kills line review.

What survives is a checker. Not a human reviewer with more coffee, and not a second model asked whether the first model's work looks right. A deterministic instrument that answers a narrow question about correctness the same way every time. OpenAI's answer to "can we trust the machine-written kernel" was to build the instrument, open-source it, and let the model produce as much as it wants behind that gate.

This is the transferable idea, and it applies at every scale down to a solo project. The question for your own agent work is no longer "can the model write this." For a growing class of tasks, it can. The question is what your FpSan is. What is the deterministic thing that fails loudly when the agent's output is subtly wrong, and does it exist before you point the agent at the problem?

Most teams building agent loops right now have this backwards. They spend the effort on the prompt, the tool definitions, the retry logic, and then review the output by reading it. That works at ten outputs a week. It falls apart at a thousand, which is exactly the volume cheap tokens are pushing everyone toward.

The harness patterns are the free part

The second half of OpenAI's post is about the Rust orchestration layer behind Codex and ChatGPT Work, and it hands over three design decisions with no vendor attached.

Deferred discovery. The harness makes integrations, custom MCP tools, skills, and plugins "only surfaceable when needed" rather than resident in context from turn one. Notice why this exists. OpenAI's own words: as agents get access to more tools, skills, plugins, and history, "context windows can easily expand," which "increases cost, distracts the model, and prompts unnecessary reasoning." That is a confession. The skill and plugin ecosystem, nine months old, already bloats context badly enough that the largest agent vendor had to build lazy loading to survive it.

A tool output cap. Tool output is capped at 10,000 tokens by default unless the model asks for a different limit. One MCP server returning a 200,000-token JSON blob can eat a turn. The cap with a model-requestable override is a better design than a hard truncation, because the model can escalate when it actually needs the whole thing.

Append-only history. New messages, tool results, and environment updates go at the end. Nothing gets inserted into earlier context. Tools are presented in a deterministic order, and runtime settings like approval policies are applied at execution time rather than baked into tool definitions. All of that exists to keep the prompt-cache prefix byte-identical across the many model calls inside a single user turn.

That last one is the cheapest useful change most people can make to an existing loop, and it is also the one with a conflict OpenAI does not mention: append-only and mid-turn compaction are incompatible. The moment you summarize or rewrite earlier context to fit a long run, you have invalidated the prefix you were protecting. Pick one per turn, deliberately.

Put this into practice

Nothing here needs a Codex subscription. Four steps, roughly in order of payoff.

1. Write the objective function down before you start. Take one optimization task you have been meaning to hand an agent. Write one sentence naming the number that must move and the numbers that must not get worse. If you cannot write that sentence, the task is not ready for an agent and no prompt will fix it.

2. Build the checker first. Your version of FpSan is usually a differential test: run the agent's output and a known-good reference implementation on the same inputs, compare within an explicit tolerance, and fail the run on any drift. Write it, then confirm it catches a bug you introduce on purpose. An unverified verifier is worse than none, because it launders bad output as checked output.

3. Port the three harness patterns. Stop loading every MCP server and skill on turn one; register them and surface them on demand. Add a token cap on tool results with a documented way for the model to ask for more. Then read your own turn-two payload and confirm the prefix is byte-identical to turn one. That last check takes ten minutes and usually finds something, because most loops reorder tool definitions somewhere or stamp a timestamp into the system prompt.

4. Log the rejection rate. Record how many agent proposals your checker threw out. That ratio is the honest measure of whether the loop is working, and it is the number OpenAI did not publish.

Honest limitations

Every figure in the post is OpenAI's own, measured on hardware nobody else can see, with no methodology, no baseline description, and no error bars. Twenty percent against what, over what workload mix, over what window, is not stated.

"Autonomously" is doing heavy lifting. Codex at OpenAI runs inside a team of infrastructure engineers with review processes the post does not describe. The honest version is that the model did the search and the writing, and humans somewhere set the objectives, staged the rollouts, and could revert. Read it as extremely high-quality machine-assisted engineering, not as a system left alone with production.

FpSan validates numerical correctness. It has nothing to say about whether a kernel is fast, safe, maintainable, or introduces a side channel. The checker covers exactly the failure mode it was built for, which is the point and also the boundary.

The post gives no per-pattern numbers for the harness section. Deferred discovery, the tool cap, and append-only history are presented as design choices that "contribute to Codex's and ChatGPT Work's high overall prompt-cache hit rates," with no isolated measurement. You are copying a design, not a result, so measure it in your own loop or you have not learned anything.

There is also no disclosure of how many model-written kernels were rejected, how many shipped and were rolled back, or whether any subtle numerical regression made it to users before being caught. A post about verification tooling that reports no defect rate is telling you about the process and not the outcome.

Where this leaves you

The claim worth taking seriously from July 29 is not that a model can write GPU kernels. It is that a company with the best engineers in the field looked at machine-written systems code, concluded that human review does not scale to that volume, and responded by building an instrument. That is a real answer to a real problem, and it is the one part of the story you can copy this week without permission or a budget.

Go find the one place your agent's output is currently checked by someone reading it, and ask what would have to be true to check it with a program instead. If the answer is "nothing, the output is a judgment call," then keep the human and stop scaling that loop. If the answer is a tolerance, a schema, or a reference implementation, you already know what to build next.

Sources: OpenAI, "How GPT-5.6 fuses frontier intelligence with frontier efficiency" (July 29, 2026); Triton documentation; The New Stack, "Kernel of truth: GPT-5.6 Sol can cut its own costs, says OpenAI".