Your Agent's Tool Outputs Are Wasting 60% of Your Token Budget

Last week we watched a Claude Code session where a developer asked the agent to "add rate limiting to the auth middleware." Standard task. The agent ran grep to find the right file, cat to read it, wrote the implementation, ran typecheck, ran tests.

50 turns. By turn 30, something had gone quietly wrong: the agent was carrying 60,000 tokens of accumulated tool output in its context. npm install logs from turn 5. A 4,000-line typecheck output from turn 12. ANSI escape codes and progress spinners from a dozen other commands.

The LLM was reading all of it. Every turn. And being billed for every token.

This isn't an edge case. It's every agent session you've ever run.

The Tool Output Problem, Quantified

In a chat application, tool calls are rare. In an agent session, they're the entire point. Here's the anatomy of a single turn in a Claude Code coding session:

Over half the context window at turn 23 is just accumulated tool output from earlier turns. None of it changed between turn 22 and turn 23. But because the API is stateless, all of it gets re-sent and re-billed.

And tool output isn't just large — it's mostly noise.

What's Actually in Your Tool Outputs

Let's look at five real tool outputs from actual agent sessions and measure what fraction is useful:

1. npm install — 99% noise

Actual useful information: "added 47 packages, removed 12 packages, found 0 vulnerabilities" — about 120 characters. The rest — deprecation warnings, the animated spinner (captured as literal ⠙ ⠹ sequences), funding nag — is pure context waste. Useful fraction: ~2%.

2. typecheck (TypeScript) — 95% noise

The first error is exactly what the agent needs to see. The second is noise from a file it hasn't touched yet. The "Errors Files" table at the bottom is a reformatted summary of the exact same data. Useful fraction: ~40% — better than npm, but still half waste. And a large project can produce 300+ lines of type errors that are 90% irrelevant to the current task.

3. grep in a large codebase — 80% noise

The agent asked for src/ — and got node_modules/ results too because grep -r is recursive. The developer knows to ignore node_modules/ hits; the LLM has to read through all of them to figure that out. Useful fraction: ~20%. The 47 node_modules lines add zero value but consume ~3,000 tokens that will persist in context for the rest of the session.

4. cat on a large file — 90% noise (but you need some of it)

The agent asked to read a file to understand the auth middleware. It probably needs lines 40-60 (where the token validation logic lives), maybe the imports at the top, and maybe the exports at the bottom. The 140 lines in between — database queries, error formatting, utility functions — are context that the LLM will read once and never reference again. But they don't disappear. They sit in context for 30 more turns. Useful fraction: ~25% — but the structure matters more than the line count.

5. curl / HTTP responses — 70% noise

The JSON body is 72 characters. The headers are 380. And the headers contain a timestamp that will be stale in 10 seconds, a request ID that will never be referenced, and rate limit counters that don't matter. Useful fraction: ~20%.

The Cumulative Effect: A 50-Turn Session

Here's what these tool outputs add up to in a real session. We instrumented 15 Claude Code sessions (median 47 turns) and measured tool output accumulation:

96,000 tokens of tool output. 78,700 of them are noise. And every one of those tokens gets re-billed on turns 48, 49, and 50 — along with all the other context. With Claude Sonnet at $3/$15 per million input/output tokens, those 78,700 tokens of waste cost roughly $0.24 every turn they're in context. Over the last 20 turns of the session, that's $4.80 in pure waste — from tool outputs alone.

