Cost accounting for AI-assisted work: what actually shows up on the bill

Six months into serious Claude Code adoption, our monthly bill went from "rounding error" to "someone in finance wants a meeting." What followed was three weeks of figuring out where the money was actually going — which was harder than any of us expected. Not because the raw data was missing, but because the intuitive categories ("who used it, for what") don't map cleanly to what actually costs money. This post is the anatomy of a Claude Code bill after we finally understood it.

The short version: most cost attribution frameworks that teams reach for don't work well for AI-assisted work. The categories that DO work aren't the ones you'd design from first principles — they emerged from noticing what actually varied across our usage. Here's that breakdown, plus the specific attribution model we ended up with.

The bill you actually get

The invoice from Anthropic has one line: total tokens by model. That's it. No user attribution. No project attribution. No workflow attribution. Just total input tokens and total output tokens, priced by model tier.

This is the source of most confusion. "Whose usage was this?" and "what project drove this cost?" aren't answered by the invoice. To answer them, you need instrumentation you built yourself. Most teams don't have this until the bill gets big enough to justify the engineering work — by which point they've been over-spending for months without knowing where.

The five real cost categories

Once we had instrumentation, we could categorize where tokens actually went. Five categories, in rough order of magnitude for us:

Category 1: The MCP tax (biggest surprise)

MCP tool descriptions load into every session. Every session. A team with 8 MCPs connected, each averaging 15 tools with 150-token descriptions, pays roughly 18,000 tokens per session as pure MCP overhead. Multiply by sessions per month.

For us: MCP tax was 34% of our monthly bill at peak. Two-thirds of THAT was from three MCPs we'd installed because "it seemed useful" but rarely invoked tools from. Pruning aggressively (see the MCP pruning post) cut this category by more than half.

This category surprised everyone because it's not visible in any usage report. Tokens spent on MCP descriptions produce nothing — no code, no answers, just context tax. Most teams don't know how much of their bill this is until they measure.

Category 2: CLAUDE.md and skills overhead

Same shape as MCP tax — content that loads ambient into sessions regardless of whether it's needed. A 5000-word CLAUDE.md adds 7000+ tokens to every session. Skills that always load add their token cost too.

For us: 12% of monthly bill before we cut CLAUDE.md from 4800 to 380 words (see the CLAUDE.md post). Post-prune, this category dropped to about 3%.

Categories 1 and 2 together — the "ambient overhead" category — were more than 40% of our bill at peak. Almost half of what we were spending produced no direct work; it was just context tax paid on every session.

Category 3: Agentic loops (highest variance)

Subagents doing multi-step work — code reviewers, refactoring agents, investigation agents — spend real tokens because each iteration adds context. A single long-running agentic session can cost $10-30 in tokens; most sessions cost cents.

For us: 28% of monthly bill, and the highest variance category. Most sessions were cheap; a small number of runaway loops (before we implemented the non-spiraling prompt structure) dominated total spend from this category. After implementing iteration budgets, this category dropped to about 15% of bill despite unchanged usage volume.

The variance matters. When 5% of sessions produce 60% of category spend, tracking averages misses the story. You need to look at the tail — the 95th and 99th percentile — to understand what's really happening.

Category 4: Direct chat usage

Engineers using Claude Code interactively — asking questions, exploring code, writing new features with back-and-forth conversation. This is what most people think of when they think "Claude Code usage."

For us: 18% of monthly bill. Smaller than we expected. Individual sessions here range from very cheap (a few questions) to moderately expensive (long feature-building conversations), but the aggregate was smaller than either ambient overhead (Categories 1+2) or agentic loops (Category 3).

The insight: the visible usage (engineers actively chatting) isn't where most of your money goes. It's the invisible usage (ambient overhead per session, plus agentic loops that run in the background) that dominates.

Category 5: Background jobs and automation

Scheduled subagent runs — nightly doc sweeps, PR review bots, monitoring loops. Runs without direct human involvement.

For us: 8% of monthly bill. Small because we'd been conservative about scheduling automated jobs. Teams that heavily automate see this category much larger — a nightly full-codebase scan can be a $50-200 job by itself.

This category is worth watching because it grows silently. A background job you set up six months ago is still running; nobody remembers to check whether it's producing value. Quarterly audits of scheduled jobs are essential.

The categories that DON'T matter

Worth noting what didn't drive material cost, despite common intuition:

Individual "power user" engineers. The heaviest individual users had 3-4x the token spend of average users. Not 20x. Individual variance matters less than category variance.

Long chat conversations. Even a 2-hour chat rarely costs more than $2-3. What costs money is many sessions, not long sessions.

Rich code output. Generating 500 lines of code in one shot costs a few cents. Output tokens are much cheaper than input tokens (in the current pricing structure), so generation-heavy work is actually cost-efficient.

The pattern: cost is driven by "invisible" categories (ambient overhead, agentic loops with iteration) rather than "visible" ones (individual engineers writing code). Attribution frameworks that focus on the visible categories miss the actual cost drivers.

