Cut your weekend agent's memory bill by 75% without breaking the run

You build a small agent on a weekend, run it through the evening, and find the bill has grown because the same long context keeps getting reread. A cache-read price cut can turn that hidden leak into a small, measurable saving if you audit the spend and handle the migration breaks.

Repeated context is the leak

Anthropic announced the two Claude model releases, Fable 5.1 and Mythos 5.1, on September 1, 2026. Fable 5.1 cut prompt cache reads by 75%, from $1 per million tokens to $0.25 per million tokens. Fable 5.1 kept Fable 5's input and output prices at $10 and $50 per million tokens. For a weekend agent, the cache-read cut is the part that changes the budget.

Agents keep a prefix alive: system instructions, tool descriptions, examples, files, and prior turns. Every turn can reread that prefix. The saving shows up in prompt caching, because the repeated part is exactly what gets cached. Agentic workload cost can look surprising when the model is mostly paying to look at the same context again.

A coding agent with a 200,000-token cached prefix across 50 turns would read 10 million cached tokens, costing $10 in cache reads on Fable 5 and $2.50 on Fable 5.1. Anthropic projected roughly 25% lower costs for typical token-billed workloads and up to roughly 45% savings for complex coding or highly agentic tasks.

A week of spend shows the saving

You can estimate the real saving by taking a week of billing, finding the cache-read share of spend, and cutting that share by three quarters. The audit takes an evening and gives you a number you can defend to yourself.

• Pull a week of billing and separate cache reads from input and output. Finish with a small table showing total spend, cache-read spend, and the rest. A dashboard that only shows a total needs the line items.
• Find the cache-read share of that spend. The result is a percentage you can compare to the rest of the bill. A high share means your agent is rereading a lot of cached context. A low share means the saving will be smaller.
• Multiply the old cache-read total by 0.25. Keep the input and output lines unchanged. The result is a new expected cache-read line for the same billing period.
• Check the request path for forced tool choice, thinking-block handoff, and turn edits. Finish with a short note naming each code path that touches tools, thinking, or history edits. When the code is hard to find, run a short test with a forced tool, a thinking block, and an edited earlier turn.

When your agent is mostly fresh context, the saving will be modest. When it reuses a long system prompt, tool list, or file context, the saving can be the difference between a quiet weekend and a bill you need to explain. The audit does not prove the migration is worth the risk; it tells you what the memory bill should look like after the cut.

Three breaks can stop the run

Agents migrating from Fable 5 to Fable 5.1 face three breaking changes: forced tool use returns a 400 error, prior models cannot consume Fable 5.1 thinking blocks, and changes to earlier turns invalidate subsequent thinking blocks. Work through them in the order your code touches them.

Remove forced tool choice from the request, or make tool selection optional. When the agent depends on a tool being chosen, add a fallback path that can continue without it. A test run lets the model answer, ask for clarification, or call a tool without the request failing.

Keep thinking blocks on the same model version. If your pipeline stores thinking blocks and later passes them to another model, strip them before handoff. A resumed conversation avoids a compatibility error.

When a user revises a prior message, expect the model to discard downstream thinking and rerun the affected part. The log shows fresh thinking after the edited turn, not stale blocks.

The bill tells you if the switch worked

After the migration, watch the bill for a short period. Compare the new cache-read line to the number from your audit. When the line is higher than expected, check whether your agent is invalidating the cache more often than you thought. Long prefixes help, but they only help when the prefix stays stable.

Keep a small note with the old cache-read share, the new expected share, and the code changes you made. That note is the difference between a saving you can repeat and a surprise. Most weekend agents will stay small, and that is fine. When the saving is smaller than the audit predicted, look at the shape of your context: shorter prefixes, more edits, or a run that does not reuse the cached part. The next bill should let you point to the cache-read line and say why it moved.