How Much Does a 100-Tool Session Actually Cost?

Tool calls are how agents act: searching documentation, querying data stores, and executing code. Each action is another round trip to the model, and each round trip includes context.

The figures below are simplified from PurpleSwarm’s internal benchmarking, using Anthropic models as the example. Exact token volumes and prices vary by model, cache TTL, and workload.

Token cost for a tool loop is often treated as a linear product of steps and tokens per step. That estimate is incorrect. Models are stateless, so prior tool results must be sent again on every subsequent call. Context does not accumulate once. It is re-processed at every step.

This article measures the input-token cost of a 100-tool-call session, then shows how prompt caching and context compacting change the result.

The linear estimate, and why it fails

The session used throughout this article:

• Length: 100 sequential tool calls
• Context per step: each tool round adds 10,000 tokens (10k)

The linear estimate:

Total tokens = 100 calls × 10,000 tokens = 1,000,000 tokens (1M)

The arithmetic is correct for new tokens. It is not the quantity the API bills.

Language models do not retain tool history between requests. To produce tool call 5, the provider must receive the original prompt plus the inputs and outputs of tool calls 1 through 4. Each request is the full prefix, not the latest increment.

Uncached context growth

Without caching, every call re-processes the entire conversation. The request is a single concatenated prompt:

prompt + tool 1 input + tool 1 output + tool 2 input + tool 2 output + …

Each term is a block in that prompt. The next call appends two more blocks and resubmits the sequence in full.

For the cost model, each tool round (input plus output) is treated as 10k tokens:

• Call 1: prompt + tool 1 (10k)
• Call 2: prompt + tool 1 + tool 2 (20k)
• Call 3: prompt + tools 1–3 (30k)
• Call 100: prompt + tools 1–100 (1,000k)

Total billed input is the sum of those requests:

Total input tokens = 10,000 × (100 × 101) / 2
                   = 10,000 × 5,050
                   = 50,500,000 tokens

A 100-step session does not process 1 million tokens. It processes 50.5 million. That is a 50× increase over the linear estimate.

Strategy 1: prompt caching

Prompt caching stores the key-value (KV) cache of the prompt between calls so unchanged prefixes are not billed at the full input rate.

Pricing

Cache writes. The first time new tokens are written to the cache, they cost more than standard input:

• 5-minute TTL: 1.25× the base input price
• 1-hour TTL: 2.0× the base input price

Cache reads. Subsequent requests that reuse the cached prefix are billed at 0.10× the base rate — a 90% discount.

100 calls with a 5-minute cache

Cache writes: 100 steps × 10,000 tokens = 1,000,000 write tokens.

At 1.25× = 1,250,000 equivalent tokens

Cache reads: each step re-reads the history accumulated so far.

Σ (i − 1) × 10,000  for i = 1…100
= 49,500,000 read tokens
At 0.10× = 4,950,000 equivalent tokens

Total equivalent tokens: 1.25M + 4.95M = 6.20M.

Strategy 2: context compacting

Compacting periodically summarizes accumulated history instead of letting the prompt grow to 1M tokens by step 100. After every N tool calls, a compacting step compresses the window back to a 10k summary, and the loop continues from that smaller prefix.

The two cadences below keep the same 100-call session and the same 10k-per-round assumption.

Compacting every 50 tool calls

Two cycles of 50 calls. In each cycle, context grows from 10k to 500k tokens.

Tokens per cycle = 10,000 × (50 × 51) / 2 = 12,750,000
Across 2 cycles:  2 × 12.75M = 25.5M raw tokens

Compaction overhead: at steps 50 and 100, an extra model call reads 500k tokens to produce the summary: 2 × 500k = 1M tokens.

Total raw input tokens: 25.5M + 1.0M = 26.5M.

Compacting every 10 tool calls

Ten cycles of 10 calls. In each cycle, context grows from 10k to 100k tokens.

Tokens per cycle = 10,000 × (10 × 11) / 2 = 550,000
Across 10 cycles:  10 × 550k = 5.5M raw tokens

Compaction overhead: 10 summarization calls reading 100k tokens each: 10 × 100k = 1M tokens.

Total raw input tokens: 5.5M + 1.0M = 6.5M.

Without caching, compacting every 10 calls reduces raw volume from 50.5M to 6.5M — an 87% reduction from prompt structure alone.

Strategy 3: caching and compacting together

Caching makes prefix reads inexpensive. Compacting keeps the prefix short. Used together, both effects apply.

Caching, compacting every 50 calls

• Writes (1.25×): 1M tokens × 1.25 = 1.25M equivalent tokens
• Cached tool reads (0.10×): 24.5M read tokens × 0.10 = 2.45M equivalent tokens
• Cached compaction reads (0.10×): 1M read tokens × 0.10 = 0.10M equivalent tokens

Total equivalent tokens: 1.25M + 2.45M + 0.10M = 3.80M.

Caching, compacting every 10 calls

• Writes (1.25×): 1M tokens × 1.25 = 1.25M equivalent tokens
• Cached tool reads (0.10×): 4.5M read tokens × 0.10 = 0.45M equivalent tokens
• Cached compaction reads (0.10×): 1M read tokens × 0.10 = 0.10M equivalent tokens

Total equivalent tokens: 1.25M + 0.45M + 0.10M = 1.80M.

Cost comparison

At $3.00 per 1M input tokens and a 5-minute cache TTL:

Optimization strategy	Effective tokens	Estimated cost	Savings vs. raw
Linear estimate	1.00M	$3.00	—
Raw, uncached	50.50M	$151.50	0%
Compact every 50 calls	26.50M	$79.50	47.5%
Compact every 10 calls	6.50M	$19.50	87.1%
Prompt caching only	6.20M	$18.60	87.7%
Caching and compact every 50	3.80M	$11.40	92.5%
Caching and compact every 10	1.80M	$5.40	96.4%

Takeaways

Enable prompt caching. Caching reduces cost by nearly 88% without changing conversation history.

Compact often enough to keep the prefix small. Cached reads are cheap, but a shorter prefix is cheaper still. Caching and compacting every 10 calls reduces the uncached bill from $151.50 to $5.40 — more than 96%.

Keep prefixes stable. Identical prompt prefixes are what make cache hits reliable. After a compacting step, append the new summary as a clean continuation so existing KV blocks remain valid.