Massive cache-create on git worktree — cwd-keyed prefix breaks reuse, 92x cache-create/input ratio

Summary

Claude Code CLI appears to key its cacheable prefix (CLAUDE.md + project memory + plugin state) on the literal cwd rather than on the git repository root. As a result, every git worktree directory under the same repo triggers a fresh full-cache event, even though the cacheable content is byte-identical. Over 30 days this produced a cache-creation/input-token ratio of ~92× on my account (expected: < 2×).

Severity

High — billing impact in the 5-figure USD range over 30 days for a single workflow that uses git worktree for parallel feature work. Affects any team using:

• git worktree for parallel branches
• The Claude Code Review GitHub App on PRs that originate from worktree branches
• Multi-feature PDCA / agentic workflows that switch directories within one session

Reproduction

1. cd repo-with-CLAUDE.md && claude → first cache-create event (expected, ~10K cached tokens)
2. git worktree add .claude/worktrees/feature-x feature-x
3. cd .claude/worktrees/feature-x && claude --continue

→ Second full cache-create event for the same logical project, despite identical CLAUDE.md / memory / plugin state.

1. Repeat for N worktrees → N × full cache cost, with no amortization.

Observed Behavior (one repo, my data)

| Metric | Value |
|---|---:|
| Sessions in ~/.claude/projects/<one-repo>/ | 15 |
| Distinct cwd values across those sessions | 25 |
| Total cache-create tokens | 252,267,892 |
| Total cache-read tokens | 6,264,999,480 |
| Reconstructed cost | 5-figure USD |
| Mean cost per session | high 3-figure USD |
| Max single-session cost | low 4-figure USD |

The 25 distinct cwd values are all subpaths of the same git repo. Examples:

~/proj/<repo>
~/proj/<repo>/.claude/worktrees/feature-a
~/proj/<repo>/.claude/worktrees/feature-b
~/proj/<repo>/.claude/worktrees/feature-c
~/proj/<repo>/src/app/<module>
~/proj/<repo>/projects/<dated-folder>
~/proj/<repo>/scripts/<subdir>
... etc.

All 25 paths share:

• Same git repository root (git rev-parse --show-toplevel is identical)
• Same CLAUDE.md (single file at repo root)
• Same ~/.claude/projects/<repo-slug>/memory/ directory
• Same plugin configuration

A correctly designed cache key would yield an identical cacheable prefix across all 25 entry points.

Cache-Create / Input Ratio (7 daily samples)

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

The ratio worsens over time as more worktrees and subdirectories accumulate.

Claude Code Review on Worktrees (separate amplifier)

The Claude Code Review GitHub App, when invoked on PRs originating from git worktree branches, exhibits the same behavior. In one observed 2-day window:

• Repos affected: 1
• PRs merged: 15
• claude[bot] review submissions: 19
• Cost on the Claude Code Review service line: low 3-figure USD
• Effective cost per review: ~$35 (community-reported norm: $1–$5)

Sample PR sizes were small-to-medium feature increments, including a chore: archive PR. Nothing about the diffs would justify a 7-35× cost premium.

Likely Root Cause

The cacheable prefix appears to be invalidated whenever cwd changes — even when the cwd change is within the same git repository. This collapses cache reuse for:

• Parallel git worktree workflows
• Sessions that cd into subdirectories (project layouts with scripts/, projects/, src/app/<feature>, etc.)
• The Claude Code Review GitHub App where each PR's checkout sits at a different path
• Conductor-style workspace forks

Suggested Fix

Key the cacheable prefix on git rev-parse --show-toplevel (or the closest enclosing ~/.claude/projects/<slug> directory) rather than on the literal cwd. Within one logical project, the cacheable prefix should be stable across:

• Worktree subdirectories
• Subfolder navigation within the same repo
• Conductor / Claude Code Review GitHub App invocations

Tooling

Local analysis was done with ccusage and direct parsing of the JSONL session logs at ~/.claude/projects/<repo-slug>/*.jsonl. The cwd field is present on each request entry, which makes the per-cwd cost reconstruction straightforward.

Why I'm filing publicly

I have already raised this with Anthropic support. Their automated agent (Fin AI) declined to refund the affected charges and declined to route the dispute to a human specialist or to engineering. The agent did acknowledge two factual inconsistencies on the record (the citation pattern they used to justify denial is in support documentation, not the formal Credit Terms; and they could not reconcile an "Inactive" account status with active charges in the same period).

I'm filing here so the engineering team can evaluate the cache-key design and so other users running similar workflows can be aware. The technical fix benefits all customers using worktrees or the Claude Code Review GitHub App.

Environment

• Claude Code CLI on macOS (Apple Silicon)
• Multiple plugins active (PDCA workflow plugin with SessionStart hooks)
• Project structure: single git repo with 11 active worktrees + standard subdirectories
• CLAUDE.md ~5 KB, project memory ~116 markdown files

What would help diagnose this

If the Claude Code team can share:

1. The exact composition of the cache key for the cacheable prefix
2. Whether the cache key is documented anywhere user-facing
3. Whether git worktree and cwd-within-repo changes are intentionally different cache namespaces

— that would let users adjust workflows pre-emptively. Right now this is an invisible billing footgun.