63% of Agent Context Comes from One Tool: Real Data Reveals the Hidden Cost Trap

A developer did something most people haven't: they quantified and measured every single tool call in their AI Agent project. The result was surprising — the most frequently used tool is not the most expensive one.

This finding points to a widely overlooked cost structure problem that's relevant to anyone building or using AI Agents.

Real Data, Not Modeled Estimates

The author emphasized that these numbers aren't estimates — they're actual tool call records pulled directly from the Agent's own session database. They even pinned the snapshot to a specific timestamp (07:41 UTC) because the database is live and changes while you write about it.

63% of Agent context comes from one tool

Looking at the totals, the bash tool stands out dramatically:

Tool	Calls	Total Characters	Share
bash	3,210	5,147,190	63.4%
read	194	795,397	9.8%
web search (exa)	20	545,357	6.7%
web search (built-in)	16	460,672	5.7%
fetch page	24	445,160	5.5%
all others	571	728,507	9.0%

bash alone accounts for 63.4% of all context, while web searches make up only about 2% of calls. At first glance, the optimization target seems obvious — focus on bash. But the truth is exactly the opposite.

Why the Rankings Flip

When you re-sort the same table by cost per call (characters returned per invocation), the order completely reverses:

bash           1,603 chars/call
grep           3,117
read           4,099
scrape a page  10,519
fetch a page   18,548
web search     27,267

bash is the cheapest tool in the entire loop — just 1,603 characters per call. It dominates the 63% share purely because of low per-call cost × extremely high call frequency. A single web search, by contrast, consumes 27,267 characters — about 17× more than a single bash call.

The author distills this into a key formula:

Context share = (call frequency) × (per-call output size)

The problem is that most people only look at the first factor (call frequency), so they never optimize where it actually hurts. The tool you use most often is rarely the one costing you the most.

The Hidden Cost That Doesn't Show Up in Tool Names

The most alarming number in this analysis isn't in the table above.

Across the project's 55 sessions, token consumption breaks down as follows:

Type	Tokens
Input	40,473,602
Output	1,587,482
Cache reads	561,271,443

The context is being re-read approximately 14 times for every time it's first written.

This means that 8.1MB of tool output isn't billed just once. It gets re-read and re-billed in every subsequent conversation turn, over and over, until the context is compacted.

The author makes a sharp observation: this is precisely the multiplier effect that turns a "cheap tool" into an "expensive habit." A single read returning 4,000 characters will cost another 4,000 characters in every subsequent turn — indefinitely, until the context is compacted. Low per-call cost doesn't mean a low total bill.

The "cache reads" here refer to the Prompt Cache mechanism in LLM APIs. In Anthropic Claude, for example, when the context prefix is identical across consecutive conversation turns, the API automatically detects and reuses previously computed KV Cache, charging a much lower "cache read" rate (typically around 10% of the normal input price). But a low rate isn't the same as free — if a 4,000-character tool output gets read in each of the next 20 turns, even at one-tenth the normal price, the cumulative cost is double what you paid to write it in the first place. The 561,271,443 cache-read tokens being ~14× the input tokens tells you that this project runs long sessions where context is repeatedly re-read. This is exactly why context compaction or periodically clearing tool outputs can produce meaningful cost savings in long-session Agents.

What the Author Actually Changed

Based on this data, the author made three adjustments, ordered by impact:

1. Filter at the Tool Layer, Not After

Use grep | head -40 instead of grepping 59,000 characters and letting the model find the four lines it needs. Filtering at the tool layer is free and deterministic; asking the model to ignore 12,000 characters is neither free nor reliable.

2. Count Lines Before Reading

Run wc -l to see how large a file is before deciding whether to read the whole thing. The author notes that most files they open are only 40 lines long, but they open them 400 times — blindly reading everything accumulates staggering repeated costs.

3. Batch Cheap Tools, Keep Expensive Ones Rare

Here's a counterintuitive point: bash costs almost nothing per call, so batching it doesn't save much. The real leverage is in calling expensive tools less often. A web search at 27,000 characters per call has only one effective optimization strategy: call it less.

The author openly admits they haven't done well on point 3 — web tools account for 20% of output volume but probably deliver only 15% of the value. As they put it: "This chart is a report card, not a strategy."

All three adjustments share a common design principle: reduce information volume before it enters the context, rather than relying on the model to "ignore" redundant content after the fact. This maps directly to how LLM APIs charge — you're billed on the actual tokens passed in, regardless of whether the model truly "uses" them. More importantly, even if the model can identify and ignore noise, those redundant tokens still occupy the finite context window, crowding out space for reasoning, and continue generating cache read charges in every subsequent turn. "Tool-layer filtering" isn't just a cost-saving trick — it's an engineering practice for improving Agent reasoning quality: the more refined the input, the better the model's attention can focus on genuinely relevant information.

The Simplest Version You Can Do Right Now

The good news is you don't need a database to replicate this analysis. Open your own Agent's logs and sort by tool output size.

If the biggest tool isn't the one you expected, that discovery alone is the whole point.

The one thing the author cautions against trusting: charts that show total token counts without a per-call cost column. Total volume tells you where the bytes are, but not which habit is actually expensive. You need to measure both frequency and per-call cost to see the full picture.

Takeaways for Agent Developers

This real-world analysis offers a few immediately actionable insights for developers building LLM Agents:

Cache reads are the real big-ticket item. In long-session scenarios, repeated context billing can run 10–15× your input tokens — this is where optimization ROI is highest.
Measure before you optimize. Guessing which tool is expensive based on intuition is almost always wrong. Real logs will overturn your assumptions.
Build filtering into tool design. Having tools return refined, minimal results is far more reliable and cost-effective than hoping the model will "ignore the noise" on its own.

As Agent applications scale to production, context costs are no longer abstract — they show up directly on your bill. Learning to read your own session logs may be the most essential skill for every Agent developer.