How Much Does Claude Code Cost? Plans, API, and Team Math

Search “how much does Claude Code cost” and the first page is a dozen pricing explainers that agree on the plan table and then disagree on the model prices, because half of them were written for a model family Anthropic has since replaced. Most pivot to the author’s own product by the final third. None of them answer the question an engineering manager actually has, which is not “what is the sticker price” but “what will this cost my team next month, who spent it, and did it ship anything”.

This post does both. First the sticker prices, every one read from Anthropic’s own pages in October 2026 and linked, because they move. Then the arithmetic for a team. Then the part the pricing page cannot show you: how YAGNI puts a developer’s Claude Code session and an Agent Team’s tickets on one meter, at 60% or more under comparable frontier API rates, with a Usage page that answers the manager’s question.

What does Claude Code cost on each plan?

Claude Code is the CLI; the plan is what you pay for. The Free plan does not include it. Every paid plan does. These are Anthropic’s published prices as of October 2026:

Plan	Price	Claude Code	Who it fits
Free	$0	Not included	Nobody writing code
Pro	$20 a month, or $17 a month billed annually	Included, within the plan’s limits	One developer, moderate use
Max 5x	$100 a month, five times Pro’s per-session allowance	Included	One developer, daily heavy use
Max 20x	$200 a month, twenty times Pro’s allowance	Included	One developer running long sessions or several at once
Team Standard	$20 a seat a month billed annually, $25 monthly; 2 to 150 seats	Included on every seat	A team where most people use it a few times a week
Team Premium	$100 a seat a month billed annually, $125 monthly	Included, with more usage per seat	The developers on the team who live in it
Enterprise	$20 a seat a month billed annually, 20-seat minimum, plus usage at API rates	Included	An org that wants seat admin and a metered bill in one contract

The Max tiers and their multipliers are from Anthropic’s Max plan article. Team and Enterprise inclusion is from Anthropic’s Team and Enterprise article. Read those pages again before you budget; the one thing every ranking explainer gets wrong is quoting a price six months old.

Two details change how the table reads. First, the CLI on a subscription shares the plan’s usage allowance with Claude chat, measured in a rolling five-hour window and a weekly window, and the allowance is not published as a token number. “Five times Pro” is the whole spec. Second, since CLI version 2.1.280 the default model on every plan is Opus 5.5, per Anthropic’s model configuration docs, which burns through an allowance faster than the Sonnet default that Pro and Team Standard had before. A developer who hit the weekly limit on Tuesday is usually a developer running Opus on work Sonnet would have done.

What does Claude Code cost on the API?

When a plan’s allowance runs out, or when you authenticate with an API key instead of a subscription, you pay per token at Anthropic’s API rates, as of October 2026:

Model	Input, per million tokens	Output, per million tokens	Cache read, per million tokens
Opus 5.5 (the default)	$4	$20	$0.20
Sonnet 5.5	$2	$10	$0.10
Haiku 5.5 (prompts up to 100K tokens)	$0.10	$0.50	$0.01

The cache read column is the one that matters for an agent. A session resends the whole conversation on every turn, and after the first turn most of that is served from the prompt cache at a twentieth of the input price. That is why a long session costs less than its token count suggests, and why a session that goes cold costs more: on a subscription the cache lives for an hour, but once a developer is drawing on usage credits, or on an API key, it drops to five minutes by default, per Anthropic’s cost docs. The first message after lunch reprocesses the whole context at full price.

Usage credits are how a subscriber keeps working past the plan’s limit. Per Anthropic’s extra usage article, they are prepaid, billed at standard API rates, and capped by a monthly spend limit you set, with optional auto-reload. On Team and Enterprise plans an admin turns them on and sets limits at the org, group, or member level. So a $100 Max seat is not a $100 ceiling; it is a $100 floor with a meter behind it that the developer can switch on.

How much does Claude Code cost per developer per month?

Anthropic’s own number, from the same cost docs: across enterprise deployments, about $13 per developer per active day and $150 to $250 per developer per month, with costs below $30 per active day for 90% of users. That figure doubled in April 2026, when Business Insider reported the docs had moved from $6 a day to $13 with no price change, as a heavier default model and longer sessions pushed usage up. Treat it as a median for API-billed use, not a ceiling. Third-party estimates vary from $100 to over $1,000 a month for a developer who runs agents all day, and none of them are measured the same way, so we will not stack them into a fake range here.

Here is the arithmetic for a team of ten developers, three of whom use Claude Code all day and seven a few times a week, using only the prices above:

Way to pay	Monthly bill before overage	What is hidden
Ten Pro seats, individually	$200	The three heavy users hit the weekly limit and either stop or buy credits on a personal card nobody sees
Team: 7 Standard plus 3 Premium, annual	$440	Usage credits once the Premium allowance runs out, at API rates, visible only after an admin turns on the spend report
Console, API key, at Anthropic’s average	$1,500 to $2,500	Nothing, which is the point: every token is on the Console usage page, but the bill has no floor

The Team row is the one most orgs land on, and the cost is fine. What the Team row does not give you is the answer to the second half of the question. The admin spend report shows estimated spend per user and per model, exported as a CSV and updated daily, and only once usage credits are on; inside the seat allowance usage is not metered in dollars at all. It tells you that Priya spent $38 of credits on Opus. It cannot tell you which ticket that was, whether it merged, or whether the $38 was one clean build or four retries of the same change.

Why is token price not what Claude Code costs your team?

Because the invoice counts tokens, and the team spends attention. Three things decide a team’s real cost, and only one of them is on the pricing page.

