Keeping your AI coding costs low with Anthropic

June 14, 2026·Updated June 16, 2026·12 min read·by the FrankenCoder team

A practical guide to where the money actually goes when you code with an Anthropic-powered AI agent — and the handful of settings that decide whether 1,000 turns of work costs you $37 or $550. The general lesson — smaller context is cheaper than a giant re-read every turn — applies broadly, but the cache-write premiums, 5-minute cache TTL, keep-warm heartbeat and shared-prefix savings in this guide are mostly Anthropic-specific. OpenAI, Gemini and xAI use different caching economics, so they do not need the same keep-warm strategy. None of this is guesswork: to find what actually drives the bill, we went back through our own usage — more than 340,000 messages across 600+ real coding sessions — and measured it. Skim the five-step short version below, or read on for why each one holds.

1. The one idea: the re-read tax

An LLM has no memory between turns. To "remember" the conversation, the entire history is re-sent on every turn. Prompt caching makes those re-sent tokens cheap — they bill at the cache-read rate (~10% of input) instead of full price — but cheap is not free. You still pay to re-read the whole prefix, every turn, and that bill grows with the conversation.

Here is the same turn, mid-conversation, in a small-window chat vs a large-window chat. Only one line changes:

Summarizing is what resets that re-read tax: it collapses 160k of history back down to a 3k summary, so the next 29 turns re-read a small prefix again. And the summary itself is cheap — a few cents per collapse (often free; see §4). The re-read tax, by contrast, is paid on every one of the 157 turns between summaries. That asymmetry — cheap-and-occasional vs small-but-relentless — is why avoiding summaries to "save money" backfires.

2. What does one summary actually cost?

A summary is one extra model call that fires when your context fills up. Two things set the price — which summarizer you pick, and where you set the trigger:

• Local model — always $0. Summarize with the built-in local model and it's genuinely free, at every window and every threshold. Nothing in the table below applies to it.
• Cheap cloud — pennies. The prices below use a small cloud model (Haiku); other small models — GPT-mini / -nano and the like — land in the same ballpark.

Here is the cost of one single summary, by window size and where you trigger it, with Pre-compute summaries in background OFF (one call at the threshold) vs ON (rewritten after every message):

The sweet spot is a token count, not a percentage: aim to summarize around 100k of context. That's 50% of a 200k window, ~40% of a 272k window, and only ~10% of a 1M window — which is why a big window left at a high % gets pricey. Two patterns to read off the table: the OFF column barely moves (it's a single call no matter how full you let it get), while the ON column climbs steadily, because pre-compute rewrites the summary after every message and a higher trigger stacks up more messages before it fires. At the recommended ~100k it's under 4¢ a summary either way — cheap enough to leave pre-compute on for the instant turns.

3. When should it summarize? (the threshold) — measured on real chats

This is the knob you actually control: how full does the context get before we compress. Those last figures were single-turn and single-summary snapshots. The chart below is the real thing — we replayed 52,321 actual turns from 219 of our own real coding conversations through the exact prices we get billed at, sweeping the summarize threshold from 50k all the way to a 1M window. y-axis is the all-in cost to drive 1,000 turns; the x-axis is where you set the trigger. Three curves show the same sweep under three assumptions for the floor (how big the prefix is right after a summary: system prompt + tools + the ~3k bridge + pins) — because that floor, not the threshold, is the real driver, and it depends on your prompt and tool set.

Here is the full data behind the chart — every point, all three floor assumptions — so you can read your own setup off it instead of trusting our headline. ($ per 1,000 turns; the cheapest threshold for each floor is highlighted.)

A note on the absolute numbers: these are averages across every conversation we looked at, and most real chats are short and never reach a high threshold — which is why the averages here sit below the single deep-turn example in §1–2. Don't anchor on the exact dollars; anchor on the shape, which never changes: cheap on the left, a steady climb to the right, and a cliff if you never compress at all.

4. Who writes the summary? (and yes, that cost counts)

The summary is produced by a separate model call — it can't share the chat's cache, so its cost is real and was easy to overlook. Two knobs decide how much it adds: which model writes the summary, and how often it fires.

• Pre-compute summaries in background — ON (the default): a fresh summary is written after every user message, so the next turn is always ready. Great for latency — but it re-emits the summary on every message (dozens of times per epoch). Each fire reads only the new turn + the prior summary — not the whole history — so the cost grows with how often you message, not with how deep the chat is.
• Pre-compute summaries in background — OFF (unchecked): the summary is written only once, when the window hits the threshold. Far fewer calls — this is the box to uncheck for the cheapest summaries.