The attribution problem

Once you have category breakdown, you still need to attribute cost to teams or projects for chargeback. This is where most frameworks break down.

Attribution by user works for Category 4 (direct chat). The engineer who ran the chat is the natural attributee. Track by session, aggregate per user.

Attribution by user is weird for Categories 1-2 (ambient overhead). Whoever's session it was pays the overhead tax, but they didn't choose to install those MCPs or write that CLAUDE.md. The "responsible" party is the team that maintains the shared config.

Attribution by user is misleading for Categories 3 and 5 (agentic loops and background jobs). The engineer who invoked a subagent isn't the one who designed it or set its iteration budget. Sharing cost across all users of the subagent, or attributing to the subagent's owner, both make more sense.

What we settled on: hybrid attribution. Direct chat costs go to the individual user. Ambient overhead costs get distributed across the team that maintains the shared config. Subagent invocation costs get split — a portion to the invoker (they chose to use it), a portion to the subagent's owner (they own its efficiency). Background job costs go entirely to the team that scheduled them.

This is more complex than "each user pays for what they invoke" but produces more accurate incentives. The team maintaining shared config feels the cost of that config (encourages pruning). Subagent owners feel the cost of their subagents' inefficiency (encourages optimization). Users feel the cost of their choices but not costs they didn't control.

The metrics that predict future cost

For forecasting — will next month be higher, lower, same? — the leading indicators aren't total spend. They're shape metrics:

• Sessions per engineer per week. Growth here means more usage; more usage means more ambient overhead cost, which scales linearly.
• MCPs connected per team. Growth here means more ambient tax per session; catches proliferation before it hits the bill.
• Average agentic-loop iterations. Growth here means agents are working harder per invocation; could mean tasks getting harder, or could mean spiral drift.
• Long-tail session cost (P95 and P99). Growth here catches spiraling loops before they dominate the bill.
• Background job count and per-job cost. Growth here catches automation creep.

We track all five of these on a weekly dashboard. When any starts trending up, we investigate before the bill catches up. Reactive cost management (waiting for the invoice to be too big) always costs more than proactive.

The optimization sequence

When we finally started optimizing, we did it in order of highest-leverage first. The sequence that worked:

1. Cut MCP surface (Category 1). Biggest single savings. Pruned from 8 MCPs to 4, and within those, restricted tool access to actively-used tools. Cut Category 1 by 55%.
2. Prune CLAUDE.md (Category 2). Second biggest. 4800 → 380 words. Cut Category 2 by 75%.
3. Add iteration budgets to agentic loops (Category 3). Cut the tail (P95, P99) of session cost. Cut Category 3 by nearly half.
4. Audit and retire unused background jobs (Category 5). Small individual jobs added up. Cut Category 5 by about 30%.
5. Right-size model routing (spans multiple categories). Moved bulk classification work from Sonnet to Haiku; moved judgment work confidently to Opus. Mixed impact, but stable cost improvement.

Total: monthly bill dropped 62% without reducing team usage. Same number of sessions, same number of engineers, similar work output. The savings came entirely from cutting overhead and preventing waste, not from limiting productive use.

This matters because "cut Claude usage" is the wrong lever. The bill is dominated by overhead and waste, not by productive use. Cutting productive use hurts output without cutting most of the cost. Cutting overhead cuts the cost without hurting output.

The reporting cadence that worked

For our team of ~40 engineers, the reporting cadence we landed on:

• Daily automated check — is today's spend unusual?
• Weekly leading-indicator dashboard — the 5 metrics above
• Monthly category breakdown — where did spend go?
• Quarterly deep audit — what changed, what needs pruning, what optimization opportunities exist?

The daily check has caught more surprise cost events than any other. The monthly breakdown has driven the most systematic improvements. The quarterly audit has caught long-term drift.

The counterintuitive lessons

Three things we learned that ran against intuition:

1. Your bill is dominated by tokens that produce no work. Ambient overhead (Categories 1+2) can easily be 40%+ of spend. Everyone assumes their bill reflects productive work; usually most of it doesn't.

2. Individual power users aren't the problem. Distribution of per-user spend is flatter than expected. The problem isn't heavy individual usage; it's system-level overhead affecting all users.

3. Cost optimization improves output. Cutting MCP surface reduced tool-selection confusion; pruning CLAUDE.md improved attention to remaining guidance; iteration budgets caught spiraling loops. Every optimization we made improved OUTPUT while cutting cost. This is unusual — most cost-cutting hurts output. AI infrastructure has enough waste that cutting waste actually helps.

Where to start

If you're not currently instrumenting cost by category, that's the first move. Even rough categorization (aggregate MCP overhead vs everything else) tells you more than the raw invoice. Once you know where money goes, the highest-leverage cuts become obvious.

Skip the exercise of "asking engineers to use Claude less" until you've done the category audit. Almost certainly, engineer usage isn't your problem. The overhead is. Cut that first; you'll probably find you didn't need to touch actual usage patterns to hit whatever budget target you have.