Agent Session & Prompt-Caching Cost Calculator
Model how a long agent chat grows turn-by-turn and how much prompt caching saves.
With the default inputs, $1.01 with caching vs $5.16 without — 80.4% cheaper over 30 turns · cache reads are 46.0% of the cached-run spend. Enter your own numbers below to recompute instantly; the full step-by-step math is shown under the worked example.
Results update automatically as you type.
- Cached base (system + tools + docs)
- 20,000 tokens
- One-time cache-write cost
- $0.1250
- Total cache-read spend
- $0.4640
- Session cost — with caching
- $1.01
- Session cost — no caching
- $5.16
- Saved by caching
- $4.15
| Turn 1 | $0.1140 | $0.1390 | $-0.0250 |
| Turn 2 | $0.2320 | $0.1634 | $0.0686 |
| Turn 5 | $0.6100 | $0.2390 | $0.3710 |
| Turn 10 | $1.32 | $0.3730 | $0.9470 |
| Turn 25 | $4.05 | $0.8350 | $3.21 |
| Turn 30 | $5.16 | $1.01 | $4.15 |
Long coding-agent and chat sessions get expensive because the whole transcript is re-sent on every turn. This calculator models a conversation that grows turn by turn: a fixed base (system prompt, tool schemas, pinned files) is cached once, the re-sent context on later turns is billed at the cache-read rate, and new input and output are billed at full price — so you can see cumulative cost with vs without caching, and how much of your spend is just cache reads.
How this is calculated
We simulate the session turn by turn. Turn 1 writes the cached base at the cache-write rate. On every later turn the whole re-sent prefix (base + prior turns) is billed at the cache-read rate, while the new user message and the output are billed at full input/output price. Without caching, the entire prompt is re-sent at the full input rate every turn. We then sum both to show cumulative cost at each milestone and the share of the cached run that is cache reads.
Is this a good result? What to do next
If caching cuts the session cost by well over half, your workload is a great fit — a large stable prefix reused across many turns. If the saving is small, either your base is tiny or the session is short. Watch the cache-read share: when it dominates, further wins come from trimming history or shortening turns, not from more caching.
Typical planning ranges
- Cache read price
- ~10% of input
- Cache write premium
- ~1.25× input (Anthropic)
- Best fit
- large base + many turns
Ranges are typical planning figures to sanity-check your result, not authoritative benchmarks. Your numbers will vary with use case, volume, and vendor.
How to improve this number
- Cache the biggest stable prefix you can (system prompt, tools, pinned files).
- Trim or summarize old turns so the re-sent prefix stops growing.
- Keep the session warm so the cache doesn't expire and re-charge writes.
Common mistakes
- Letting history grow unbounded so cache-read tokens balloon every turn.
- Ignoring the one-time cache-write premium on very short sessions.
When to use a different approach
For the cost of one specific message, use the AI prompt cost calculator. For the pure caching discount on a single request, use the prompt caching savings calculator.
Worked example (defaults)
With the default inputs above, here is the result:
- Cached base (system + tools + docs)
- 20,000 tokens
- One-time cache-write cost
- $0.1250
- Total cache-read spend
- $0.4640
- Session cost — with caching
- $1.01
- Session cost — no caching
- $5.16
- Saved by caching
- $4.15
| Turn 1 | $0.1140 | $0.1390 | $-0.0250 |
| Turn 2 | $0.2320 | $0.1634 | $0.0686 |
| Turn 5 | $0.6100 | $0.2390 | $0.3710 |
| Turn 10 | $1.32 | $0.3730 | $0.9470 |
| Turn 25 | $4.05 | $0.8350 | $3.21 |
| Turn 30 | $5.16 | $1.01 | $4.15 |
- Later turns re-send the whole transcript; caching bills that prefix at the cache-read rate instead of full input.
Sources & references
Frequently asked questions
Why does a long agent session cost so much?+
Most APIs are stateless, so the client re-sends the entire conversation on every turn. By turn 30 you may be re-sending tens of thousands of tokens each message — cost grows roughly quadratically with the number of turns unless you cache or trim history.
How does prompt caching change this?+
The stable prefix (system prompt, tool schemas, pinned files, earlier turns) is cached once at a cache-write premium, then read on later turns at roughly 10% of the input price. In long sessions the cache-read line becomes the dominant — but much smaller — cost.
Why is most of my Opus spend on cache reads?+
Once the base and history are cached, every later turn pays the cheap cache-read rate on that large prefix plus full price on only the small new message and output. Cache reads are individually cheap but there are many of them, so they add up to the biggest single share of a well-cached session.