Claude Code's Prompt Cache Cost Depends on How You Launch It
Claude Code prompt-cache costs vary by launch path: measurements reveal a large fixed overhead and a subagent fan-out cost multiplier.
A developer measured Claude Code's prompt-cache behavior by running the identical empty project through three launch paths — the VSCode extension, a terminal inside VSCode, and a standalone terminal like iTerm2 — and reading cache_creation and cache_read token counts straight from the session JSONL logs. The standalone terminal never touched Anthropic's shared prompt cache at all: cache_read stayed at zero on every turn, meaning it paid full cache_creation cost every single time. Both VSCode-based paths, by contrast, consistently hit the shared cache with identical results.
Even more notable: after stripping out CLAUDE.md files, custom skills, and hooks, roughly 85% of the remaining cache_creation cost turned out to be Claude Code's own fixed overhead, not anything the user configured. The user-controllable share came out to only about 15% in this project. On top of that, subagents don't inherit the parent session's cache — each one pays its own fixed cache_creation cost, so parallel subagent fan-out multiplies that fixed cost linearly.
For engineers, the practical takeaway is that trimming CLAUDE.md still helps, but the bigger cost lever is which client/terminal launches the session and how many subagents run in parallel — variables that can dwarf any savings from configuration cleanup alone.