Your agent bill isn't decided by the model price. It's decided by your repeat rate.

A 20-step agent task re-sends its context at every step. That is the whole cost story, and it is easy to miss, because the price you shop for — dollars per million tokens — is the smallest term in the bill. The terms that actually decide it are in your own traces: how often the same goal repeats, how long the gaps between repeats are, and what a finished task costs you end to end.

An external worked example makes the shape concrete. Sourceit.com.sg's cost breakdown of a 20-step task on Sonnet 5.5 puts the re-sent input at 770k tokens, $2.14 per task without caching versus $0.97 at an 80% cache rate — and at 1,000 tasks a day for 30 days, $64,200 versus $29,088. Their retry-loop number is the one to sit with: one agent stuck in a loop for 12 hours costs about $318, ten agents about $3,180. Those are their numbers, from their model and their workload — but the structure generalizes: the bill is steps × re-sent context × repeats, and the multiplier that nobody budgets for is the loop.

Spheron's roundup of the same problem cites Gartner 2026 — agentic AI consumes 5–30x more tokens per task than a chatbot exchange — and a Stanford Digital Economy Lab finding that identical SWE-bench runs can differ up to 30x in token cost, because trajectories are stochastic. Tool calls add tokens twice, once for the schema and once for the result. Their conclusion is the same one this post is built on: the highest-leverage fix attacks the re-sent context directly.

The three numbers, in order

1. Repeat rate — but measured on goals, not prompts. A repeat rate computed on exact prompt text understates the opportunity, because the same goal arrives in different wording all day. On τ-bench — the airline customer-service benchmark, dense with the rephrased-same-goal traffic that support agents actually see — Pomerene's trajectory cache served 86% of paraphrased requests from cache, with 78% of those judged correct. Read both numbers honestly: 86% is why repetitive agent workloads are worth caching, and 78% is why the safety rules below are the product, not a footnote. Your number will differ. Measure it from your traces: cluster completed runs by goal, count the clusters with more than one member, and that is your ceiling. If goal repeats across sessions are effectively zero on your corpus, a trajectory cache has almost nothing to serve there — and the honest answer is to not buy one.

2. The gap distribution — because a repeat after the data changed is a stale hit, not a saved run. A repeat rate without a time dimension is a vanity metric. Bucket your requests by gap length first, then price each bucket separately: a repeat inside the TTL is a saving, a repeat after the underlying data changed is a wrong answer served fast. Which TTL wins — 5-minute or 1-hour — falls out of the gap histogram, not the average task cost. The same logic applies to the cache-write side: a small fraction of requests can write a large fraction of the cache-write tokens, so price the writes per bucket too, not per task.

3. Cost per finished task — not per token, not per request. Cost per token flatters any change that makes each call cheaper while the agent takes more turns to finish. Cost per request hides the retry loops. The decision-grade number is what a completed task costs, including the runs that failed and retried. A cache that never hits is worse than no cache at all — it charges you the lookup and validation on every call and saves nothing — so the first test of any caching change is whether cost per finished task actually falls.

Where trajectory replay fits in that math

Prefix caching and trajectory caching attack different terms, and they compose. Prefix caching reuses the re-sent context and still generates — it makes each completion cheaper. A trajectory cache replays the recorded plan instead of re-deriving it: a 14-step audit trajectory replays in 47ms versus 3.9s live, with zero LLM invocation on the hit path. The saving lands on the whole run, not on one call's input tokens — which is exactly the term the 5–30x multiplier lives in.

The match has three outcomes, all deterministic — hashing plus vector geometry computed in TypeScript, no LLM call in the match decision, so the same input makes the same cache decision every time. L1 is a full replay. L2 replays the matching prefix and hands control back to your agent at the exact step where the plan stops matching. A miss runs live and gets stored. That L2 handoff is what makes the math safe to apply to real traffic: partial drift hands control back to the agent, never a subtly wrong execution.

The safety term in the equation

A wrong hit doesn't show up in your token bill. It shows up as a wrong answer, a duplicated charge, a state change that never should have happened — and no cost model that omits it is honest. So the write rule is the whole product: steps that write are never fuzzy-matched against a new request. A cached write step replays only on an exact goal-plus-context repeat; anything ambiguous becomes a miss or an L2 handoff. On an adversarial eval of polarity-flipped pairs (requests that are semantically close but must not be confused, like activate vs. deactivate at 0.853 cosine similarity), the gated engine produced 0 false positives across 18 pairs.

One honest note, because the gate's story changed after the first post about it: the write-safety gate as originally published had three holes, found via outside critique and fixed in core — merged, shipping in the next core release. An abstract-goal match is no longer treated as an exact repeat (write trajectories are refused there, and context is diffed); a trajectory with no taint records plus a context change is now a miss; and a hit never serves past a declared external_write — control hands back to the agent at that step. Still open, not shipped: entity agreement on read matches. Any cost model you build should treat those as the current rules, and the open item as the next gate to build.

Do the math before you buy the cache

If your traces show the same goals arriving in different wording, you're paying the model to rediscover plans it already derived. If they don't, no cache — trajectory, prefix, or otherwise — will save you money, and the kit will tell you that before you commit: the built-in diagnostics (/v1/diagnostics) show hit rates, the L1/L2/miss breakdown, latency percentiles, and dollars and tokens saved for your real traffic. Run the three numbers first — goal repeat rate, gap histogram, cost per finished task — and let them decide whether caching is a cost lever or a distraction for your workload.

Pomerene ships as a self-hosted Starter Kit — Indie $99 / Pro $249, one-time, source included — so the cache runs in your infrastructure, next to your agents. Quickstart is about 5 minutes (Node 20+, Docker or Postgres 15+). Docs and details at pomerene.io/starter-kit.