Claude Code Team Plan: Budgeting a Rollout for Your Org

An engineering leader who searches for the Claude Code Team plan is not asking what Claude Code is. They have developers using the CLI already, on a scatter of Pro subscriptions and personal cards, and they want one bill, one admin, and a number they can put in next quarter’s budget. The pages that rank mostly restate the seat prices, four of the top six get the seat details wrong, and none of them model what happens after the seats are bought, which is where the real cost lives.

This post does the budgeting. Every price was read from Anthropic’s own pages on October 16, 2026 and is linked, because they move. Then the arithmetic for a 30-developer org, three ways. Then the two things the Team plan cannot do for a manager: show spend per unit of work, and put the coding agents on the same meter as the people. YAGNI is built for both, and the post ends there.

What does the Claude Code Team plan include?

There is no separate “Claude Code Team plan”. Claude Code is included with every seat on Anthropic’s Team plan, and the plan is what you buy. The terms, from Anthropic’s pricing page and the Team and Enterprise article, as of October 2026:

Seat	Price, billed annually	Price, billed monthly	What it buys
Team Standard	$20 a seat a month	$25	All Claude features, more usage than Pro, Claude Code included
Team Premium	$100 a seat a month	$125	Five times the usage of a Standard seat, Claude Code included
Enterprise	$20 a seat a month, 20-seat minimum	Not offered monthly	Seat admin, SSO and SCIM, role-based access, audit logs, plus usage billed at API rates

A Team runs from 2 to 150 seats and you can mix seat types. The ranking explainers that say a Standard seat excludes Claude Code, or that Premium is $150, are quoting something Anthropic never published. Read the two pages above before you budget, and read them again before you renew.

Three details matter more than the prices. First, the allowance behind a seat is not published as a token count: “five times Standard” is the whole specification, measured in a rolling five-hour window and a weekly window that the CLI shares with Claude chat and the IDE extensions. Second, Team plans include up to $500 a month in pooled API credits, and the same article states those credits cannot be used in the CLI or the Claude apps. They fund the Claude Platform, not your developers’ sessions. A budget that counts them against the CLI is $500 a month wrong. Third, the current Enterprise plan is a different shape of bill: the seat buys the admin controls, and the usage is metered at API rates on top, so cost scales with the models and tasks your team uses, as Anthropic’s page puts it.

Where does a Team seat stop and the meter start?

A seat is a ceiling, not a cost. When a developer reaches their allowance they wait for the window to reset, or they keep working on usage credits. Per Anthropic’s cost docs, an organization owner turns usage credits on, the credits bill at standard API rates, and admins set spend limits at the organization, group, or individual member level. Usage inside the seat allowance is not metered in dollars at all. The spend report in the admin analytics covers usage-credit spend only, as a CSV per user and per model updated daily, and it appears once credits are on.

The API rates that apply past the allowance, from Anthropic’s pricing page as of October 2026:

Model	Input, per million tokens	Output, per million tokens	Cache read, per million tokens
Opus 5.5	$4	$20	$0.20
Sonnet 5.5	$2	$10	$0.10
Haiku 5.5	$0.10	$0.50	$0.01

So a Team plan has two bills. The seat bill is fixed and easy. The credit bill starts the day your heaviest developer hits the weekly limit on a Tuesday, and from then on the question is how many developers spill, how often, and on which model. Anthropic’s own figure for metered use, from the same cost docs, is around $13 per developer per active day and $150 to $250 per developer per month, with 90% of users under $30 an active day. Treat that as the shape of the overflow, not its size: a developer on a Premium seat spills only on the days the allowance runs out.

What does a 30-developer rollout cost on the Team plan?

Here is the arithmetic for an org of 30 developers, eight of whom live in the CLI all day and 22 who use it most days for an hour or two. Prices as above, annual billing where it exists.

Way to pay	Seats	Monthly seat bill	Where the meter starts	What the admin sees
Team, 22 Standard and 8 Premium	30	$1,240 ($440 plus $800)	Usage credits at API rates once a seat’s allowance is spent	Credit spend per user and per model, daily CSV; nothing inside the allowance
Team, 30 Standard	30	$600	Sooner, for the eight heavy developers, who either stop or spill onto credits most weeks	Same report, more rows in it
Enterprise	30	$600, plus every token at API rates	Day one; at Anthropic’s $150 to $250 average, $4,500 to $7,500 of usage a month	Spend limits per user and org, Enterprise Analytics API with per-user cost

The first row is the one most orgs land on, and the seat bill is fine. Now add overflow. Suppose each of the eight heavy developers runs out of allowance four active days a month and spends Anthropic’s average of $13 a day on credits while they do. That is $416 a month, a third again on top of the $1,240, and it does not appear on the budget line, because it is spent as credits. If the heavy developers leave the default model on Opus 5.5 for work Sonnet 5.5 would do, double the input and output price on every one of those turns.

The Enterprise row is honest in a way Team is not: every token is on the meter from the first turn, so you can see what each developer costs, and you pay for that visibility in full. Team hides the cost inside the allowance and then shows you the spillover. Neither answers the question a budget review actually asks, which is not “what did Priya spend on Opus” but “what did the payments migration cost, and did it ship”.

What does the Team plan not show an engineering manager?

Three things, and all three are about the grain of the record rather than the price.

Spend per unit of work. Every report Anthropic offers is per user and per model: the Team spend report, the Enterprise Analytics API, the Console dashboard, the OpenTelemetry export. All of it is per developer. None of it is per ticket. A manager budgets in tickets, releases, and projects, and the bill is in people and models. Translating between the two is a spreadsheet somebody maintains by hand, until they stop. On YAGNI the translation is the case file.