Retries. A session that starts from the wrong assumption costs a build, a review, a send-back, and a second build. The tokens are a fraction of it; the reviewer’s hour is the rest. The fix is not a cheaper model, it is context: an agent that reads the product decision before it plans does not take the round trip. We wrote up where that context lives in context engineering for coding agents.

Model choice by habit. Opus 5.5 is the default on every plan, and most tickets do not need it. Anthropic’s own advice is to keep Sonnet for most work and reserve Opus for architecture and multi-step reasoning. A developer who never runs /model is paying double on every turn. At a team level nobody enforces that, because nobody can see it per ticket.

Attribution. On Team plans the spend report is per user and per model. On the API the Console dashboard and the Claude Code Analytics API give daily per-user spend and accepted lines, and OpenTelemetry export streams per-user cost into your own stack. All of it is per developer. None of it is per unit of work, which is the grain a manager budgets in. “What did the payments migration cost” is not a question any of these tools can answer.

That gap is what YAGNI is built around, so the rest of this post is about the meter rather than the model.

How does YAGNI change what the same Claude Code costs?

YAGNI is additive to Claude Code, not a replacement for it. YAGNI reads the GitHub, Jira, Linear, and Slack the team already pays for and ships approved work back into them. Your developers keep the CLI, their CLAUDE.md, their skills and MCP servers, and the workflow they already have. Two things change: what the session runs on, and what the record shows.

The models. YAGNI Code, the developer’s own coding agent, routes across vetted US-hosted open-weight models at 60% or more under comparable frontier API rates. The same routing is open to Claude Code through YAGNI’s wire adapter. One command from the terminal:

yagni connect claude-code

After a restart, the same Claude Code session runs on YAGNI’s models, and the spend lands on YAGNI’s meter. The command writes Claude Code’s own settings file, so there is nothing to patch in the workflow, and --off removes the connection again. YAGNI does not publish which models serve which work; the lanes are upgraded as better models land and the rate card does not move. Where a task is hard enough that a frontier model would finish it in fewer attempts, that is a real trade, and we say so in the call rather than pretend the floor is free.

The meter. There are no seats on YAGNI. A developer with zero usage costs zero. Developers running YAGNI Code or Claude Code through the adapter, and the named Agents on a Team, bill on the same rate card and show up beside each other on the Usage page: spend, the parked-at-frontier benchmark, and savings, per developer and per Agent, with each Agent’s spend broken out by the job that spent it. A daily spend ceiling in Workspace settings is the brake. The rate card itself is shared on a call, not published; the only public claim is the 60% floor.

That is the per-developer half of the manager’s question answered without a CSV. The per-ticket half is the Team.

What does a ticket cost when a Team carries it?

An Agent Team on YAGNI mirrors one of your engineering teams and reports to one accountable person. A ticket moves through six stages, each owned by one Agent: Bailey, the Product Manager, proposes it from the backlog in Jira or Linear with evidence; Reeve, the Staff Engineer, plans it, reading the ticket, the linked Slack thread, and the Team’s decision ledger before it asks a person anything; a person approves the plan; Wright, the Builder, builds it to a draft pull request in a sandbox; Proctor, the Reviewer, posts one review a person can read; Fletcher, in beta, boots the environment and walks the change in a browser; and a person merges. Harper, the Chronicler, posts what shipped to Slack with the receipts attached.

Every one of those runs is metered on YAGNI’s rate card, the same one the developers are on, and the ticket’s case file shows what the workspace was charged for them. So the question the spend report cannot answer has a plain answer here:

Stage	Who did it	What a manager sees on the case file
Proposed	Bailey	The proposal, the evidence from the tracker, the cost of the proposal run
Plan	Reeve, then a person approves	The plan, the questions it asked, what the planning cost
Build	Wright	The draft PR, the runs, what each run cost
Review	Proctor	One review, the checks it ran, what the review cost
QA (beta)	Fletcher	The test plan, the video, what the walk cost
Done	A person merges	The total for the ticket, end to end

“What did PAY-212 cost, and did it ship” is one row. “Was the plan send-back cheaper than the build it prevented” is two rows. The YAGNI page we wrote for engineering managers, AI tools for engineering managers, walks through the Usage page in more detail. The point for a cost post is simpler: the cheapest token is the one a retry never spends, and a plan a person approved before a line was written is how a Team avoids the retry.

Which Claude Code plan should an engineering org pick?

The honest decision tree, in order:

1. One developer, inside the limits: Pro, then Max 5x when the weekly limit bites more than once a month. Switch the default to Sonnet for routine work.
2. A team that wants one bill and seat admin: Team, with Premium seats only for the people who use it all day, usage credits on with a per-member limit, and the spend report exported monthly.
3. An org that already meters everything: the Console, where every token is itemized and workspace spend limits cap the Claude Code workspace, with the Analytics API or OpenTelemetry for per-user numbers.
4. Any of the above, when the bill matters: connect the same Claude Code to YAGNI. Developers keep the CLI; the session runs at 60% or more under comparable frontier API rates; the spend shows up per developer next to the Agents.

The last step is where the arithmetic stops being about Claude Code. The same meter carries a Team that takes tickets from the backlog to a merged pull request under a plan a person approved, and a manager who can read what each ticket cost has a different budget conversation than one holding a per-model CSV. If you want the model run on your team’s numbers, book 30 minutes and bring your current plan and the number of active users. We will send the arithmetic back, and the rate card with it.

For the bigger picture, the managed version of this is Agent Teams for software development, and the offer itself is on the home page.