The Cost Problem at Scale

You deploy Claude Code to five developers. The first month costs $200. The second month costs $800. The third month someone runs a refactoring agent overnight and the bill is $3,400.

This is not a hypothetical. It is the most common trajectory for teams that deploy Claude Code without monitoring. And the reason is simple: Claude Code is not a chatbot with predictable per-message costs. It is an autonomous agent that calls tools, reads files, writes code, runs tests, and makes API requests in loops. A single developer prompt can trigger dozens of API calls, each consuming tokens.

The cost equation is straightforward but often misunderstood:

Cost = Input Tokens + Output Tokens + Cache Creation + Cache Read

Input tokens include your prompt, the system prompt, CLAUDE.md, any files Claude reads, and the conversation history. Output tokens are what Claude generates. Cache creation happens when Claude stores context for reuse. Cache reads are cheaper but still count.

The surprise comes from the input side. When Claude Code reads a large codebase to understand context, it can consume 100K+ input tokens before generating a single line of output. Multiply that by 10 developers running 20 sessions each per day, and you see why costs compound.

The second surprise is that not all sessions are equal. A developer who asks Claude to "fix this typo" uses 1,000 tokens. A developer who asks Claude to "refactor this module to use the new API" might use 500,000 tokens across dozens of tool calls. Without visibility into per-session costs, you cannot optimize.

Before you set up dashboards or configure alerting, understand the three metrics that every engineering leader needs to track.

1. Cost per developer per day. This is your baseline. Measure it for two weeks before making any optimization decisions. The typical range is $5-50 per developer per day depending on how heavily they use Claude Code. If someone is consistently above $100/day, investigate their usage patterns, not to punish, but to optimize.

2. Token efficiency ratio. Compare input tokens to output tokens. A healthy ratio is roughly 3:1 to 5:1 (input to output). If you see 20:1 or higher, Claude is reading enormous context windows to produce small outputs. This usually means the project structure or CLAUDE.md could be optimized to reduce unnecessary context.

3. Active time vs idle time. Claude Code tracks both. Active time is when a developer is actually interacting (typing, reading responses) or when the CLI is processing (tool execution, AI responses). High active time relative to session duration means productive usage. Low active time means sessions are sitting open and potentially accumulating context window costs on reconnection.

These three metrics give you 80% of the insight you need. Everything else, commits, PRs, lines of code, is secondary until you have cost visibility.

Understanding Claude Code token pricing is essential before you can optimize it.

Model pricing varies significantly. Opus costs roughly 10x more than Haiku per token. Sonnet sits in between. If your developers are using Opus for tasks that Sonnet handles equally well, you are overspending by 3-5x on those tasks.

Here is the general pricing structure (check Anthropic's current pricing page for exact numbers):

• Haiku: Cheapest. Good for simple tasks, classification, extraction.
• Sonnet: Mid-range. The workhorse for most development tasks.
• Opus: Most expensive. Best for complex reasoning, architecture decisions, nuanced analysis.

Cache tokens matter. Claude Code uses prompt caching aggressively. When Claude reads your CLAUDE.md, project files, and conversation history, much of that context gets cached. Subsequent requests reuse the cache, which costs significantly less than fresh input tokens. This is why the first request in a session is often the most expensive.

The Advisor Strategy changes the math. Anthropic's Advisor tool (released March 2026) lets you run Sonnet as the executor with Opus consulting only when needed. This reduces costs by roughly 12% compared to Sonnet alone while improving quality on hard problems. For teams running primarily on Sonnet, this is the single highest-impact optimization.

Fast mode does not change the model. A common misconception: fast mode uses the same model (Opus or Sonnet) with faster output. It does not switch to a cheaper model. The cost per token is the same. The benefit is speed, not savings.

Most teams try to optimize Claude Code costs before they have any data. They set model restrictions, limit session durations, or restrict tool access. These approaches usually backfire because they reduce developer productivity without knowing whether the cost savings justify it.

The correct order is:

1. Measure first. Deploy OpenTelemetry monitoring (covered in Module 2). Collect two weeks of baseline data without changing anything.

2. Identify patterns. Which developers cost the most? Which sessions consume the most tokens? Which models are being used for which tasks? Is the spending correlated with productive output (commits, PRs) or not?

3. Optimize with evidence. Once you have data, you can make targeted changes: switch specific workflows to cheaper models, optimize CLAUDE.md to reduce context loading, set up alerts for runaway sessions, and guide developers toward efficient patterns.

4. Measure the impact. After making changes, compare the new baseline to the old one. Did costs go down? Did productivity stay the same or improve?

This data-driven approach takes about a month from start to finish. It is slower than slapping restrictions on day one, but it produces lasting results without alienating your developers.

The rest of this track walks you through each step with specific tools, configurations, and templates. By the end, you will have a complete monitoring stack, a cost optimization playbook, and an ROI report template that your leadership team will actually read.