Retries. A session that starts from a wrong assumption costs a build, a review, a send-back, and a second build. The credits are the small part; the reviewer’s hour is the rest. No seat price changes that. What changes it is the context the agent reads before it plans: the product decision, the thread behind it, the correction a reviewer made last month. We wrote up where that context lives for a team in context engineering for coding agents.

The second meter. A Team seat is a person’s login. The best of the ranking pages says so plainly and then recommends two organizations: Team seats for the humans, and a Console workspace with an API key for anything that runs unattended, such as review in CI. That is the correct advice for the Team plan, and it means the moment your org adds a coding agent that is not a person, you have two bills, two spend limits, two reports, and no page that shows a developer’s session and an agent’s work side by side.

That third gap is the one YAGNI closes first.

How does YAGNI put developers and Agents on one meter?

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. Developers keep the CLI, their CLAUDE.md, their skills and MCP servers, and the Team plan if they want it. Two things change on YAGNI.

One rate card, no seats. On YAGNI there is no seat. A developer with zero usage costs zero. Developers running YAGNI Code, the developer’s own coding agent, and the named Agents on an Agent Team bill on the same rate card, on vetted US-hosted open-weight models at 60% or more under comparable frontier API rates. Claude Code joins the same meter through YAGNI’s wire adapter, with one command from the terminal:

yagni connect claude-code

After a restart, the same Claude Code session runs on YAGNI’s models and its spend lands on YAGNI’s meter next to everyone else’s. The command writes the CLI’s own settings file, so the workflow does not change, 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. The rate card itself is shared on a call; the only public claim is the 60% floor. Where a task is hard enough that a frontier model finishes it in fewer attempts, that is a real trade, and we say so in the call rather than pretend the floor is free.

One Usage page. YAGNI’s Usage page shows 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. The sidebar meter is its first line. A daily spend ceiling in YAGNI’s Workspace settings is the brake, for the whole workspace rather than per login. An admin can read it; a member sees their own. That is the per-developer half of the Team plan’s report, without turning credits on to get it, and on YAGNI it already carries the Agents the Team plan cannot bill.

What does a ticket cost when an Agent Team carries it?

The per-ticket half is the Team. A YAGNI Agent Team mirrors one of your engineering teams and reports to one accountable person. A ticket moves through six stages, each owned by one Agent, with a person at the three points that matter. Take a ticket in Jira: Bailey, the Product Manager, reads the backlog and proposes it with evidence from the tracker, and the proposal waits for a person to accept it. Reeve, the Staff Engineer, plans it, reading the ticket, the linked Slack thread, and the Team’s decision ledger before asking anyone anything, and a person approves the plan. Wright, the Builder, builds it to a draft pull request in a sandbox on GitHub. Proctor, the Reviewer, posts one review a person can read. Fletcher, the QA Agent, in beta, boots the environment and walks the change in a browser, with video attached. A person merges. Harper, the Chronicler, posts what shipped to Slack with the receipts.

Every one of those runs is metered on the same YAGNI rate card the developers are on, and the ticket’s case file shows what the workspace was charged for them. Put beside the Team plan’s report:

Question	Claude Code Team plan	YAGNI
What did each developer spend this month?	Credit spend per user and per model, once credits are on	Spend per developer on YAGNI’s Usage page, from the first token
What did the coding agents spend?	A separate Console workspace and report	The same page, per Agent, broken out by job
What did ticket PAY-212 cost, end to end?	Not available	One row on the YAGNI case file: proposal, plan, build, review, QA, merge
Was the plan send-back cheaper than the build it prevented?	Not available	Two rows on the same case file
Who approved what, and when?	Not recorded	Each click a person made, beside the run it gated

The managed version of this story is the pillar, Agent Teams for software development, and the manager’s day-to-day view of it is in AI tools for engineering managers. For a budgeting post the point is narrower: a Team plan seat is the right way to pay for a person who types into the CLI, and it is the wrong grain for anything else you will want to know by the second quarter.

How should an engineering org budget the Claude Code Team plan?

In order:

1. Count the heavy developers honestly. A Premium seat costs five Standard seats. If a developer hits the weekly limit twice a month on Standard, Premium is cheaper than the credits they would otherwise burn. If they never hit it, Standard is right.
2. Turn usage credits on with per-member limits from day one. The report only exists once credits are on, and a limit per member turns a surprise into a request. Export the CSV monthly and put the credit total on the budget line next to the seats.
3. Do not count the pooled API credits. The $500 a month funds the Claude Platform, not Claude Code.
4. Change the default model for routine work. Opus 5.5 at $4 and $20 per million tokens versus Sonnet 5.5 at $2 and $10 is the single largest lever on the credit bill, and the seat price does not make it go away.
5. Decide where the agents live before you add one. On the Team plan that is a second meter in the Console. On YAGNI it is the same meter as the developers, with the Agents’ spend per job beside the people’s.

The last step is where the arithmetic stops being about seats. Connect the same Claude Code to YAGNI and the sessions run at 60% or more under comparable frontier API rates, with spend per developer on one page. Add an Agent Team and the same page shows what each Agent spent, and each ticket’s case file shows what it cost to ship. If you want the model run on your org’s numbers, book 30 minutes and bring your seat count and your current plan. We will send the arithmetic back and the rate card with it. The offer itself is on the home page.