Claude Code keys its cacheable prefix on the literal current directory. Every git worktree under the same repository pays a fresh full cache-create on every session start, even when CLAUDE.md, project memory, and plugin state are byte-identical.

Source: GitHub issue anthropics/claude-code#53490 ^[1], filed by kwangsug (Izakka) on 2026-04-26 with a 30-day reconstruction from local JSONL session logs. Across 15 sessions and 25 distinct cwd values inside one repository, the account ran a cache-creation-to-input-token ratio of 92x against an expected ratio under 2x. The only outside commenter on the thread, 0xbrainkid, called the failure mode a “namespace mistake with very expensive consequences” and a “billing amplifier” ^[1]. A second issue, anthropics/claude-code#48236 ^[2], filed earlier by wadabum with a bare-repo minimal repro, identifies the byte that diverges: a Primary working directory: <cwd> line embedded in the system prompt.

The numbers

The reporter’s daily samples ^[1]:

Day	Input tokens	Cache-create tokens	Ratio
1	37,402	16,785,123	449x
2	67,583	24,730,433	366x
3	50,281	24,234,117	482x
4	7,203	8,187,875	1,137x
5	7,690	9,357,242	1,217x
6	33,988	34,540,802	1,016x
7	10,569	14,832,998	1,403x

Aggregate over 30 days: 252,267,892 cache-create tokens, 6,264,999,480 cache-read tokens, 15 sessions, 25 distinct cwd values inside one git repository. Reconstructed cost: 5-figure USD. Anthropic support declined the refund request and declined to escalate ^[1].

The ratio worsens as more worktrees and subdirectories accumulate against the same project. Each new path is treated as a fresh workload.

Why every worktree is a new cache

Per wadabum’s analysis on #48236 ^[2], Claude Code’s system prompt contains an # Environment block with two literal lines: Primary working directory: <cwd> and Is a git repository: true. Across two worktrees of the same repo, those bytes differ, the system prompt prefix diverges from that line forward, and cache_control checkpoints placed after it land on a different cache key. Even with CLAUDE_CODE_DISABLE_GIT_INSTRUCTIONS=1 set (which mitigates the related #47107 git status injection), the worktree miss persists ^[2].

Bare-repo repro from #48236 ^[2]:

mkdir the_project && cd the_project
git init --bare -b master .git
git worktree add master
pushd master && git commit --allow-empty -m "Dummy" && popd
git worktree add feature

# warmup in master
pushd master && CLAUDE_CODE_DISABLE_GIT_INSTRUCTIONS=1 claude "Hello" && popd
# rerun in master: 15.9k cache_read, 0 cache_creation: warm
# run in feature: 10.4k cache_read, 5.4k cache_creation: re-warmed in the sibling

That 5,400-token cache_creation_input_tokens on a “Hello” message in the sibling worktree is the system prompt + skills + CLAUDE.md being re-cached because the cwd line diverged.

What it costs you

Sonnet 4.6 pricing as of 2026-04-27: $3.00/M base input, $3.75/M 5-minute cache write, $0.30/M cache read ^[3]. The reporter’s 30-day cache totals against current pricing:

Component	Tokens	Rate	Cost
Cache-create	252,267,892	$3.75/M	$945.99
Cache-read	6,264,999,480	$0.30/M	$1,879.50

The 92x ratio means cache-create ran ~46x what a healthy 2x account would log on the same input volume. Total input for the 30 days was ~2.74M tokens (252M / 92). A healthy account would have written ~5.5M cache-create tokens and read everything else; this account wrote 252M. The 246M excess writes cost ~$924 at $3.75/M against the ~$74 those tokens would have cost as cache-reads. The worktree tax on cache writes alone: ~$850 over 30 days. Output tokens and the remainder of the 5-figure aggregate sit outside that line.

The amplifier is per-cwd, not per-session. A developer who keeps three worktrees open and runs claude in each pays three independent cache warmups even when the second and third sessions start within the cache TTL window. CI and review-bot workloads multiply it further: the same account logged 19 review submissions across 15 PRs in two days, each at a different checkout path, at roughly $35 per review against a community-reported norm of $1 to $5 ^[1].

