Code Mode: When Your Agent Stops Calling Tools and Starts Writing Programs

Every tool call your agent makes is a round trip through the model. Full tool definitions in context, a JSON request out, a JSON response back, repeat for every step of a multi-step task. That pattern works fine until you scale past a handful of tools, at which point the token bill and the latency both start to hurt. A different pattern is converging across multiple companies right now: instead of calling tools through the model, the agent writes code that calls tools directly, and only the result comes back into context.

The token math nobody was watching

Anthropic published a concrete before-and-after. A workflow that previously ran through direct tool-calling consumed about 150,000 tokens once you counted tool definitions and intermediate results passed back through the model. Reimplemented with code execution against filesystem-based MCP APIs, the same workflow used about 2,000 tokens. That's a 98.7 percent reduction, and it wasn't a synthetic benchmark, it was the same task with a different execution model.

Cloudflare landed on the same design independently, at a scale that makes the pattern's necessity obvious. Their MCP server exposes access to the entire Cloudflare API, over 2,500 endpoints, through exactly two tools: search() and execute(). Their own writeup is blunt about why: "With just two tools, search() and execute(), the server is able to provide access to the entire Cloudflare API over MCP, while consuming only around 1,000 tokens." Two companies, working separately, arrived at the same architectural answer. That's usually a sign the old pattern had a real ceiling, not just a rough edge.

Progressive disclosure, not smarter prompting

The mechanism underneath both examples is progressive disclosure of tools. In the direct tool-calling model, every tool definition sits in context from the first token, whether the task needs it or not. A 40-tool MCP server means 40 tool schemas loaded before the agent has read the user's request. Code execution flips this: tools are represented as files or functions the agent can explore on demand, the same way a developer reads an SDK's directory structure instead of memorizing every method signature before writing a line of code. The agent lists what's available, reads the specific interface it needs, writes code against it, and only the tools actually used ever consume context.

This is the part that's easy to undersell as a minor efficiency trick. It's actually a change in what the model is doing. In direct tool-calling, the model is choosing from a menu on every step. In code execution mode, the model is programming against an API surface once and letting a runtime execute the resulting logic, including loops, conditionals, and intermediate variables that never touch the model's context window at all.

The platform is catching up to the pattern

This stopped being a clever workaround the moment Anthropic started building it into the product. Their advanced tool use update cites their own earlier post directly: "Our blog article on using code execution with MCP discussed how tool results and definitions can sometimes consume 50,000+ tokens before an agent reads a request. Agents should discover and load tools on-demand, keeping only what's relevant." That's a vendor telling you the default tool-calling pattern doesn't scale and that progressive disclosure is the intended fix, not a niche optimization for teams with unusually large tool catalogs.

For teams deciding whether to build this themselves or wait for platform support, that's useful signal. The pattern is moving from field-tested hack to first-class product direction. Waiting has a cost too, though, because the teams building it now are the ones figuring out the operational tradeoffs before the tooling is fully mature.

The pushback is legitimate, not noise

Not everyone thinks the filesystem metaphor is the right abstraction, and the objection deserves a real hearing rather than a dismissal. In the MCP community's GitHub discussion, one practitioner put it directly:

The article proposes mapping MCP servers to a local file system so agents can 'discover' tools by listing directories and reading files. This feels like a workaround. An intelligent agent can already dynamically determine which servers to use based on high-level server descriptions.

The counterargument is worth sitting with. A filesystem is a familiar mental model for humans, but it's an arbitrary one for a model that could, in principle, route to the right server based on a good description without needing to "browse" anything. The honest answer, from production experience, is that both are right in different regimes. Filesystem-style discovery earns its keep when the tool surface is large and heterogeneous, like Cloudflare's 2,500 endpoints, where no amount of clever description writing avoids the need to explore. Server-level routing wins when you have a small number of well-scoped servers and the overhead of code generation per call isn't worth paying. Treating this as a universal pattern instead of a scale-dependent one is where teams get it wrong in both directions.

The part nobody's pricing in

Here's the part that matters most for anyone actually running these systems in production, and it's the part that doesn't show up in the token-savings headline. Letting an agent write and execute code to call tools means your agent runtime now needs to be a code execution platform, not a chat completion API with function-calling bolted on. That reintroduces every problem a studio building agents already thinks about for other reasons, except now it's showing up as a side effect of a cost optimization instead of a deliberate feature decision.

• Execution isolation: arbitrary generated code needs a sandbox with real resource limits, not a shared process
• Permission scoping: code that calls tools programmatically can call more of them, faster, than a human reviewing each JSON call would notice
• Auditability: you need a record of what code ran and what it touched, not just what the model "said" it would do
• Artifact and intermediate-state storage: results that never re-enter model context still need to live somewhere durable and inspectable
• Failure handling: a stack trace from generated code is a different debugging problem than a malformed JSON tool call

Community implementations are already running into this. One open-source project building on Anthropic's base pattern explicitly added "Container Sandboxing: Optional rootless isolation with security controls" as a first-class feature, not an afterthought. That's the tell. The moment code execution against tools becomes the default pattern, sandboxing stops being a security nice-to-have and becomes table stakes for shipping at all, the same way you wouldn't run untrusted user code in a web app without a sandbox regardless of how much it saved on compute.

Script reuse compounds the savings, and the risk

The next optimization on top of code execution is reusable, parameterized scripts instead of generating fresh code for every call. One reported implementation saw a 99.6 percent token reduction after moving from one-off code generation per invocation to a library of reusable scripts the agent could call with different parameters. That's a meaningful jump even past the base pattern, because code generation itself has a token cost, and skipping it for common operations compounds the savings from progressive disclosure. It also compounds the operational surface. A library of reusable scripts is effectively a codebase your team now owns, versions, and reviews, sitting between the model and your actual systems. It needs the same code review discipline as anything else that touches production data, and it needs a way to detect when a script has drifted from what the underlying API actually expects. Treating agent-generated scripts as throwaway artifacts because they came from a model, rather than as production code, is how teams end up debugging a subtle parameter-mismatch bug three months after nobody remembers writing the script in the first place.

What this changes about the build decision

The practical question for a team shipping this quarter isn't whether code execution with MCP is better than direct tool-calling in the abstract. It's whether your tool surface is large enough that the token math justifies the added infrastructure. A three-tool internal agent doesn't need progressive disclosure or a sandboxed execution runtime; the direct pattern is simpler and the savings wouldn't be worth the operational cost. A team wiring an agent into dozens of internal APIs, or into a platform like Cloudflare's with thousands of endpoints, is well past the point where direct tool-calling scales, and the token numbers make the case on their own.

Where teams get this wrong is treating code execution as a prompting technique they can adopt without touching their infrastructure. It isn't. It's an architecture decision that turns your tool-serving layer into something closer to a code execution platform, with everything that implies about isolation, permissions, and audit trails. The token savings are real and well documented. The bill for making them safe to run in production is the part that hasn't been written up yet, and it's the part that decides whether this pattern actually ships or just looks good in a benchmark post.