Code Mode Token Savings
- title
- Code Mode Token Savings
- type
- summary
- summary
- One script against 26 tool calls on agent-swarm's own production data β a self-measured 99.2% cut
- tags
- agentic-coding, mcp, cost, llm
- sources
- code-mode-token-savings
- created
- 2026-07-29
- updated
- 2026-09-13
The Agent Swarm team measured the "code mode" idea against their own production workload and published the arithmetic. The result they lead with is a 99.2% reduction in what reaches the model's context, and the number is a vendor measuring its own product on its own data, which they acknowledge and partly compensate for by showing every intermediate figure. The methodology is the interesting part; the headline is not independently reproducible.
The lineage is stated up front. Anthropic's code execution with MCP piece put a task at 150,000 tokens through raw tool calls versus 2,000 through generated APIs in a sandbox, a 98.7% cut, on the principle that intermediate results stay in the execution environment and the agent sees only what you log or return. Cloudflare shipped the same idea in September as Code Mode and later measured 2,500+ API endpoints going from 1.17M tokens to about 1,000. Agent Swarm's contribution is not the idea β they already ship a rubric in every session's system prompt (system.agent.context_mode) telling the agent that ten or more items, or a bulk fan-out, means write a script rather than fire N tool calls β but a measurement of it against Anthropic's yardstick with real data.
The workload
The subject is workflow-triage, a script two of their own agents wrote and which any agent in the swarm can call. It scans every workflow and cron schedule and flags each one dead, failing or fine. That is 26 calls against their production catalog of 24 workflows and 60 schedules: one workflow_list, one schedule_list, and one workflow_listRuns per workflow. Done by hand, all 26 raw JSON payloads land in the agent's context and stay there for the rest of the conversation. Run as a script, the same 26 calls happen inside a sandboxed subprocess and one summary object comes back.
There is no framework involved, which they point out themselves. The script is a loop with a concurrency pool of six, some Date.parse, a sort, and a return. The only thing making it code mode is where the calls run: every ctx.swarm.workflow_listRuns result lands in a local variable, never in the transcript.
The numbers, and which are measured
The script side is measured exactly: one call, durationMs: 13120, a 25,811-character result, about 6,450 tokens at four characters per token (they had no tokenizer available), roughly $0.02 at Claude Sonnet 5's $3 per million input tokens.
The raw side is measured then extrapolated, and they are explicit about the seam. The two list calls were run for real: workflow_list({}) returned 16,304 characters and schedule_list({}) returned 72,105. For the per-workflow runs they sampled four workflows spanning small to large β 6 runs at 98,706 characters, 26 runs at 293,036, 53 runs at 157,720, and 227 runs at 525,968 β for 1,075,430 characters across 312 sampled runs, a mean of 3,447 characters per run. Applying that mean to the 920 runs the script itself recorded across all 24 workflows gives about 3.17M characters, plus the two list calls, for roughly 3,259,649 characters or about 815,000 tokens: $2.44 at the same rate, and a 126x ratio.
Two caveats are theirs and one is arithmetic. They declined to actually run all 26 raw calls, since doing so would pull 3.2 million characters of JSON into the very conversation used to write the post β the same judgement call the rubric asks an agent to make. They also flag that limit: 25 passed to workflow_listRuns does not cap anything; the busiest workflow returned all 227 runs, which makes the raw number a floor rather than a ceiling. And the $2.44 is a floor for a different reason: it prices the tokens once, as though everything entered context on a single turn, where a real 26-turn loop re-sends each result as input on every subsequent turn. They say they cannot defend a precise multiplier without running the wasteful version, which is the honest place to stop.
The arithmetic caveat they do not raise is what the sampled mean is made of. Per-run payload size in their own sample runs from about 16,451 characters (98,706 over 6 runs) down to about 2,317 (525,968 over 227), and it moves inversely with run count β the busiest workflows have the smallest payloads per run. Pooling those into one 3,447-character mean and multiplying by 920 runs weights the extrapolation toward the sparse, fat-payload workflows, so the raw-path estimate probably runs high. That cuts against the floor arguments above rather than adding to them, and the direction of the combined error is not determinable from what they published.
The cross-model table is a straight conversion of the same two token counts at five providers' direct API input rates from their live pricing cache, verified on the publication date: claude-opus-4-8 at $5.00/M ($0.032 vs $4.08), claude-sonnet-5 at $3.00 ($0.019 vs $2.44), claude-fable-5 at $10.00 ($0.065 vs $8.15), gpt-5.5 at $5.00 ($0.032 vs $4.08), glm-5.2 at $1.40 ($0.009 vs $1.14). Since both columns scale with the same rate, the table adds price levels but no new evidence β as they say, the reduction is a token-count story rather than a pricing one.
What it does and does not settle
The mechanism is not in dispute and does not need their measurement to be true: data that never enters the transcript is never paid for, and never crowds the window. That is the same move as agent-built-deterministic-tools, where the LLM writes a deterministic analyzer once and all later agent work is constrained to its output β workflow-triage is literally that artifact, written by agents and now called as a tool. It also sharpens the service-access half of mcp-vs-skills: a raw MCP tool surface is the thing being replaced here, not the thing being used.
The unpriced half is the interaction with prompt-caching-in-agents. Their $2.44 floor assumes the raw path's 26 results are billed once, and they say a real loop would cost meaningfully more because each result re-enters the input on every turn. With a working prompt cache those re-sends are charged at the discounted cache-read rate rather than the full input rate, which is precisely the multiplier they declined to name. It also runs the other way: a script call is one append to a stable prefix, so code mode is cache-friendly in a way that a 26-turn fan-out is not, and neither effect appears in the table. And on the reading side, ai-token-budget-explosion describes enterprises with no usable per-task cost measurement at all β this post is a small, self-interested, and unusually well-documented instance of exactly that measurement being attempted.
portal-shunt-token-routing applies the same keep-it-out-of-the-transcript move to file reads, sending them to a cheaper model through Claude Code hooks.