Does a new Claude Code session reuse the prompt cache of an earlier one?

Key numbers

The charts

Hover or focus a row for its exact value, interval and sample. Each chart has a Table view.

Tables

Method

1. The protocol claims a declaration at 00:32 UTC. Its surviving file has a birth time of 00:49:27 UTC. The first counted call started at 00:32:33 UTC. We cannot verify a pre-call protocol.
2. The run kept every try and made no retries. The run log lists three amendments. They cover the post-hoc Codex rule, a post-hoc pooled calculation and text corrections after a check.
3. Claude Code 2.1.286 ran Sonnet 5.5 at its default effort. Tools were off. No MCP servers. No session persistence across processes. Caching was at the provider default.
4. A session is one CLI process with 2 turns. Turn 1 asks a quantity lookup over a seeded synthetic stock ledger. The ledger has 100 lines and about 9,600 characters. Turn 2 asks a warehouse lookup. Each question has one reference answer. The checker trims spaces, quotes, backticks, a final period and currency units before comparison.
5. Each setup had 3 sessions with 2 turns each (6 calls). A used a new folder each time. B used a fixed folder. Both put the ledger in the first user message. C used a fixed folder and put the ledger in the system prompt.
6. Each setup has its own ledger seed. Different seeds prevent full ledger-prefix reuse between setups. Shared CLI-prefix reads remain possible. Sessions of a setup ran back to back. The gap between one session's last call and the next session's first call was 508 to 720 ms.
7. A later session is session 2 or 3. The protocol labels it reuse when turn 1 read at least half of its input from the cache. This is a counter-based rule; no token-level trace identifies the ledger. The cache counters are the provider’s: uncached input, cache reads and cache writes (with the 5-minute and 1-hour split).
8. List-price cost is a calculation. It prices uncached input at the input price and reads at the cache-read price. It prices 1-hour writes at 2× the input price. The calls ran on a subscription, so nothing here is a bill.
9. Codex CLI ran GPT-6.1 Sol at medium effort in setups A and B. Each setup had 3 sessions with 2 turns each. Tools, apps, plugins and web search were off. Each session used an ephemeral read-only thread. The app-server reports input and cached input, but no cache writes. Its own large system prompt could explain a cached count.
10. The surviving protocol records a 50% threshold but dates from after the calls. This rule counts 2 of 4 later Codex sessions. The post-hoc 90% rule counts 0 of 4. The respective Wilson 95% intervals are 15% to 85% and 0% to 49%. The highest turn-1 read share was 56% (calculation). No token-level trace identifies the ledger.
11. One uncounted probe call per route, with its own ledger seed, checked the driver before the counted calls. The answer checker is the one of the earlier study. Its control test (every reference answer passes, every planted wrong answer fails) ran after the counted calls, because no cache measure depends on it.
12. No batch stopped early. Nothing was trimmed. The Claude CLI reported a rate-limit status of "allowed_warning" on 9 of 18 Claude turns. No call was refused and the run did not stop.
13. The normalized-answer checker passed 18 of 18 Claude answers (95% interval 82% to 100%).
14. The normalized-answer checker passed 12 of 12 Codex answers (95% interval 76% to 100%).

Caveats

