Claude Fable 5.1 Cache Reads: Meter Dollars per Overnight Job
Claude Fable 5.1 cache reads cost 0.025x base input. Meter dollars per overnight agent job and cache-hit rate, learn what breaks the cache, set effort per job.
Go deeper. Build your own.
At 6:40 a.m. the overnight run has finished, the branch is green, and the job’s usage total reads 72 million input tokens. Whether that night cost about $57 or about $924 turns on a ratio nobody watched while it ran: how many of those 72 million were cache reads, and how many were cache writes.
On September 1, 2026, Anthropic cut the Claude Fable 5.1 cache read price to $0.25 per million tokens, a quarter of what Fable 5 charged. Nothing else on the price card moved. For unattended agent work, where almost every input token is a re-read of context the model has already seen, that one number is the price of the model. It also sharpens the penalty for getting the cache wrong, because a miss that has to be re-written now costs fifty times a hit instead of twelve and a half.
This is the meter, not the scorecard: a dollars-per-job formula built from the four usage fields the API already returns, an illustrative night worked through with the real multipliers, the three things that quietly turn reads into writes, and the effort setting that decides the second-largest line on the bill.
What changed on September 1, and what stayed at Fable 5 prices
Anthropic released Claude Fable 5.1 and Claude Mythos 5.1 on September 1, 2026; the developer docs list the model as “Released September 1, 2026” under the API id claude-fable-5-1 (model page). The launch page puts the price change in one line: “Cache reads now cost 75% less, or $0.25 per million tokens.” It adds that “Fable 5.1’s pricing is otherwise the same as Fable 5’s: $10 per million input tokens and $50 per million output tokens” (Anthropic).
Screenshot: Anthropic, “Introducing Claude Fable 5.1 and Claude Mythos 5.1” (September 2026), captured Sep 19, 2026.
The pricing page carries the multiplier as a footnote: “Cache hits and refreshes on Claude Fable 5.1 and Claude Mythos 5.1 are priced at 0.025x the base input price. All other models use the standard 0.1x multiplier.” Writes did not move. A 5-minute cache write is still 1.25× base, and a 1-hour write is 2× (pricing).
| Price card, USD per million tokens | Claude Fable 5 | Claude Fable 5.1 | Multiplier |
|---|---|---|---|
| Base input | $10 | $10 | 1× |
| 5-minute cache write | $12.50 | $12.50 | 1.25× |
| 1-hour cache write | $20 | $20 | 2× |
| Cache read (hit or refresh) | $1 | $0.25 | 0.1× → 0.025× |
| Output | $50 | $50 | 5× |
Screenshot: Claude Platform Docs, “Pricing” (undated docs page), captured Sep 19, 2026.
The savings claim is Anthropic’s own: “For typical workloads, costs are reduced by around 25% relative to Fable 5. For complex coding and highly agentic tasks, the savings could be up to around 45%.” The chart under that sentence carries its method in the caption, and the caption is the part worth reading: “Indexed cost of running the same workloads on Fable 5 and Fable 5.1, at usage-based pricing measured at default effort over four weeks of actual usage in August 2026. Typical workload covers Fable usage across Claude Enterprise, Claude Code, and the API. Highly agentic workload covers context-heavy, tool-heavy work, where cache reads make up most of the cost.” Default effort, August traffic, Anthropic’s mix. Your night is none of those three things until you measure it.
Why an acting agent’s bill is mostly re-reading
A chat turn reads its prompt once. An agent loop reads its entire context on every tool call, appends a tool result, and reads all of it again. Six hundred tool calls against 120,000 tokens of context is 72 million input tokens, and all but a sliver of them are repeats. The launch page’s customer quotes describe exactly this shape; Ramp’s Dwight Temple cites “One unattended 38-hour run on a machine learning problem” that “kicked off six parallel experiments that ran overnight” (Anthropic).
That is why the read price is the agent price. The replay-tax piece already covers how auto-memory multiplies the re-read; this article prices the loop itself, which is where the 0.025× number lands.
The per-job meter: four usage fields and one formula
The prompt-caching docs name the fields you need. Every response reports input_tokens, cache_creation_input_tokens, cache_read_input_tokens and output_tokens, and the docs are blunt about the failure case: “if both cache_creation_input_tokens and cache_read_input_tokens are 0, the prompt was not cached” (prompt caching).
Build the meter from those four numbers and nothing else.
dollars_per_job = ( input_tokens × 10.00
+ cache_creation_input_tokens × 12.50 # 20.00 for 1-hour writes
+ cache_read_input_tokens × 0.25
+ output_tokens × 50.00 ) / 1,000,000
cache_hit_rate = cache_read_input_tokens
/ (cache_read_input_tokens + cache_creation_input_tokens + input_tokens)Two notes on the formula. If you use 1-hour writes anywhere in the job, price that share at $20; the usage block breaks creation out in a cache_creation object (ephemeral_5m_input_tokens, ephemeral_1h_input_tokens), and the docs say cache_creation_input_tokens is their sum. And input_tokens here is the uncached remainder, billed at base; in a healthy loop it should be near zero after the first turn.
The steps, in order:
- Log usage per turn, keyed by job. One JSONL line per model call with a job id, a turn number, a timestamp, the four fields, and the effort in force.
- Sum at job end. Dollars, hit rate, writes per hour, and output tokens per turn. Four numbers.
- Write them next to the artifact. The pull request description, the run record, wherever the merge gate already looks. A cost that lives only in a dashboard is a cost nobody owns.
- Set two thresholds. A hit-rate floor and a dollars-per-job ceiling. The ceiling belongs with the cost anomaly alerts you already run; the floor is new.
# illustrative: meter.py, sum one overnight job from per-turn usage lines
import json, sys
RATES = { # USD per million tokens, claude-fable-5-1, 5-minute writes
"input_tokens": 10.00,
"cache_creation_input_tokens": 12.50,
"cache_read_input_tokens": 0.25,
"output_tokens": 50.00,
}
tot = {k: 0 for k in RATES}
turns = 0
for line in open(sys.argv[1]):
u = json.loads(line)["usage"]
turns += 1
for k in RATES:
tot[k] += u.get(k, 0)
dollars = sum(tot[k] * RATES[k] for k in RATES) / 1_000_000
denom = tot["cache_read_input_tokens"] + tot["cache_creation_input_tokens"] + tot["input_tokens"]
hit = tot["cache_read_input_tokens"] / denom if denom else 0.0
print(f"turns={turns} dollars={dollars:.2f} hit_rate={hit:.3f} "
f"writes_MTok={tot['cache_creation_input_tokens']/1e6:.2f} "
f"out_per_turn={tot['output_tokens']/max(turns,1):.0f}")A job that runs inside Claude Code on a subscription also draws down the plan’s limits, a second meter the September 14 field guide covers. A job-keyed log is the version that survives the harness, the vendor and the plan.
An illustrative night, priced with the real multipliers
Everything in this section is modeled. The multipliers are Anthropic’s; the job is invented so the arithmetic is visible. Picture one unattended job with these assumptions:
- 8 hours, 600 model turns, roughly one per tool call.
- 120,000 tokens of context at each turn, of which about 2,000 are new each time (the last tool result plus the last reply).
- 800 output tokens per turn at Medium-class effort.
- 5-minute cache writes, with the last breakpoint on the final block of each turn.
| Scenario (illustrative) | Reads | Writes | Output | Total on Fable 5.1 | Same job on Fable 5 |
|---|---|---|---|---|---|
| A. Stable prefix, cache never expires (hit rate 98%) | 70.8 MTok × $0.25 = $17.70 | 1.2 MTok × $12.50 = $15.00 | 0.48 MTok × $50 = $24.00 | $56.70 | $109.80 |
| B. One volatile token early in the system prompt (hit rate 0%) | $0 | 72 MTok × $12.50 = $900.00 | $24.00 | $924.00 | $924.00 |
| C. Forty test runs longer than 5 minutes, cache expires each time | $16.50 | $15.00 + 40 × 120K × $12.50/MTok = $75.00 | $24.00 | $115.50 | $165.00 |
| D. Scenario A at High effort, output doubles to 1,600 per turn | $17.70 | $15.00 | $48.00 | $80.70 | $133.80 |
Scenario A is the 45% case, and it is not hard to hit: 48% saved against the same job on Fable 5, all of it from the read line. Scenario B is the one to fear. A timestamp, a nonce, or a reordered tool list ahead of the first breakpoint makes every turn a write, and the night costs the same on either model because writes did not get cheaper. Scenario C is the quiet one; nobody put a timestamp anywhere, the test suite just takes nine minutes.
Only one bar moved. Source: platform.claude.com pricing, Sep 2026.
The ratio that falls out of the chart is the one to remember. A 5-minute write at $12.50 against a read at $0.25 is 50×. On Fable 5 the same ratio was 12.5×. Cheaper reads made the loop cheaper and made every miss four times more expensive relative to the reads around it, which is why a hit-rate floor matters more on this model than on the last one.
What breaks the Claude Fable 5.1 cache, and what each break costs
Three mechanisms turn reads into writes. All three are in the caching docs; none of them announce themselves in the transcript.
1. Prefix churn. The cache matches an exact prefix. Anything that changes ahead of a breakpoint invalidates everything after it: a clock in the system prompt, a tool list assembled from a dictionary with unstable ordering, a project-instructions file that a subagent rewrote at 2 a.m., an operator editing an earlier turn. The docs list editing earlier turns as a breaking change on this model for another reason too, because it “invalidates thinking blocks” (model page). Cost of one churn event at 120K context: a $1.50 write instead of a $0.03 read; churn on every turn is scenario B.
2. The 512-token floor. The minimum cacheable prompt is “512 tokens for Claude Fable 5.1, Claude Mythos 5.1, Claude Opus 5, Claude Fable 5, and Claude Mythos 5” (prompt caching). Anything under it is billed at base input on every call. That is invisible in a 120K-token main loop and very visible in a fan-out of tiny helper calls: a 400-token classifier prompt invoked 2,000 times overnight is 800,000 tokens at the $10-per-million base price, with a hit rate of exactly zero, and the fan-out metering piece explains why those calls multiply faster than you think. Do not pad prompts to cross the floor; do know which of your calls live under it.
3. TTL expiry. “By default, the cache has a 5-minute lifetime. The cache is refreshed for no additional cost each time the cached content is used.” A loop that waits nine minutes for a test suite, backs off on a rate limit, or pauses for an approval that arrives in the morning comes back to a cold cache and re-writes the context.
Two fixes, priced differently. Pre-warm: the docs say to “send a new pre-warm request at least every 5 minutes to keep the cache warm,” which at 120K context is a $0.03 read per ping. Or set the 1-hour duration with {"cache_control": {"type": "ephemeral", "ttl": "1h"}}, which doubles the write price and, per the docs, “pays off after one cache read for the 5-minute duration (1.25x write), or after two cache reads for the 1-hour duration (2x write).” In scenario C the pre-warm costs about $2.40 for the night, the 1-hour TTL adds roughly $9 to the write line, and doing nothing costs $60.
The API allows up to four breakpoints and looks back through a 20-block window for hits. The docs’ growing-conversation example shows the catch: a breakpoint on the final block finds the previous turn’s cache entry only if that turn appended fewer than 20 blocks, so keep the last breakpoint on the newest turn and put another at the end of the static prefix, where it survives a turn that dumps many tool results at once. Whether your harness exposes those breakpoints or places them for you is a harness question; check its docs before you assume either.
| What broke | The signal in the job log | First move |
|---|---|---|
| Prefix churn | cache_creation_input_tokens is large on every turn; hit rate near zero |
diff the system prompt and tool list between two consecutive turns; remove the volatile token |
| TTL expiry | creation spikes follow gaps longer than 5 minutes between turns | pre-warm during long tool calls, or move the job to the 1-hour duration |
| Under the floor | input_tokens is nonzero on every call and both cache fields are zero |
list the call sites under 512 tokens; accept the base price or restructure |
| Not cached at all | both cache fields zero on a large prompt | the breakpoint is missing; the docs say this is what zero on both fields means |
| Output creep | output tokens per turn drift upward across the night | check the effort in force; see the next section |
Effort decides the output line, and the default depends on the door
Output is $50 per million tokens on both models, and effort is the setting that moves it. Fable 5.1 runs “Thinking: Adaptive (always on)” with a “Default effort” of high, and the docs’ advice is to steer depth with effort (models overview). The launch page adds the part operators miss: “(Note that Fable 5.1 defaults to High effort in Claude Code, and to Medium in Claude Cowork and on Claude.ai.)” It also says that “when set to Low or Medium effort, Fable 5.1 achieves results similar to or better than Fable 5’s at a much lower cost” (Anthropic).
The same job costs a different amount depending on the door it came through. Scenario D models the output line doubling at High; that doubling is my assumption, not a vendor figure, and your own log will give you the real ratio in one night. The rule that follows is simple: set effort per job class, never inherit it from the surface. A refactor that has to pass a strict merge gate can earn High. Nightly triage, log summarization and test-writing usually do not, and Medium is where Anthropic itself says the Fable 5 quality bar sits at lower cost.
Three levers you own: a byte-stable prefix, a warm cache, and effort set per job. Everything else is the vendor’s price card.
Effort also touches the cache. A higher effort spends more on output, and a longer reply is a larger append to the next turn’s context, which is a larger write at $12.50. A lower effort shrinks both the output line and the write line.
The honest counterpoint: per-task cost can still rise
Cheaper reads do not guarantee a cheaper job, and the same-day third-party measurements said so. Artificial Analysis reported that Claude Fable 5.1 “tops the Artificial Analysis Intelligence Index but costs 20% more per task than Fable 5 despite a 75% cache read price cut” (@ArtificialAnlys). That is a per-task figure measured at maximum effort, not a per-token price, and it is what scenario D predicts: when a model thinks longer and writes more, the output line grows faster than the read line shrinks. ARC Prize’s post the same day pointed the other way on its two benchmarks, with per-task cost about 32% lower, driven by token efficiency.
Both measurements are honest and neither is your workload. A benchmark task is short, cold and cache-hostile by design; an overnight job is long, warm and mostly reads. The meter is the arbiter.
Two smaller lines belong on the same record. Tool definitions cache well if they are stable, but they are not small: the pricing page says the computer toolset “adds about 4,500 input tokens to a request” and the browser toolset about 6,600. And a job on Claude Managed Agents carries a second meter, “$0.08 per session-hour” that “accrues only while the session’s status is running” (pricing); on an 8-hour night that is $0.64, a rounding error next to one cache expiry.
The meter belongs to the operating layer
A price card tells you what a token costs. It cannot tell you what a job costs, because the job is made of decisions the vendor never sees: what sits in the prefix, how long the loop waits, which effort the door handed you. Those are operating-layer facts, and they belong where a fleet command center keeps its per-session evidence, next to the approvals and the diff.
The discipline transfers. DeepSeek prices the same hit ratio at different numbers and adds a clock, and the off-peak scheduling piece is this meter with a calendar attached. The context you keep warm is also context the vendor retains for a while, which is the retention boundary question and a different article. Meter the night first.
FAQ: Claude Fable 5.1 cache costs
How much cheaper are Claude Fable 5.1 cache reads than Fable 5?
Cache reads are $0.25 per million tokens on Fable 5.1 against $1 on Fable 5, a 75% cut, or 0.025× the base input price instead of 0.1×. Base input ($10), cache writes ($12.50 for 5 minutes, $20 for 1 hour) and output ($50) are unchanged, per Anthropic’s pricing page.
What is a good cache-hit rate for an overnight agent job?
For a single long loop with a stable prefix, an illustrative floor is 90%, and a healthy night sits closer to 98% because only the appended tail is written each turn. Anything under 80% on a 100K-plus context means something ahead of the breakpoint is changing or the 5-minute cache is expiring between turns.
Sources
- Anthropic: “Claude Fable 5.1 and Mythos 5.1” launch page (September 2026)
- Claude Platform Docs: Pricing (model table, cache multipliers, Managed Agents runtime, tool overheads)
- Claude Platform Docs: Prompt caching (TTLs, 512-token minimum, breakpoints, usage fields)
- Claude Platform Docs: Claude Fable 5.1 model page (released September 1, 2026; breaking and additive changes)
- Claude Platform Docs: Models overview (adaptive thinking, default effort)
- Artificial Analysis on X: Fable 5.1 costs 20% more per task than Fable 5 despite the cache read cut (Sep 1, 2026)
- @claudeai on X: Fable 5.1 cache reads 75% cheaper, around 25% lower cost for typical workloads (Sep 1, 2026)
