63% of my agent's context came from one tool

I measured every tool call in one of my agent projects. The result I didn't expect: the tools I reach for most are not the ones that cost the most.

The most-used tool produced 63% of my context at the lowest cost per call. A tool I used twenty times produced 18 times more context per call.

The measurement

This is not a model. It is every actual tool call from a real project, read straight out of the agent's own session database. The snapshot is pinned to 07:41 UTC on 2026-10-12, because the database is live and the counts move while I am writing this.

SELECT json_extract(data,'$.tool')            AS tool,
       COUNT(*)                               AS calls,
       SUM(LENGTH(json_extract(data,'$.state.output'))) AS chars
FROM part GROUP BY 1 ORDER BY 3 DESC;

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%
everything else	571	728,507	9.0%

Why the ranking flips

Sort the same table by cost per call instead of total, and the order inverts:

bash              1,603 chars per 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 thing in the loop and it is 63% of my context. That's only possible because it's so cheap per call, and I call it constantly.

A tool's share of your bill is the product of two different things, and you can only see the problem if you measure both:

share of context = (how often you call it) x (how much each call returns)

Optimising only the first is why the tools I use most are not the tools that hurt.

The part I could not see from the tool names

Here's the number that actually made me care, and it's not in that chart.

Across 55 sessions on this project:

	tokens
input	40,473,602
output	1,587,482
cache read	561,271,443

Context was re-read roughly 14 times more often than it was first written. The 8.1 MB of tool output above is not billed 8.1 MB. It is billed once per call that follows it, for the rest of the session.

That is the multiplier that turns a cheap tool into an expensive habit. A read that returns 4,000 characters costs 4,000 characters again on every subsequent turn, forever, until the context is compacted.

What I changed, and what it cost me

Three things, in order of how much they mattered:

1. Filter at the tool, not after it. grep | head -40 instead of grepping 59,000 characters and asking the model to find the four lines it needs. The filtering is free and deterministic. Asking a model to ignore 12,000 characters is neither.

2. Count before you read. wc -l first, then read. Most files I open are 40 lines and I open them 400 times.

3. Batch the cheap tool, keep the expensive one rare. bash calls are nearly free per call, so batching them saves nothing. Web search costs 27,000 characters a call, so the only lever that matters is calling it less.

I didn't do number 3 well, which is why the web tools are 20% of my output volume for what was maybe 15% of the value. The chart is a report card, not a strategy.

The version of this you should check first

You don't need a database. Open your own agent's log and sort tool output by size. If the biggest tool isn't the one you expected, that's the whole finding.

The version I wouldn't trust is a chart of token counts without the per-call column. Total volume tells you where the bytes are. It does not tell you which habit is expensive.