A shared CLAUDE.md is billed once per seat, at the same time
You wrote the file once. Your team pays for it in parallel. Every session that opens the repo re-injects the whole CLAUDE.md on every turn, so a team running it concurrently pays your per-turn token count once for every engineer, all at once.
Direct answer (verified 2026-05-21)
Yes, a shared CLAUDE.md costs more across parallel sessions, linearly. The file is re-injected every turn of every session that loads it, and sessions do not share a cache. So a team of M engineers working the same repo in parallel pays your per-turn token count M times simultaneously. The corollary is the useful part: cutting one bloated line saves M times over. The per-turn dollar number ccmd prints is the per-seat floor; your headcount is the multiplier.
Source on the per-session model: Anthropic's cost docs (each session and teammate keeps its own context window), code.claude.com/docs/en/costs.
The number you read is per seat. The bill is per seat times headcount.
Most advice about CLAUDE.md cost stops at one engineer. You paste your file somewhere, you get a per-session token figure, you nod. But a shared CLAUDE.md is a team artifact, and the cost model that matters is the team one: how many people have this repo open right now, each running their own session, each re-paying the file every turn.
The file does not get cheaper because it is shared. It gets more expensive, because the same tokens are paid in parallel by everyone who loads it. A single line nobody reads is not a small mistake. It is a small mistake multiplied by your headcount, every turn, every day.
One shared file, paid by every parallel session
No cross-session cache for the file. Each lane re-injects the whole CLAUDE.md every turn.
Worked example: eight engineers, one 6k file
Take the example file the analyzer ships with: 6,000 tokens. One engineer running a 30-turn long session pays $2.70 in input cost just for the file. Now run eight people against the same repo on the same afternoon. The file did not change. The bill did.
Where the per-seat number comes from
The number ccmd prints is not a guess. The analyzer assumes the worst honest case: the whole file fires every turn. That assumption is one line of code, and it is the right one for a shared file, because a shared CLAUDE.md is exactly the kind of always-on context that rides along on every turn of every session.
Line 264 sets the per-turn token cost to the literal size of the file you pasted. Lines 265 to 269 turn that into a dollar figure at a 30-turn session and the $15 per million input rate for Opus 4.7. That is one seat. Multiply by the number of seats running the repo and you have the parallel-team cost the rest of the internet does not print.
The shared-file mental model vs. how it actually bills
| Feature | What teams assume | What actually happens |
|---|---|---|
| Who pays for the file | Whoever edited it last (the mental model) | Every session that loads it, every turn, in parallel |
| How many times one bloated line is billed | Once, you assume | Once per parallel seat, simultaneously |
| Where the cost shows up | Hidden inside per-engineer Max usage | Spread across N weekly limits, hard to trace to the file |
| What a 1,500-token cut returns | A smaller diff | Token savings multiplied by your parallel headcount |
| Who notices when the file drifts up | Nobody, until a Wednesday rate-limit | The whole team at once, because they share the cost |
Per-engineer cost rollups are part of ccmd's paid tier, alongside continuous monitoring and a weekly drift email; the free analyzer prints the single-seat per-session number you multiply.
The fix: treat the shared file like a hot loop
A shared CLAUDE.md is the most expensive file in the repo on a per-line basis, because its cost is multiplied by everyone who loads it. Review additions to it the way you would review a function that runs millions of times. Three things move the bill more than anything else:
- Audit the shared file first, with the multiplier in mind. Paste it into the ccmd analyzer, read the per-seat number, then multiply by your active headcount. That is the real cost. Cut the lines flagged as bloat, vague, or dead, and the saving multiplies the same way.
- Push rarely-needed instructions into skills. Anything that is not needed on every turn does not belong in a file that fires on every turn for every seat. Move it into an installable skill that loads on demand. Each cut line is removed from every seat at once.
- Attribute the cost per engineer. The reason a fat shared file goes unnoticed is that its cost hides, evenly spread, across N people's usage. Per-engineer cost rollups make the tax visible seat by seat so an upward drift in the shared file gets caught the week it happens.
If you also fan out subagents or agent teams inside each session, the two multipliers stack. See the companion breakdown on CLAUDE.md cost with parallel agents for the within-session fan-out math, and the weekly-quota burn breakdown for why several engineers hit the cap on the same day.
Sharing a CLAUDE.md across a team that keeps hitting limits?
Bring your shared file and your headcount; we will work out the parallel cost and what to cut first.
Frequently asked questions
Does a shared CLAUDE.md cost more when several engineers run it in parallel?
Yes, and the cost is linear in headcount. A CLAUDE.md checked into a repo is loaded by every Claude Code session that opens that repo, and the file is re-injected on every turn of each session (the analyzer assumes this exactly: estimatedTokensFireEveryTurn = totalTokens, analyzer.ts:264). So if eight engineers are working the same repo on the same afternoon, your per-turn token count is being paid eight times, concurrently, across eight separate Max seats and eight separate weekly limits. The file is shared; the cost is not pooled, it is duplicated.
How is this different from the parallel-agents (subagent / agent-team) cost?
Different multiplier, same file. Fanning out subagents or an agent team multiplies CLAUDE.md cost inside one engineer's session (Anthropic puts agent teams at roughly 7x a standard session because each teammate maintains its own context window). That is covered in our parallel-agents breakdown. This page is about the organizational multiplier: M engineers, each running their own session against the same shared file. The two stack. An eng lead whose team both shares a fat CLAUDE.md and fans out agent teams is paying the file cost (headcount) times the fan-out cost (team size).
Where does ccmd get the per-turn number I should multiply?
From the analyzer on ccmd.dev. Paste your shared CLAUDE.md and it prints totalTokens (chars / 4, the same heuristic the CLIs use) and an estimatedCostPerLongRunSession computed as totalTokens x 30 turns x $15 per million input tokens at Opus 4.7 rates (analyzer.ts:263-269). That dollar figure is the per-seat floor for one engineer. To get the real team number, multiply it by the count of engineers running the repo in parallel. The analyzer prints the unit; your headcount is the multiplier.
If I cut 1,500 tokens from a file eight people share, what is the actual saving?
1,500 tokens x 30 turns x $15/M is about $0.675 saved per seat per long session. Across eight parallel sessions that is roughly $5.40 saved per round of work, from a single edit, with no behavior change if the lines you cut were dead weight. That is the leverage of editing a shared file: every line you remove is removed from every seat at once. It is the inverse of the problem, which is why the shared file is the highest-leverage thing to audit on a team.
Why doesn't this show up clearly in our billing?
Because the cost is split across N engineers' usage. One bloated shared file does not produce one big line item; it produces a small, identical tax on every seat, which is exactly the shape that hides in noise. Nobody sees 'the CLAUDE.md cost us $X' because it never lands in one place. It surfaces instead as several engineers independently hitting a weekly Max limit on the same Wednesday, with no obvious common cause. The common cause is the file they all share. ccmd's paid tier ships per-engineer cost rollups so the tax becomes visible per seat instead of disappearing into aggregate usage.
Does pooling or caching make the shared file cheaper across sessions?
No. Each Claude Code session is its own context window with no cross-session cache for your CLAUDE.md, so two engineers in two terminals do not share a cached copy of the file. Git worktrees and background agents are full sessions too, not subagents, so each one loads the full file independently. There is no shared-team discount on a shared file. The only lever is the file itself: fewer tokens in the file means fewer tokens paid by every seat that loads it.
What is the cheapest shared-CLAUDE.md pattern for a team?
Three habits. First, treat the shared CLAUDE.md as the most expensive file in the repo on a per-line basis, because its cost is multiplied by headcount, and review additions to it the way you would review a hot loop. Second, keep it short (Anthropic suggests staying under about 200 lines on the costs page) and push project-specific or rarely-needed instructions into installable skills that load on demand instead of every turn. Third, attribute it: watch per-engineer cost so an upward drift in the shared file is caught the week it happens, not after three people hit their cap.
Does the analyzer model the parallel-team cost for me?
Not yet in the free one-shot. The analyzer scores one file and prints the single-seat per-session number. The parallel-team math is the multiplication you do on top: per-seat cost times engineers running the repo. The paid tier is where the team view lives: continuous monitoring, a weekly drift email with a real token-savings number, PR diff comments on changes to the shared file, and per-engineer cost rollups so the multiplied cost is attributed seat by seat rather than left implicit.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.