Programmatic tool calling: why AI agents increasingly call their tools through code
With programmatic tool calling, the model writes code that calls tools, and intermediate results stay out of the context. Sometimes 99% fewer tokens, sometimes more expensive.
Say your agent has to find out which team members went over their travel budget in Q3. With regular tool calling, the model fetches the team, then each person's expenses, then the budgets. All of that data, more than two thousand expense lines in Anthropic's example, ends up in the context window. The answer you want is two or three names.
Programmatic tool calling flips that around. The model writes a script that calls the tools, the script filters the data in a sandbox, and only those two or three names come back into the context. Anthropic introduced it in November 2025 as a beta feature. Since 17 February 2026, the day Claude Sonnet 4.6 came out, it has been generally available, and Claude now filters web search results the same way.
Is this the future of tool calling? For some agents, yes. For others it actually costs more.
As of 25 September 2026. This article was prompted by the video Anthropic Just Killed Tool Calling from the YouTube channel Prompt Engineering. The numbers below come from the primary sources at Anthropic and Cloudflare.
What is programmatic tool calling?
With programmatic tool calling, a language model doesn't call tools one at a time. It writes code that calls them. That code runs in an isolated environment. Intermediate results stay there, and only the script's output goes back to the model. That saves tokens and round trips between model and tools.
Regular tool calling goes like this:
- All tool definitions sit in the context up front.
- The model requests one tool call, as JSON.
- Your code runs it and sends back the full result.
- The model reads that result, and requests the next call.
Every call is a full round trip through the model, and every intermediate result stays in the context window. You pay for it, and the model has to wade through it again at every next step.
Why code instead of JSON?
Cloudflare made the argument most people remember in September 2025. Language models have seen huge amounts of real code, but very few synthetic tool calls. Their comparison: making a model work through tool calling is like putting Shakespeare through a month-long class in Mandarin and then asking him to write a play in it. Cloudflare calls the approach Code Mode.
A little over a month later, Anthropic applied the same idea to MCP servers, with a nod to Cloudflare. Present the tools as code APIs and let the model write a script. In their example, an agent pulls a meeting transcript from Google Drive and attaches it to a lead in Salesforce. Normally the full transcript passes through the context twice. Through code, usage dropped from 150,000 to 2,000 tokens, a 98.7 percent saving.
On 24 November 2025 the feature arrived in the Claude API itself: programmatic tool calling.
How does it work in the Claude API?
You give the model the code execution tool and mark each tool that may be called from code, using the allowed_callers field:
"tools": [
{ "type": "code_execution_20260120", "name": "code_execution" },
{
"name": "query_database",
"description": "Runs a SQL query. Returns rows as JSON.",
"input_schema": {
"type": "object",
"properties": { "sql": { "type": "string" } },
"required": ["sql"]
},
"allowed_callers": ["code_execution_20260120"]
}
]
The model then writes Python that calls query_database, say, three times, for three regions, and combines the results. Your application still executes every call itself. The difference is that the results go to the script, not to the model. According to the documentation, those intermediate results don't count as input or output tokens. Only the script's output and the model's response count.
How much does it save?
The numbers vary widely, and that's exactly the lesson:
| Situation | Result | Source |
|---|---|---|
| Cloudflare API (more than 2,500 endpoints) via Code Mode | about 1,000 instead of 1.17 million input tokens (99.9% fewer) | Cloudflare |
| MCP example, Google Drive to Salesforce | 150,000 to 2,000 tokens (98.7% fewer) | Anthropic |
| Complex research tasks | 43,588 to 27,297 tokens on average (37% fewer) | Anthropic |
| Project-management agent with 75 tools | about 38% fewer billed input tokens, same accuracy | Anthropic docs |
| Production traffic with 10 to 49 tools per request | typically 20 to 40% fewer tokens | Anthropic docs |
| τ²-bench: one or two sequential calls per turn | same score, about 8% more expensive | Anthropic docs |
The extreme savings come from situations with huge tool definitions or large intermediate results. For an agent that calls one or two tools in sequence per turn, it gains nothing and even costs more: starting the container and writing the script cost more than you save.
Dynamic filtering: the same trick for web search
Alongside Sonnet 4.6, Anthropic applied the principle to its own web search and web fetch tools. Search results and whole HTML pages used to go straight into the context. Now Claude first writes code that filters the results, and only what's relevant goes through.
On BrowseComp, a benchmark where an agent has to find information that is deliberately hard to find, Sonnet 4.6 went from 33.3 to 46.6 percent. Opus 4.6 went from 45.3 to 61.6 percent. That's a gain of 13 and 16 percentage points. Averaged over BrowseComp and DeepsearchQA, performance improved by 11 percent with 24 percent fewer input tokens.
Is it always cheaper?
No. You save on input tokens, because raw data no longer enters the context. But the model now has to write code, and those are output tokens, which cost more. Anthropic says so itself: with dynamic filtering, price-weighted tokens went down for Sonnet 4.6 on both benchmarks but went up for Opus 4.6. Costs depend on how much code the model writes to filter the context.
The Prompt Engineering video explains this as "Opus is a perfectionist and writes too much code". That's an interpretation; Anthropic doesn't name a cause.
What to watch out for
- It suits certain tasks. According to Anthropic it helps with many parallel calls (checking fifty endpoints, looking up twenty records), with large results you can filter or summarise, and with search and research tasks. It doesn't help with strictly sequential steps where the model has to reason over each previous result, or with a few small calls.
allowed_callersis not a security boundary. The documentation says so literally: the model is strongly guided to respect it, but it isn't a hard block. Your code must also handle a direct call to that tool.- Not everything works. Tools from an MCP connector can't be called programmatically. Neither can tools with
strict: true(structured outputs) or schemas with a recursive$ref. - Data in the sandbox is input for code. If a tool returns external data or user input, watch out for code injection.
- Measure it. Anthropic itself recommends comparing billed input tokens with and without
allowed_callerson a representative sample of your traffic before turning it on everywhere.
So: the future of tool calling?
The old pattern isn't going away. An agent that calls one tool and has to think about the answer is still better off with regular tool calling. But an agent with dozens of tools, lots of data or lots of parallel work pays, with regular tool calling, for tokens nobody reads. For that kind of agent, code is the logical layer between model and tools. Cloudflare came up with the pattern, and Anthropic built it into its own API within two months. If you build agents with many tools, start measuring now rather than waiting for it to become the standard.
