Build1 publisher2 min readPublished
Breaks longer than the cache TTL added about 15% to one developer's Claude Code input usage
One developer's month of Claude Code logs shows each break past the one-hour cache lifetime rewriting 125k-135k tokens at twice the base input price. What that costs a team depends on its cache timer and how big sessions grow before a break.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- A warm turn reads cached context at 0.1x the base input price, so a cold rewrite costs roughly 20 times as much per token as the turn before it.
- The author's sessions kept the cache for one hour, and every request reset the timer, including the tool calls an agent makes while working alone.
- The default API cache lifetime is five minutes, and the post says Claude Code can drop to it in some cases, such as usage overage.
- A script published with the post scans Claude Code's local session logs and flags any turn that writes at least 50,000 tokens to cache as a candidate miss.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint On a five-minute timer any pause longer than five minutes forces the full rewrite, so the author's 15% describes only sessions that kept the one-hour TTL.
- decision Resuming a big session after a long break has a price set by its context size at the moment of leaving, so resuming versus starting smaller becomes a cost choice.
- capability Teams can read their own TTL and miss rate from the usage blocks Claude Code already writes to disk, so a planning case need not rest on one developer's month.
Run the post's multipliers on the author's own numbers. A typical restart in those logs bills the equivalent of 250k-270k tokens at the base input price. Read warm, the same context would have billed 12.5k-13.5k [1]. Every turn before the break paid the warm rate on that context. The first turn after it pays the cold one [5].
The write is large because of how a session is built. Every turn sends the whole conversation again, including the system prompt, tool definitions, files read and tool output [3]. Caching stores the stable prefix after the first request, so later turns read it back without processing it again [4]. Once the cache expires, the logs show the turn as a large write with little or no read [10]. "The risk is when you are the slow part: a meeting, lunch, the end of the day," the author wrote [14].
The 15% comes from one developer's month on a one-hour timer [2] [6]. It carries over to a team only if the team's sessions grow to a similar size and sit idle past the TTL about as often. Size alone moves the figure a lot. The post puts long sessions at 100k-400k tokens [3]. A cold write at the top of that range bills the equivalent of 800k base-price tokens [2], about three times the author's typical restart [3]. The post does not include logs from anyone else.
The measurement itself is careful work. Claude Code writes each session to a JSONL file under ~/.claude/projects, and each assistant turn carries a usage block that separates cache reads from cache writes [8] [9]. The script drops duplicate messages by ID before it counts anything [11]. Its second test, a write larger than the read, is what separates a miss from a busy turn. A warm turn that pulls in a big tool result still shows a large read beside its write. A miss shows a large write with little or no read [10]. Misses are then grouped by the gap since the previous turn and weighted by price [12]. A session's first turn has no earlier timestamp, so the script stores its gap as None [13]. That lets the write that opens a session be counted apart from the one that follows lunch.
What to watch
- Whether Claude Code changes when it falls back from the one-hour cache TTL to the five-minute default, given that usage overage already triggers it in some cases.
- Miss shares published by other users running the same log scan, especially from sessions on the five-minute TTL.
- Any change to the 2.0x cache-write or 0.1x cache-read multipliers relative to the base input price.