Reading that table: the two all-in $/turn columns are the cost of the entire turn — almost all of it your main coding model re-reading context, which you pay no matter who summarizes — so they barely budge between rows. The summarizer only moves the last column. That's why the local-model row still shows ~$0.067 / ~$0.178: those are what the coding model charges to do the work; the summary itself is genuinely free ($0.00, last column).

But before you go unchecking it: 11× cheaper than what, and is it worth the wait? A summary's cost rides on how many user messages piled up before the window filled — and that scales with your threshold. At a small threshold an epoch holds only a message or two, so there's almost nothing to save. Here's the real cost of one compaction, with the Haiku summarizer, at the thresholds you'd actually pick:

5. "What if I never summarize — just run to 900k and start a new chat?"

Tempting: no summarizer cost, no compression loss. But the re-read tax tells you the answer before you run it. The cost of a big chat isn't the summary — it's re-reading the giant prefix every turn, which you pay whether you summarize or not.

6. Keeping an idle chat "warm"

Keep-warm is a provider-specific optimization, not a universal one. It matters when a provider charges extra to write a cache entry, then expires that entry quickly unless you refresh it. Of the four major providers we compared, Anthropic is the only one with both halves of that cost structure: a paid write premium and a short 5-minute message-cache TTL.

Why this mattered in real sessions

We measured the gaps in the real history, not a synthetic trace: every conversation database on the machine, 90 databases covering 3,142 conversations and 447,321 assistant turns over 125 days. The surprising part was where cold-cache returns came from. It was not mostly slow shell commands. It was ordinary human time: reading a diff, answering Slack, getting coffee, or just thinking.

A cold return is expensive because the token mix flips. In the trace we inspected, a normal warm turn read about 86k cached tokens and wrote only ~1.1k new tokens. The turn after a five-minute-plus gap read almost nothing from cache and wrote about 93k tokens — the whole conversation rebuilt from cold. On Anthropic Opus pricing at the time, cache read was $0.50/M, fresh input was $5.00/M, and 5-minute cache write was $6.25/M: a read was about one-twelfth the price of a write.

Why not just use Anthropic's one-hour cache?

We tried that first, and it looked great on paper: trade the 5-minute message cache for a 1-hour cache and rescue human pauses automatically. The catch is that Anthropic's 1-hour write cost was higher ($10/M vs $6.25/M), so the blanket version taxes every ordinary warm turn too. In the replay, that added +$2,609 on healthy turns while rescuing only -$1,137 of cold idle rewrites; another +$234 was wasted on returns cold for over an hour, which a one-hour cache could not help anyway.

On Anthropic, your conversation's message cache expires after 5 minutes (the system prompt and tools live a full hour — that's the shared prefix in §7). If even that message cache lapses while you're away, the history must be re-written on your return — the expensive write tier. To dodge that, the keep-warm heartbeat quietly re-reads the cached history every few minutes (the cheap read tier, ~12× cheaper than a rewrite), nudging the 5-minute timer forward — but only up to a point.

And the bigger the Anthropic context, the more even those cheap reads add up while you're away — priced at a mid-tier (Sonnet-class) read rate: a 160k chat burns about $0.58/hr idle, an 800k chat about $2.88/hr doing nothing (roughly 1.7× those on a flagship model). One more reason to keep context small.

What shipped is intentionally boring: a Keep Warm toggle and a small fuse indicator under the context meter. Flip it on for Anthropic, and FrankenCoder quietly spends cheap reads during normal pause-length gaps, then lets the cache lapse on long absences instead of bleeding heartbeats forever.

The cost dashboard keeps it honest. In this captured workspace, Keep Warm is just 0.4% of the bill while protecting a 43.5% prompt-cache hit rate.

7. The shared warm prefix — a free head start across chats (same model only)

Two things sit at the very bottom of every request and never change between turns: the system prompt (instructions + standing orders + read-only workspace context) and the tool definitions (the schema for every tool the agent can call). Together they're a large, fixed block. FrankenCoder builds it to be byte-identical across every chat — no conversation name, no timestamp baked in — and caches it with a 1-hour TTL, twelve times longer than the 5-minute message cache.

Because the bytes are identical, that cache entry is shared across your chats. Warm it once — just by using the agent — and for the next hour every new chat you open finds its system prompt and tools already cached: you pay the cheap read rate (~10%) on that whole block instead of a cold write, on the very first turn of each new conversation. Open ten chats in an hour and nine of them skip rewriting the prefix entirely.

So, to actually bank the discount: pick an Anthropic model and stay on it across the chats you open in a session — model-hopping re-pays the cold prefix on every switch. This one needs no toggle and no summarizer; it's just free, as long as you don't change models. (The 5-minute message cache from §6 is the part the keep-warm heartbeat protects; this 1-hour system+tools prefix is the cross-chat freebie underneath it.)

8. The recommended setup

← All guides