How to tell if it’s you

Two signals.

OpenTelemetry. Claude Code exports flat un-namespaced attributes on the claude_code.token.usage metric: a type attribute with values "cacheCreation", "cacheRead", "input", "output" ^[4]. Sum cache_creation_tokens divided by sum input_tokens over a working day. Healthy: under 2x. Per #53490, over 100x is the worktree-bust signature ^[1]. The reporter’s worst day was 1,403x.

Local JSONL. Each request entry in ~/.claude/projects/<repo-slug>/*.jsonl carries a cwd field. Group by cwd, sum cache_creation_input_tokens per group. Multiple groups inside the same repo means you are paying the worktree tax. The ccusage CLI ^[5] supports per-project filtering; pair it with direct JSONL parsing to group by cwd.

For a single response check, look at the API usage block. If cache_creation_input_tokens is non-zero on a session that should be warm (same repo, second turn, identical CLAUDE.md), the prefix diverged ^[3].

Workaround

There is no in-product fix. The options are operational:

1. Stay in the main checkout. Skip worktrees on projects where the prefix is large enough that the warmup cost dominates session cost.
2. Open one persistent Claude Code session per worktree and keep it alive. The first turn pays the full cache-create; subsequent turns inside that session amortize against it. This avoids the cross-session re-warmup but does not avoid the per-cwd duplication.
3. Audit your active cwd count. The local JSONL grouping above tells you how many distinct paths your account has paid the warmup for. If that count is in the dozens against one project, the bill is non-trivial.

CLAUDE_CODE_DISABLE_GIT_INSTRUCTIONS=1 does NOT fix it. The flag mitigates #47107 (the git status injection at the top of the system prompt), not #53490 ^[2].

What to watch for

The fix has to anchor the cache key to project identity, not to literal cwd: git rev-parse --show-toplevel is the suggested anchor on #53490 ^[1], or the closest enclosing ~/.claude/projects/<slug> directory. As of 2026-04-27, neither #53490 ^[1] nor #48236 ^[2] has an Anthropic engineer comment on-thread; #53490 was auto-flagged as a duplicate by github-actions and is on a 3-day auto-close timer unless contested. The adjacent worktree-memory inconsistency #30667 (filed by kalaspace) ^[6] is a separate but compounding bug: auto-memory paths resolve to the main checkout while session JSONLs are stored under the worktree-specific slug.

Track #53490 ^[1] and #48236 ^[2] for movement. Until either lands, every new worktree opens a fresh prompt cache.

Fact Check

1. anthropics/claude-code#53490: the 92x cache-creation-to-input-token ratio, the 7-day daily samples (366x to 1,403x), 252M cache-create / 6.26B cache-read aggregate, 15 sessions / 25 cwd values, $35-per-review figure, 5-figure 30-day reconstruction, the suggested fix to anchor on git rev-parse --show-toplevel, the support refusal
2. anthropics/claude-code#48236: the bare-repo minimal repro, the Primary working directory: <cwd> system-prompt line as the diverging byte, the 15.9k warm read / 5.4k worktree write measurement, the verified non-effect of CLAUDE_CODE_DISABLE_GIT_INSTRUCTIONS=1
3. Prompt caching, Anthropic API Docs: byte-exact prefix matching, cache_creation_input_tokens and cache_read_input_tokens semantics, Sonnet 4.6 pricing ($3/M base input, $3.75/M 5-min write, $0.30/M cache read as of 2026-04-27)
4. Monitoring, Claude Code Docs: the claude_code.token.usage metric and its type attribute values ("cacheCreation", "cacheRead", "input", "output")
5. ccusage on GitHub: per-project / per-session cost reporting CLI for Claude Code; the reporter on #53490 paired it with manual JSONL parsing for per-cwd reconstruction
6. anthropics/claude-code#30667: the adjacent per-worktree memory-path bug (auto-memory resolves to main checkout while session logs use the worktree slug), filed by kalaspace

Source: anthropics/claude-code#53490