What a heavy-use Claude Code seat costs in production: 27 days of measured spend

Most answers to "how much does Claude Code cost per developer" start from an average. Anthropic's cost documentation puts enterprise deployments at about $13 per active developer day and $150 to $250 per developer per month, with 90% of users under $30 per active day. Press coverage of large rollouts adds a tail: power users at $500 to $2,000 a month.

Those numbers are useful for a first budget. They do not show what one real seat does when it is used all day, across a large codebase, with no cap. This article does.

Sparq works on a large multi-repository integration and infrastructure estate for a large US services company.

The measured numbers

For one seat over 27 days:

Dividing Claude Code spend by requests gives about $0.30 per request.

These figures come from the client's usage report for a single seat. They are not a team average and not a statistical sample.

How this compares with the published averages

Anthropic's $13 per active day is the average across enterprise users. This seat averaged about $100 per day over the 27-day window, roughly 7 to 8 times that figure. Its monthly run rate of about $3,000 sits above the $500 to $2,000 range press coverage reported for Uber engineers across AI tools and well above the $150 to $250 monthly average.

One caveat matters when reading the daily figure. Anthropic's number is per active day. The $100 here is spend divided by the 27 days in the window, so it is not directly comparable if the engineer had days off. Treat it as an order-of-magnitude comparison.

The takeaway is that a developer using Claude Code as the primary way to change a large estate can land in the tail of the distribution, and a plan built on the average will miss it.

What is likely driving the cost

Three conditions in this deployment likely push spend up. The usage report does not attribute spend to each one:

• Cross-repository sessions. The workspace root is launched above all repositories, so work that spans repositories happens in one session. Larger context means more input tokens on every turn.
• Opus as the working model. Developers choose their model with /model, and most work runs on Opus.
• No usage cap. The license has no usage restrictions and no token caps, and none has ever been hit. This was a joint decision with the client, made on Sparq's recommendation.

Why the client chose not to cap it

The reasoning is a governance principle: control the point of action, not the point of consumption. Capping an agent's questions does not make its answers safer.

The controls in this deployment sit on what the agent can do:

• A filesystem boundary limits writes to two directory trees and runs subprocesses in an OS-level sandbox.
• A command policy allows reading and inspection and denies mutating commands.
• Production, third-party business systems, and cloud management APIs sit behind per-occasion grants that the next task does not inherit.
• Systems of record are protected by write-tool denial.
• Claude Code connects to one MCP server, enforced, with a change-control policy for adding more.
• No agent has deployment authority. Existing CI pipelines deploy the code.

The client is deliberately encouraging more usage and monitors spend instead of capping it. Spend is visible to the client's engineering manager and the developer, who share the reporting manually.

What the spend bought

Two kinds of numbers appear in this story, and they have different standing.

Measured: spend, requests, and the model mix described above, from the usage report.

Judgment: delivery speed. The engineer who did the work both ways estimates that a change on this estate took three to six business days before Claude Code and takes a few hours now. That is the engineer's assessment, not a figure pulled from ticket timestamps. The same engineer estimated the broader technology shift at six to twelve months and reached a working, testable MVP in seven business days.

At about $3,000 a month, the question for a team is not whether that is high. It is whether the delivery change on your own estate is worth it, and whether you can see the spend well enough to tell. Here, the client's answer was to keep the seat uncapped.

What we would do differently when budgeting

• Budget from the tail, not the mean. If you plan to have an engineer drive large cross-repository changes, model that seat separately from the average seat.
• Make spend visible to someone who can act on it. In this deployment reporting is shared manually. That works for three seats. It will not scale to a larger rollout without automation.
• Decide what you are governing. If you cap consumption, you limit cost but not risk. Controls on actions, such as sandboxing, command policy, and grants for sensitive systems, address risk directly.
• Write down what you did not measure. Cost control is easier when ownership is explicit.

About this deployment

Sparq runs enterprise Claude implementation, including Claude Code policy setting, skills and prompt libraries, telemetry, and human review gates. Learn more about Sparq's Claude implementation services.