Why Nobody Fixes This (It's Harder Than It Looks)

"Just strip ANSI codes" sounds easy. But real tool output is messy in ways that generalized parsing can't handle:

Format diversity. Every CLI tool formats its output differently. npm uses spinners. tsc uses structured error tables. curl mixes headers and body. git uses color diffs. docker uses progress bars. A regex that works for npm install breaks on docker build.

Context sensitivity. Sometimes the ANSI codes are the information. A git diff output loses all meaning if you strip color codes without preserving the +/- markers. Sometimes an npm warning about a deprecated package is exactly what the agent needs to see.

The "current turn" trap. You can't just strip everything. The tool output from the current turn is what the agent is actively reasoning about. Truncate it, and you amputate the agent's working memory. Only historical tool output — data from turns 1-46 while the agent is working on turn 47 — is safe to compress.

Every framework does it differently. Claude Code wraps tool outputs in Anthropic-format tool_result content blocks. Codex CLI uses OpenAI-format tool role messages. Cursor does its own thing. Each format requires different parsing. Most teams give up and accept the waste.

The result: almost nobody compresses tool outputs. They just let them pile up, turn after turn, paying the full token price for data the model read 20 turns ago and will never need again.

The Head+Tail Strategy: Keeping What Matters, Dropping What Doesn't

Synrouter takes a different approach. Instead of trying to understand the content of every tool output (which requires language-specific parsers and breaks on edge cases), we apply a structural rule that works across every format:

Here's why this works. Most CLI tool output follows a predictable structure:

• The head tells you what's happening: the command that was run, the first few results, the context. For tsc, it's the first 2-3 errors with their file locations. For npm install, it's the package additions and removals.
• The tail tells you the outcome: the summary, the exit code, the final line. For tsc, it's "Found 2 errors." For git, it's the final status line.
• The middle is repetition. For grep, it's the 47th through 100th matches — all formatted identically. For npm, it's the spinner animation and funding messages. For large files, it's the middle 80% of the file that the agent doesn't need to re-read.

The truncation marker is explicit and LLM-readable:

This tells the model: "data was here, it's been removed, you don't need it." Models trained on large contexts handle these markers naturally — they treat them the same way you'd treat an ellipsis in a quoted passage.

The Rules: What Gets Trimmed and When

Synrouter's tool output trimming follows three simple rules:

| Condition | Action | |-----------|--------| | Output ≤ 4,000 tokens | Untouched. Short outputs are usually entirely relevant. | | Output 4,000–20,000 tokens | Head 1,500 + truncation marker + tail 500. | | Output > 20,000 tokens | Same head+tail trimming, plus truncated_tokens metadata in the API response headers so you can track exact savings. |

And one critical safety rule: the most recent user message is never touched. If the agent just ran cat auth.ts and you're asking it to fix line 47, that full output stays intact. Only historical tool outputs — messages from earlier turns that are now just context — get trimmed.

This works across both Anthropic-format (tool_result content blocks) and OpenAI-format (tool role messages). Your agent framework doesn't need to know it's happening.

Real Numbers: A Session With and Without Trimming

We ran the same Claude Code session twice — a developer building a payment webhook handler over 55 turns. Once through the raw Anthropic API, once through Synrouter with tool output trimming enabled.

The tool output trimming dropped the tool output portion of the context from 1.47M tokens to 438K — a 70% reduction. The non-tool context also shrank slightly because shorter prompts mean less context window churn.

Combined With Session Caching: The Full Picture

Tool output trimming and session-lifetime caching are complementary optimizations:

Together, they transform the economics:

From $44.20 to $9.80. Same session, same agent, same results. 78% reduction.

The tool trimming alone saves 35% relative to Anthropic's native caching. It's not a minor optimization — it's a third of your API bill that you're currently paying for characters the model doesn't need to read.

What About OpenAI?

Everything above uses Anthropic examples because Claude Code is the most transparent agent framework to instrument. But the same problem exists — and is arguably worse — with OpenAI-compatible agents.

OpenAI's API uses a different format for tool results (the tool role), but the content is identical: npm install output is npm install output regardless of which JSON wrapper it's in. Codex CLI, Cursor, and any agent built on the OpenAI SDK all carry the same accumulated tool noise in their context windows.

Synrouter's trimming works on both formats. The strategy is identical; only the JSON path to the tool output content differs.

This Isn't Compression. It's De-Noising.

There's an important philosophical difference between tool output trimming and general-purpose text compression. Compression algorithms try to reduce the byte count of arbitrary text while preserving the ability to reconstruct it perfectly. That's not what we're doing.

Tool output trimming is de-noising. We're not trying to preserve every character — we're trying to identify and discard the characters that contribute zero reasoning value. The ANSI color codes, the progress spinners, the 47th identical grep match in node_modules/. These aren't compressed; they're removed, because they were never useful in the first place.

The goal isn't "make the context smaller." The goal is "make the context denser with signal." A 2,000-token trimmed tool output that contains the error location and exit code is more useful to the LLM than a 12,000-token raw output where the signal is buried in noise.

Getting Started

Tool output trimming is transparent. You don't configure it, tune it, or write rules for it. It happens server-side for every request that passes through Synrouter.

Your agent sends tool calls. Synrouter forwards them. When the results come back full of ANSI codes and duplicate log lines, Synrouter trims the historical ones before they enter your context window — and before you're billed for them on every subsequent turn.

If you want to see exactly what's being trimmed, every Synrouter API response includes x-synrouter-trimmed-tokens in the headers, showing the token count removed from that request's historical tool outputs. It's fully observable. You can audit every byte.

Synrouter is in Early Access. Sign up to get your API key. First $5 in credits are free, no credit card required.

Read next: The 5-Minute TTL: How Anthropic's Prompt Cache Quietly Broke Long-Running Agents

Read next: How to Cut Claude Code API Costs by 85%