• The surviving protocol file was created after all counted calls. Its claimed 00:32 UTC declaration is not supported by its file birth time. Amendment 1 and 2 state 00:36 and 00:37 UTC, but separate pre-edit copies do not verify those times. The current summary was regenerated at 07:41 UTC. Treat the analysis as exploratory.
• The synthetic ledger and short lookup questions reuse a designed task shape from the earlier study. All 30 answers passed after text normalization (95% interval 89% to 100%), so correctness hits a ceiling. This is a cache-counter probe, not evidence about coding quality or general task success.
• The protocol gives conflicting Codex entry gates: 30% weekly allowance remaining for the optional half, but 20% before the batch. The gate script enforces 20%. No retained gate receipt proves the allowance at run time. Call caps were kept: 18 Claude calls and 12 Codex calls, plus one probe each.
• The sample is small: 2 later sessions per setup and route. A count of 2 of 2 has a 95% interval of 34% to 100%, so the per-setup counts alone do not separate the setups. The token counts were stable: every later session in A read the same 1,463 tokens, and later sessions in B read 7,833 tokens each and those in C read 7,815 each. The pooled comparison across both studies is post hoc.
• The 4 earlier sessions in the pooled new-folder count differ from this study's sessions. They ran under a different Claude login, with another ledger and 5 turns per session. Sonnet and Opus sessions ran interleaved, so same-model sessions were 13 to 27 seconds apart (calculation from the recorded call times), not under 1 second. The pooled counts are a rough check, not a controlled comparison.
• Consecutive sessions of the same setup ran less than one second apart. The cache entries were 1-hour writes. This run says nothing about reuse after a longer gap or after an entry expires.
• A and B differ in working folder, ledger seed and call order. We did not test whether the folder path, its name or another property of a new empty folder breaks the match. The CLI documents an option that moves its per-machine system-prompt sections (the working folder is one) into the first user message. We did not test it.
• Setup C ran only with a fixed folder. We did not test whether a ledger in the system prompt protects the cache against a changing folder.
• Tools were off and the working folder was empty. A real repository adds other session-specific text (for example git state). We did not test that.
• Total turn-1 Claude input, including the ledger, is about 7.8k tokens. We interpret the 1,463 reads in later A sessions as the shared CLI prefix; this was not tested. We tested one CLI version and one model per route: Claude Code 2.1.286 with Sonnet 5.5, and Codex CLI 0.160.0 with GPT-6.1 Sol. Larger rewritten inputs cost more at these list prices (calculation); this does not predict another workload’s cache use.
• Codex CLI reports no cache-write count and has a large system prompt of its own. Its turn-1 cached counts varied from 0 to 8,960 in each setup. Neither setup reached the post-hoc 90% threshold. The small sample cannot show that folders never matter. We did not test why. Do not rank Codex against Claude on these numbers.
• The Codex criterion for a full read (90% or more of its input) was set after we saw the Codex counts (Amendment 1). Under the 50% threshold we recorded in the protocol, 2 of 4 later Codex sessions would count (8,960 tokens cached in each, the count the Codex probe call showed, which we read as the Codex system prefix). The 90% rule, set after we saw the counts, gives 0 of 4. Their Wilson 95% intervals are 15% to 85% and 0% to 49%, respectively.
• Costs are list-price calculations. The calls used flat subscriptions. Turn times come from a Mac that also ran other agent work, so contention can add noise.

Sources

• Prompt cache across sessions

  Our recorded runs · October 7, 2026

  Sanitized cache-session receipts: one CLI process per session, 2 turns each, a seeded synthetic ledger (a different seed per condition) and 2 short questions with exact answers. Conditions: A a new temporary working folder per session, B one fixed folder, C a fixed folder with the ledger in the system prompt (Claude Code only). The Codex app-server reports cached input only, so its rows have no cache-write count. Probes are single uncounted calls with their own ledger seed. The answers and the ledger itself are not published. Session 1 was the first use of each setup’s ledger; sessions 2 and 3 reused that ledger. Different seeds prevent full ledger-prefix reuse between setups, but shared CLI-prefix reads remain possible. Correctness uses the reference checker after it trims spaces, surrounding quotes and backticks, a final period and currency units. The surviving protocol file dates from after the counted calls; pre-call declaration is not verified.

  Raw data: cache-sessions/sessions.json

• Cost with and without the prompt cache (calculation)

  Calculation · October 6, 2026

  Recorded tokens per turn × Anthropic list prices. With the cache: uncached input at the input price, cache reads at the cache-read price, 1-hour cache writes at twice the input price, 5-minute writes at 1.25 times (an assumption; none occurred). Without a cache: every input token at the input price. Output is priced the same in both. Not a bill.

  Raw data: caching-consistency/caching.json

• Anthropic list prices (Claude models)

  Vendor price list · September 21, 2026

  Prices as listed by the vendor on 2026-09-21 and recorded in the product price table. Cache reads at the listed rate, one-hour cache writes at twice the input price.

• Caching sessions and repeated prompts (Claude Code and Codex CLI)

  Our recorded runs · October 6, 2026

  Part 1: 5-turn CLI sessions over a fixed synthetic ledger, with the cache counters each provider reports per turn. Part 2: three prompts with deterministic validators, 10 repetitions per model. Declared protocols, validator controls before inference, every attempt kept; answers are published as ordinal ids, never as text.

  Raw data: caching-consistency/caching.json, caching-consistency/consistency.json

Download the data

The study as JSON (with its sources), every chart point as CSV, or the whole public dataset. Free to reuse under CC BY 4.0: credit Agent and link the study.

Cite as: Agent public benchmarks, “Does a new Claude Code session reuse the prompt cache of an earlier one?”, updated October 7, 2026, https://agent.sasid.ai/benchmarks/prompt-cache-across-sessions.

Write-ups on this study