- GPT-5.6 introduces programmatic tool calling, where the model writes JavaScript to orchestrate tools in a sandbox instead of doing step-by-step tool calls through repeated model turns.
- The main cost in classic agents is the tool loop itself: every hop re-sends context and often dumps large intermediate tool outputs into the model, driving up tokens and latency.
- Running the loop in a sandbox cuts round-trips and, more importantly, keeps intermediate data out of the prompt so the model only sees the final (or filtered) results.
- Anthropic, Cloudflare, and OpenAI have independently converged on the same pattern, signaling a broader shift toward code-based orchestration as the default agent architecture.
- Cheaper orchestration doesn’t mean better decision-making: models still have to choose the right tools and steps, and benchmark gaps show that “what to call” remains the hard part.
GPT-5.6 shipped programmatic tool calling: the model writes JavaScript that orchestrates your tools inside a sandbox, instead of emitting one tool call, waiting, then emitting the next. OpenAI measured 38 to 63.5 percent fewer tokens and, on some benchmarks, under half the time.
This is not an OpenAI idea. Anthropic shipped the same move in November as code execution with MCP and watched a 150,000 token workflow drop to 2,000. Cloudflare shipped it as Code Mode. Three labs, one conclusion: stop routing the tool loop through the most expensive part of the stack.
The catch is that cheaper orchestration is not smarter orchestration. Sol still trails Claude Fable 5 on the Toolathlon tool-use benchmark, 58 to 61.7. The plumbing got better. Deciding what to call is still the model's job, and still the hard part.
The loop was always the expensive part
For two years the standard agent worked one way. You hand the model a list of tools. It picks one, emits a JSON call, you run it, you feed the result back, and the conversation goes around again. Every hop re-sends the full context through the model. A five-step task means five trips through the most expensive component you are paying for.
That loop is where the money goes. Not the thinking, the bookkeeping. A tool that returns 4,000 rows of JSON dumps all 4,000 rows into the model's context whether the model needed them or not, and you pay for every token on the way in and again on the way out.
Programmatic tool calling changes where the loop runs. Instead of pinging the model on every step, GPT-5.6 writes a small JavaScript program that calls the tools itself, runs it in an isolated V8 runtime with no network access, and returns only the result. The model plans once. The sandbox does the looping.
Why it is cheaper than it looks
Two things happen, and the smaller one gets the headlines.
The obvious saving is round-trips. Five model calls collapse to one. Fewer hops, lower latency, fewer tokens re-sent on every turn.
The bigger saving is that intermediate data never touches the model. When the loop runs in a sandbox, those 4,000 rows stay in the sandbox. The model only sees what the code chooses to return, maybe the three rows that matter. Anthropic put a number on this when they shipped the same pattern in November: a workflow that cost 150,000 tokens as a normal tool loop dropped to 2,000 when the agent wrote code instead. That is a 98.7 percent cut, and almost none of it is about round-trips. It is about data that never entered the prompt.
OpenAI's numbers are more modest because they are measuring a different mix of work: 38 to 63.5 percent fewer tokens, and under half the time on some benchmarks. On the Artificial Analysis coding index, Sol posts top results using less than half the output tokens of its rivals.
Three labs, one conclusion
The reason this matters is not that OpenAI did something clever. It is that OpenAI is the third lab to land on the exact same idea, which is how you can tell it has stopped being a trick and started being the shape of the thing.
Anthropic published its code execution with MCP writeup in November and argued that MCP servers should reach the model as a code API, not a wall of tool definitions. Cloudflare shipped Code Mode around the same time and collapsed an entire API behind two functions, search and execute, fitting the whole surface into roughly 1,000 tokens. Both reported 30 to 40 percent latency improvements from skipping the agent loop. Now OpenAI has baked the same move into the Responses API as a first-class primitive.
When Anthropic, Cloudflare, and OpenAI independently arrive at "let the model write code instead of calling tools one at a time," the argument is settled. Models are good at writing code. Make them write the orchestration and get out of the way.
Cheaper is not smarter
The launch posts skip this part. Making the loop cheap does not make the model better at deciding what belongs in the loop.
On Toolathlon, a benchmark that measures whether a model picks the right tools and uses them correctly, Sol scores 58 percent and trails Claude Fable 5 at 61.7. The same release that makes tool orchestration dramatically cheaper also shows OpenAI behind on tool judgment. Those are two different axes, and they are worth keeping apart. Programmatic tool calling is a plumbing win. It lowers the cost of being right and the cost of being wrong by the same amount. If the model calls the wrong three tools in the wrong order, it now does so faster and cheaper.
Simon Willison, who tested the family on release day, put it plainly. Terra and Luna are strikingly cheap for what they do, but Sol did not impress him more than Claude Fable on the hard coding work he actually cares about. The efficiency is real. The intelligence gap is not closed by it.
What it changes for how you build
If you are still assembling agents the 2024 way, wiring 30 or 40 tool schemas into a system prompt and looping, this is the signal to stop.
Your tools stop being chat-visible actions and become library functions. You expose them as an API the model can import and call in code, not as a menu it rereads on every turn. That alone claws back the context those schemas were eating.
Your data governance moves too. The useful property of running the loop in a sandbox is that you decide what leaves it. Data can flow through a workflow, get filtered and joined and reduced, and never enter the model's context at all. For anyone nervous about what their agent sees, that is a bigger deal than the token bill. The thing the model never sees is the thing it can never leak.
And you get honest about where your problem actually is. If your agent is slow and expensive, programmatic tool calling helps today. If your agent calls the wrong tools, a cheaper loop just gets you to the wrong answer sooner. Fixing that still lives in your tool design and your instructions, which is the part no API primitive is going to hand you.
The model was never a good place to run a for-loop. It took three labs and a couple of years to say so out loud. GPT-5.6 is the version where it stops being a research finding and becomes the default.
If you’re building agents, consider moving from multi-turn tool calling to code-based orchestration so intermediate data stays out of the model context and you pay for fewer tokens and round-trips. Design your tool APIs so the sandbox can filter, summarize, and return only what matters, rather than streaming raw results back into the prompt. At the same time, keep evaluating tool-choice quality separately from cost, because faster plumbing won’t fix weak planning or poor tool selection.