Part III · Measure itChapter 10
Metrics and the real cost of context
The question What should you measure, and what does context really cost once the cache, latency and people are counted?
Research contents
- Understand the problem
- The methods
- Measure it
- Decide and avoid
- Act on it
- Reference
Reference
On this page
In 30 seconds
- Every metric should drive a decision. Five cover most of them.
- Cost has four lines: compute, cache writes, latency and people. Most teams track one.
- Cutting tokens can raise cost, and compaction saves far less money than its token count suggests.
You will be able to
- Choose the five metrics to track and the decision each drives
- Compute cache-adjusted cost per turn
- Work out when a compaction pays for itself
- Use cost per solved task to compare configurations
Every metric should drive a decision#
Most metric catalogues list what can be measured. This one adds the column they omit: the decision each metric drives. A metric that drives no decision is decoration, and should be deleted.
If you track only five#
| Metric | What it tells you | Decision it drives |
|---|---|---|
| Prefix tax | Fixed input present on each call; cached billing varies | Whether to audit the tool surface |
| Relevance density | How diluted the context is | Whether dilution is your binding problem |
| Post-boundary re-fetch rate | Whether compaction drops load-bearing content | Whether to fix the summary schema or offload first |
| Pass² ÷ Pass@2 | Whether compression is making the agent intermittent | Whether to back off compression |
| Cache hit rate | Whether optimisations are defeating themselves | Whether to stabilise the prefix |
Together they cover the five constraints and the one blind spot. Everything else is diagnosis once one of these moves.
The full catalogue#
All 26 metrics, grouped
Budget composition
| # | Metric | Formula | Healthy | Decision |
|---|---|---|---|---|
| T1 | Prefix tax | Tokens in segments 1–4 | Under 15K | Audit the tool surface? |
| T2 | Tool-definition share | Tool definitions ÷ prefix | Under 40% | Defer or delete tools? |
| T3 | Defined : called | Tools defined ÷ tools ever used | Under 3:1 | Which tools to delete |
| T4 | Instruction-file size | Lines | Under 150 | Apply the inference test? |
| T5 | Skill-description budget | Sum of always-loaded descriptions | Under 3K | Have skills become bloat? |
| T6 | Peak utilisation | Maximum context ÷ window | Under 75% | Reset or offload? |
| T7 | Segment distribution | Tokens per segment ÷ total | — | Where to spend effort |
Density and waste
| # | Metric | Formula | Healthy | Decision |
|---|---|---|---|---|
| T8 | Relevance density | Plausibly citable tokens ÷ total | Over 15% mid-session | Is dilution binding? |
| T9 | Read-utilisation | Read tokens cited in output ÷ read tokens | Over 15% | Adopt symbol-level reads? |
| T10 | Tool-result share | Tool results ÷ session tokens | Under 35% | Invest in output shaping? |
| T11 | Retention integral | Σ (segment tokens × turns retained) | Trending down | Offload earlier? |
| T12 | Result waste | Tool tokens returned ÷ tokens cited | Under 10:1 | Shape results, or move to code execution? |
| T13 | Search : edit turns | Search turns ÷ edit turns | Under 1.5 | Is retrieval the bottleneck? |
Loss and recovery
| # | Metric | Formula | Healthy | Decision |
|---|---|---|---|---|
| T14 | Post-boundary re-fetch | Re-fetches in 10 turns after ÷ boundaries | Under 2 | Is the schema dropping load-bearing content? |
| T15 | Compactions per session | Count | At most 1 | Shorten sessions? |
| T16 | Exact-string survival | Strings kept verbatim ÷ strings present before | Over 95% | Is the schema followed? |
| T17 | Recall rate | Recalls ÷ stubs created | 0.1–0.4 | Are stubs dead, or offload too early? |
| T18 | Termination recognition | Correctly ended ÷ completed tasks | Over 90% | Is state surviving boundaries? S |
| T19 | Read-coverage on failure | Failures where the decisive file was read ÷ failures | — | Starvation or dilution? Opposite fixes |
Stability and quality
| # | Metric | Formula | Healthy | Decision |
|---|---|---|---|---|
| T20 | Pass² ÷ Pass@2 | On a fixed evaluation set | Over 0.85 | The compression-health indicator S |
| T21 | Loop rate | Sessions with the same call ×3 ÷ sessions | Under 5% | Tighten reset triggers? |
| T22 | Rule violations by turn depth | Violations ÷ opportunities, bucketed by turn | Flat | Is position decay biting? |
| T23 | Tokens per solved task | Total tokens ÷ tasks solved | Trending down | The joint cost–quality number |
Cost
| # | Metric | Formula | Healthy | Decision |
|---|---|---|---|---|
| T24 | Cache hit rate | Cached input ÷ total input | Over 70% | Is an optimisation self-defeating? |
| T25 | Cache-adjusted cost per turn | Σ(cached × p_cached) + Σ(new × p_new) | Trending down | The only honest cost metric |
| T26 | Total-token multiplier | All agents' tokens ÷ single-agent baseline | Depends | Is isolation earning its keep? P |
The four-line cost model#
Agent cost has four lines. Most teams instrument one.
Total cost = compute + cache writes + latency + people
Line 1: compute. Input tokens are 99.75–99.87% of agent token usage S. Output is a rounding error. Any cost model that reports "tokens" without splitting input by cache state can be off by an order of magnitude. This chapter uses a generic price shape, in relative units per 1K tokens:
| Token class | Relative price |
|---|---|
| Cached read | 0.10 |
| New input, written to the cache | 1.25 |
| Uncached input, no caching | 1.00 |
The 12.5× spread between a cached read and a new write is why cache behaviour dominates.
Line 2: the cache-write premium. New tokens cost more than plain uncached input, because writing them into the cache carries a premium. That is why churn is expensive: a token that enters, is invalidated and re-enters is paid at 1.25 twice, instead of 0.10 per turn if it had simply stayed.
Line 3: latency. Compaction is a blocking call that can stall the agent for tens of seconds S. Deferred tool loading adds a round trip. Sub-agents add orchestration overhead. Latency becomes money through engineers waiting.
Line 4: people. Instruction-file upkeep, memory curation, tool audits, shaping scripts, transcript review. A 30-minute quarterly audit is cheap. A memory system that needs weekly curation is not.
Two beliefs the arithmetic overturns#
Belief 1: "Cutting tokens cuts cost" C#
False whenever the cut is in the prefix. A team replaces a static 38K tool surface with per-turn dynamic selection, cutting definitions to 9K — chapter 3's dynamic-tool trap C.
| Context | Cached | New | Cost per turn | |
|---|---|---|---|---|
| Static | 120K | 117.5K | 2.5K | 117.5 × 0.10 + 2.5 × 1.25 = 14.9 |
| Dynamic | 91K | 10K | 81K | 10 × 0.10 + 81 × 1.25 = 102.3 |
A 24% token cut produced a 6.9× cost increase, because the tool block sits about 10K into the prompt and changing it invalidates everything after it C.
Belief 2: "Compaction saves money" C#
True, but far less than the token count suggests, and only if the session continues.
Take a 120K context compacted to 40K (a 25K stable prefix that stays cached, plus a 15K new summary), with 2.5K added per turn afterwards. The compaction call itself — reading the 120K transcript at the cached rate (12.0) and writing the 15K summary at 1.25 (18.75) — costs about 30.8 units.
Cumulative cost after a compaction
View data
| Turns after | No compaction | Compacted |
|---|---|---|
| 1 | 14.9 | 37.9 |
| 2 | 30 | 45.3 |
| 3 | 45.4 | 52.9 |
| 4 | 61 | 60.8 |
| 8 | 126 | 94.8 |
| 12 | 195 | 132.8 |
Afterwards, each turn costs about 7.1 units (25K prefix and 15K summary re-read cached, 2.5K new written) rising 0.25 per turn as earlier additions re-enter cached — the compacted series above is that arithmetic, cumulative from the 30.8-unit call.
Two consequences.
- Compacting near the end of a session is a pure loss. You pay the full price and collect none of the saving. With fewer than about five turns left, do not compact.
- The saving is modest because the kept context was already cheap. Holding 80K extra cached tokens costs 8 units per turn (80 × 0.10), not the 100 units the raw count implies. Meanwhile the quality cost is undiminished: the 6.5-point SWE-bench summariser swing, the Pass² drop and the 44.6% termination rate are paid in full S.
Worked monthly economics C#
A five-engineer team, each running about six agent sessions a day, 20 working days a month.
Sessions per month = 5 × 6 × 20 = 600
Turns per session = 45
Mid-session context = 110K
Prefix tax (3 MCP servers, 380-line instruction file) = 62K
New tokens per turn = 2.6K
Cost per turn = (110 − 2.6) × 0.10 + 2.6 × 1.25 = 13.99 units
Cost per session = 45 × 13.99 = 629.55 units
Cost per month = 600 × 629.55 = 377,730 units
Prefix tax 62K → 6K (tool audit + inference test)
Mid-session context 110K → 48K (shaping + offload + just-in-time)
New tokens per turn 2.6K → 1.9K (output shaping)
Cost per turn = (48 − 1.9) × 0.10 + 1.9 × 1.25 = 6.99 units
Cost per session = 45 × 6.99 = 314.55 units
Cost per month = 600 × 314.55 = 188,730 units
Compute saving: 50%. Now the lines everyone forgets.
| Line | Before | After | Note |
|---|---|---|---|
| Compute | 377,730 | 188,730 | −50% |
| Setup (people, one-off) | — | ~24 h | Tool audit 4 h, shaping 8 h, offload 8 h, instruction file 4 h |
| Maintenance (people, recurring) | ~2 h/month | ~3 h/month | Quarterly audit plus script upkeep |
| Latency | baseline | slightly better | Smaller contexts prefill faster; just-in-time adds round trips |
Where the value actually is. The cost saving is real, but it is not the headline. Mid-session context fell from 110K to 48K, from 55% of a 200K window to 24%. That gives the workload a lower-utilisation condition to compare with the higher one; any quality effect should be measured with chapter 9's design.
Cost per solved task#
The one number that captures cost and quality together:
cost_per_solved = total_cost / tasks_solved
It cannot be gamed in either easy direction. Cutting context aggressively lowers cost and lowers the solve rate; the ratio catches it. Dumping in more context raises solve rate slightly and cost sharply; the ratio catches that too.
Three configurations over 40 tasks: cost per solved task
View data
| Configuration | Cost per solved task |
|---|---|
| Full context, no management (27 solved) | 919 |
| Managed stack (29 solved) | 393 |
| Over-compressed (21 solved) | 424 |
This is the arithmetic form of a measured result: full context cost 2.68× the best method while completing fewer tasks S. It adds a lesson: you can over-compress as easily as you can over-load.
Where to spend the next unit of effort#
Run this checklist in order. Stop at the first "yes".
- Cache hit rate under 60%? Fix the prefix. Everything else is downstream and may be self-defeating.
- More than 3 tools defined per tool used? Inspect deletion candidates. If a representative sample confirms dead tools, remove them with rollback; the largest win is workload-specific.
- Tool results over 35% of the session? Output shaping: one afternoon, 60–90% reduction P.
- Read-utilisation under 5%? Structural retrieval.
- Post-boundary re-fetch over 2? Offload before compaction; fix the schema.
- Pass² ÷ Pass@2 under 0.85? You are shipping intermittency. Back off compression.
- None of the above? Stop optimising context. Your binding constraint is elsewhere: model choice, task decomposition or the verification loop.
Step 7 is the one people skip. Context management has a stopping point, and continuing past it is how teams end up maintaining machinery that costs people's time and buys nothing.
Key takeaways
- Stable prefix tokens cost about 0.10; churning tokens cost 1.25 every time they re-enter.
- Compaction breaks even after about four turns; near the end of a session it is a pure loss.
- You can over-compress as easily as over-load. Cost per solved task catches both.
- When the next-dollar checklist comes up empty, stop optimising context.