On a modelled thirty-turn agent loop, prompt caching saved between 80% and 89% depending on the provider, and an independent benchmark across more than 500 agent sessions measured 41% to 80%. Then a single timestamp in the system prompt cut one provider's saving to 6%. The mechanism is worth understanding, because it is the difference between a predictable month and a surprise.
Why agent runs are expensive by design
A chat message sends one prompt. An agent turn sends the entire accumulated run: system prompt, project instructions, tool schemas, every tool result so far, and the current request. By turn thirty you are re-sending a large prefix on every single call, and you will do it again on turn thirty-one.
Caching exists for exactly this. The provider stores the prefix and charges a discounted rate when the next request matches it, which is why a typical agent loop is mostly cache reads rather than fresh input. The trap is that the discount only applies when the prefix matches byte for byte, and anything volatile near the top of the prompt invalidates everything below it.
The three prices in one request
| Category | What it is | What moves it |
|---|---|---|
| Cache read | Re-sent prefix that hit the cache | Prefix stability, project file order, tool schema order |
| Cache write | Prefix stored for next time, usually at a premium | How often you invalidate, how long runs last |
| Fresh input | New text this turn only | Tool output volume, how much you clip |
| Output | What the model writes | Reasoning effort, and cache state on some providers |
Cache write can cost more than fresh input, and cached output can cost more than fresh output on one major provider. Both are easy to miss on a bill.
That last row catches people out. On one well-known provider, input cached for five minutes or more costs more than a fresh token, and cached output is priced above non-cached output. If your run keeps touching its context in short bursts, you can end up paying a premium for a cache you are generating faster than you consume it.
Image goes here
/blog/ai-coding-agent-cost-spend-chart.png
Thread spend chart split into cache read, cache write and fresh input
Show generation prompt
Editorial data illustration, 16:9, flat vector. A vertical bar chart of seven columns of varying heights, each column internally split into three stacked segments (cache read, cache write, fresh input) using three densities of fill. One column is notably taller than the rest and highlighted. Charcoal (#121212) background, grey (#8c8c8c) outlines, the tallest column's middle segment in indigo (#5560d4), ordered-dither dot texture along the baseline, generous negative space. Mood: diagnostic, measured. No readable text, no logos, no watermark.
What the bills look like
One published breakdown put a developer's API spend at roughly $36 a month at light usage, $178 at daily professional usage, and $594 at full-day agent usage on a mid-tier model, assuming three quarters of input came from cache. Flat subscriptions bracketed the same work at $20, $100 and $200. The crossover is somewhere around one real agent task per working day, past which subscription beats API, and around five per day, past which the higher tier wins.
Team-level estimates cluster in the same range: about $54 per developer per month for a mixed workload, with heavy users past $100. Vendors' own figures have come in lower, around $13 per developer per active day, which is the number to remember when a flat plan looks expensive.
Levers that actually move the number
- Freeze the top of your prompt. Timestamps, volatile tool schemas and dynamically generated instructions go last.
- Stop MCP from dumping schemas. Each tool description is re-sent every turn, so a generous tool registry is a recurring cost even when you never use those tools.
- Compress tool output. Clipping a noisy command to its last few hundred lines costs one read and saves thousands of tokens a run.
- Route the cheap work to a local model. Titles, summaries and compaction do not need a frontier model.
- Budget by outcome, not by turn. Cap spend per thread and per day so a runaway stops before the next call rather than after it.
The cleanest signal for whether the fourth lever is working is the ratio of cache reads to fresh input over time. If fresh input is climbing while the task stays the same size, something is invalidating your prefix every turn.
How Quaka meters the spend
Quaka metered spend per turn and per thread, breaking input into cache read, cache write and fresh so the ratio is visible while you work rather than after the invoice. A spend governor with a token cost attached stops the run before the next call and offers a raise-and-continue action, which is the same mechanism as the step cap.
Every session also writes a raw usage record in a form that cost and analytics tools can ingest, so a local run can be aggregated alongside everything else you spend. Pricing tables load from provider endpoints rather than being hardcoded, which is why changing provider rates do not require an app update.
Get an invite
Quaka is in private beta.
One email when your invite is ready. macOS, Windows and Linux, bring your own key.
Read the source on GitHubCommon questions
How much does prompt caching actually save on agent runs?
Measured across provider models, roughly 80% to 89% on a thirty-turn loop, and 41% to 80% across an independent sample of more than 500 sessions. The spread comes from how stable the prefix is, how much of the prompt sits above the cacheable section, and the provider's own pricing rules.
Why does my token bill spike partway through a long task?
Usually because the cache is being invalidated. A timestamp, a shuffled project file order, a volatile tool schema or a compaction that rewrites history will all change the prefix, so the next call misses and pays full price for input it had already paid for once.
Is a subscription or API pricing cheaper for a coding agent?
Around one agent task a working day, a subscription tends to win. Past roughly five a day, a higher tier wins. API pricing wins when usage is sporadic, when you want a cheap model family with no subscription, or when volume would blow through a plan's cap. A local model sidesteps the question entirely.