Claude Team vs Enterprise Plan — and When Bedrock Beats Seats for Agentic Work

A field note on the one billing difference that decides everything once agents start consuming tokens on their own.

The headline question: Team vs Enterprise, and why the answer depends on usage

Every Claude Team vs Enterprise plan comparison I've seen treats it as a size question — Team for the small team, Enterprise for the big one. That framing is wrong, and it gets expensive fast. The real difference is structural: Team includes usage in the seat price; Enterprise bills usage at API rates on top of the seat. [1][2] That single line is the whole story.

For a handful of people typing prompts into a chat box, the difference barely matters — both plans feel like "a seat with some allowance attached." But the moment you put agents into the picture, usage stops being a rounding error. An agent doesn't send one message and wait; it loops, re-sends an accumulating context, calls tools, and spends tokens on its own schedule. The plan that includes usage and the plan that meters it behave completely differently under that load.

So before you ask "is Claude Enterprise worth it" or "how much does Claude Enterprise cost," ask a sharper question: how much of my spend will come from people, and how much from agents acting on their behalf? That ratio — not headcount — is what should drive the decision. This piece compares the two plans honestly, shows where seat plans stop scaling for agentic work, and explains when routing usage through Amazon Bedrock with governance beats simply buying more seats.

Claude Team: included usage, seat range, and what premium seats add

Claude Team comes in two flavors, and both bundle usage into the seat.

Team Standard is $20 per seat per month on an annual commitment ($25 month-to-month), for 5 to 150 members, with usage included — standard seats get roughly 1.25x the usage allowance of a Pro seat, and overflow is handled as credits. [2] Team Premium is $100 per seat per month annual ($125 monthly) and lifts that allowance to about 6.25x Pro. [2]

The mental model that matters: on Team, a seat is a bundle. You pay a fixed amount and you get both access and a quantity of usage inside it. Heavy individual users bump into the allowance, and you either move them to Premium seats or let credits absorb the overflow. Budgeting is predictable because the dominant cost line — the seat — is fixed and known in advance.

Source: [2]

This is a good fit when usage is human-paced and roughly uniform. It starts to strain when one person — or one automation tied to a seat — consumes far more than the bundle assumes.

Claude Enterprise: governance features and the 'seat + usage at API rates' model

Claude Enterprise is custom-priced and built around a different billing shape: a seat price plus usage billed separately at API rates — usage is not included. [1] There is no published seat price and no published seat minimum; treat Enterprise as "custom: seat + usage at API rates," and be skeptical of any blog that quotes you a hard dollar-per-seat or a fixed seat floor — those numbers are not published. [1]

What you get for the seat is governance, not usage: SSO/SCIM-style identity integration, role-based controls, longer context options, audit and compliance tooling, and the administrative surface a regulated org needs. Those are real and often decisive. But they are bundled with the seat; the usage your people and agents generate is a second, separate, metered line item.

So the honest answer to "how much does Claude Enterprise cost" is: the seat is whatever you negotiate, and then you add metered token consumption at standard API rates on top — and that second number is the one that grows without warning once agents are involved.

The trap: Enterprise seats look cheap until metered usage stacks on top

Here's the comparison that catches procurement teams off guard. Put the two plans side by side at the seat line and the Enterprise seat can look comparable to — even cheaper than — a Premium Team seat. But the seat line is not the bill.

On Team, the seat is (mostly) the bill, because usage is inside it. On Enterprise, the seat is the floor, and metered usage is poured on top at API rates. [1][2] For a light user the two converge. For a heavy user, or a seat that fronts an automation, Enterprise's metered usage can dwarf the seat cost — and unlike Team's included allowance, there is no bundled ceiling absorbing it.

The model list prices set the scale of that metered line. They are identical whether you call Claude through the direct Anthropic API or the Claude Platform on AWS — per-token rates are at parity across channels. [3]

Sources: [4][3]

Output is priced 5x input across the current line. [4] On a chat workload that ratio is manageable because humans read more than they generate. On an agentic workload it bites, because agents generate — plans, tool calls, intermediate reasoning, revisions — and they do it in loops.

Where agents break the seat model: usage you can't cap with seats alone

A seat is a license for a person. An agent is not a person. That mismatch is where the seat model quietly fails.

Three properties of agentic work make per-seat usage unpredictable in ways human chat never was:

• Loops compound. An agent re-sends an accumulating context on every turn, so token spend grows non-linearly with the number of turns. A task that takes a human three messages can take an agent thirty internal steps, each carrying the full prior context forward.
• Fan-out multiplies. Multi-agent orchestration patterns spawn sub-agents that each consume their own context. One human request can become a dozen concurrent agent threads.
• Tokenizer drift raises the floor. Opus 4.7 and later use a new tokenizer that can consume up to ~35% more tokens for the same text. [4] The per-token rate is unchanged, but the effective cost-per-task rises — and you won't see it in a price sheet, only in the bill.

Now layer that onto the two plans. On Team, agentic overflow lands against the included allowance and then becomes credits — bounded by the bundle. On Enterprise, the same overflow is metered at API rates with no included buffer, so the line that grows fastest is the line with the least built-in containment. You cannot fix this by buying more seats, because the cost isn't proportional to seats — it's proportional to agent activity, which a seat count doesn't model. Buying a seat for an agent is paying a per-person license for something that consumes like a small data center.

This is the inflection point. When agents become a material share of consumption, the question stops being "Team or Enterprise seats" and becomes "how do I govern and discount the usage itself."

The third option: routing Team/Enterprise usage through Bedrock for governance and discounts

There's a path that neither plan's seat line advertises: keep your seats for the people who need the product surface, and route the agentic usage through Amazon Bedrock, where it can be governed and discounted at the usage layer.

First, set expectations honestly. Per-token Claude rates are identical on the direct API and the Claude Platform on AWS — parity is the rule, so there is no magic "switch to Bedrock and pay less per token." [3] The savings don't come from the channel. They come from two things the channel makes available: usage-side optimization levers and negotiated discounts applied before billing.

The two levers that move agentic bills the most:

• Batch processing at 50% off both input and output for non-latency-sensitive work — overnight evals, bulk extraction, document processing. On Bedrock, batch is also 50% of on-demand for supported models. [4] (Note: batch is for the work you can queue, not for interactive sessions.)
• Prompt cache reads at 0.1x base input — roughly 90% off the cached portion. [4] Agent loops re-send the same system prompt and context every turn; caching that stable prefix turns the most repetitive, most expensive part of an agentic workload into the cheapest.

Sources: [4][3]

On top of the levers, volume and enterprise discounts are negotiated case-by-case — there are no published discount tiers, on either the Anthropic side or via AWS private offers. [5][6] Bedrock private-offer discounts are applied before usage is rated, but they are not retroactive — they can't reach usage incurred before the offer is accepted, so the timing of the agreement matters. [6] Plan the negotiation before the agentic ramp, not after the first surprising invoice.

Governance on Bedrock that seats alone don't give you

Discounts are the headline, but governance is the part that survives an audit. Seats give you identity and access control over the product. Routing usage through Bedrock gives you control over the consumption — and for agentic work, consumption is the thing that needs governing.

What the usage layer gives you that a seat count can't:

• Per-workload cost attribution. Agent fleets can be tagged and metered by application, team, or environment through your AWS account — so you can see which agent is burning budget, not just that the org bill went up.
• Capacity controls. Bedrock offers Provisioned Throughput and a Reserved Tier for Claude (the January 2026 Reserved Tier covers Claude Opus 4.5 and Haiku 4.5 at a fixed price per 1,000 tokens-per-minute, billed monthly on 1- or 3-month terms). [7] Dollar figures aren't published — those are priced via your AWS account team — but the capability lets you cap and reserve throughput instead of riding pure on-demand for a workload that loops unpredictably.
• Marketplace billing. Claude Platform on AWS bills through AWS Marketplace in Claude Consumption Units at $0.01/CCU, with usage rated in USD at standard API rates and negotiated discounts applied before the CCU conversion. [3] That puts Claude spend inside the same procurement and cost-management surface as the rest of your AWS estate.

This is the model I reach for when agents dominate: seats for the humans who use the chat product, governed usage for the agents that don't. It maps cleanly onto an AI governance program because the controls live where the spend lives.

A decision framework: stay on seats, or add Bedrock routing?

Here's the heuristic I use. Don't start from headcount — start from where your tokens come from.

The tell that you've crossed the line: when a meaningful fraction of your token spend is generated by software acting autonomously rather than by people typing, seats stop being the right unit of account. At that point, adding seats doesn't bound the cost — governing the usage does. The two approaches aren't mutually exclusive; the strongest setups keep seats for the product experience and route the agentic load through a layer you can cap, cache, batch, and discount. This is the practical core of running agentic AI at enterprise scale.

Compliance and regulated buyers: data isolation and audit

For regulated and public-sector buyers, the channel decision is also a compliance decision, and the details are specific.

Claude on Amazon Bedrock is approved for FedRAMP High and DoD IL4/IL5 in AWS GovCloud (US) — but only for specific models (Claude 3.5 Sonnet v1 and Claude 3 Haiku), for unclassified and CUI workloads. [8] This is the part to get exactly right in a procurement document: it is not "all Claude models are FedRAMP High." If your agentic workload depends on a current-generation model that isn't on the approved list, that model isn't covered by those authorizations today, and you need to design around it.

Beyond the authorizations, routing usage through your AWS account gives regulated teams what they actually need at audit time: data isolation within their own account boundary, per-workload logging and attribution, and consumption that flows through the same audit and cost surfaces as the rest of their cloud estate. Seats give you user-level access control; the usage layer is where data-handling and audit evidence live. For regulated agentic work, you generally want both — governed seats and governed, isolated usage.

The bottom line and where to get help

The Claude Team vs Enterprise plan choice is not small-versus-big. It's included-usage-versus-metered-usage, and that distinction only gets louder as agents take over more of the work. Team bundles usage into a predictable seat; Enterprise charges a seat for governance and meters usage on top at API rates. [1][2] For human-paced work, pick the plan that matches your access and governance needs and don't overthink it.

For agentic work, change the question entirely. Once software is generating a material share of your tokens — looping, fanning out, paying the tokenizer-drift tax — seats stop modeling your cost. The move that scales is to keep seats for people and route agent usage through a layer you can govern and discount: batch at 50%, cache reads at 0.1x, capacity reserved, spend attributed per workload, and discounts negotiated before the ramp rather than after the invoice. [4][3][6] The seat line is where you start; the usage line is where agentic budgets are won or lost. ASCENDING, an AWS Premier Consulting Partner and Anthropic partner, works in exactly this seam — governing Claude spend on Amazon Bedrock for teams whose agentic usage has outgrown what seats can model.

Disclosure: Explore Agentic is published by ASCENDING, which builds Jarvis AI on Claude and Amazon Bedrock; we have a commercial interest in the partner-led path described here. The pricing facts above come from Anthropic's and AWS's published documentation regardless.

FAQ

What's the real difference between Claude Team and Claude Enterprise?

The core difference is how usage is billed, not company size. Team includes token usage in the seat price (standard seats get about 1.25x Pro usage, premium about 6.25x), while Enterprise charges a custom seat price plus usage billed separately at API rates, with usage not included. Enterprise adds governance features like SSO, audit, and role-based controls, but the structural distinction that affects your bill is included-versus-metered usage.

Does Claude Team include token usage, or is it billed separately?

Claude Team includes usage in the seat. Standard seats ($20/seat/month annual, $25 monthly) come with roughly 1.25x the usage of a Pro seat, and Premium seats ($100/$125) come with about 6.25x. When a user exceeds the included allowance, the overflow is handled as credits rather than as a separate metered API charge.

How much does Claude Enterprise actually cost per user?

Enterprise is custom-priced, and there is no published per-seat dollar figure. The model is a negotiated seat price plus usage billed at standard API rates on top, so the total per user depends heavily on how much that user — or any automation tied to their seat — actually consumes. Be cautious of any source quoting a fixed Enterprise seat price; that number is not published.

Is there a seat minimum for Claude Enterprise?

No seat minimum is published for Claude Enterprise. The plan is custom and negotiated, so any specific seat-floor figure you see quoted elsewhere is not an official published minimum. Treat both the seat price and any minimum as items to confirm directly in your own negotiation.

When does routing through Bedrock beat buying more Claude seats?

Routing usage through Bedrock wins when agents, rather than people, generate a material share of your token consumption. Seats license people, but agentic workloads loop and fan out in ways a seat count can't model, so adding seats doesn't bound the cost. Per-token rates are the same across channels, but Bedrock lets you apply usage-side levers (batch at 50% off, cache reads at 0.1x), reserve capacity, attribute spend per workload, and apply negotiated discounts before billing.

Is Claude on Bedrock compliant for regulated or public-sector teams?

Claude on Amazon Bedrock is approved for FedRAMP High and DoD IL4/IL5 in AWS GovCloud (US), but only for specific models — Claude 3.5 Sonnet v1 and Claude 3 Haiku — for unclassified and CUI workloads. It is not accurate to say all Claude models carry those authorizations. Regulated teams should confirm that the specific model their workload depends on is covered before designing around these authorizations.

References

1. Claude pricing — Enterprise plan: custom seat + usage at API rates, no published seat price or minimum: https://claude.com/pricing
2. Claude Support — What is the Team plan: standard $20/$25 (1.25x Pro), premium $100/$125 (6.25x Pro), usage included, 5–150 members: https://support.claude.com/en/articles/9266767-what-is-the-team-plan
3. Claude pricing docs — per-token parity across API and Claude Platform on AWS; AWS Marketplace CCU billing at $0.01/CCU; discounts applied before CCU conversion: https://platform.claude.com/docs/en/about-claude/pricing
4. Claude pricing docs — model list prices, batch 50% off, cache read 0.1x base input, tokenizer change on Opus 4.7+: https://platform.claude.com/docs/en/about-claude/pricing
5. Anthropic — volume/enterprise discounts negotiated case-by-case, no published tiers: https://claude.com/pricing
6. Amazon Bedrock — private-offer discounts negotiated per deal, not retroactive: https://platform.claude.com/docs/en/about-claude/pricing
7. Amazon Bedrock Reserved Tier for Claude (Opus 4.5 & Haiku 4.5), fixed price per 1,000 tokens-per-minute, 1- or 3-month terms; dollar figures via AWS account team: https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-bedrock-reserved-tier-claude-opus-haiku/
8. Anthropic — Claude on Amazon Bedrock approved for FedRAMP High and DoD IL4/IL5 in GovCloud for specific models (3.5 Sonnet v1, 3 Haiku): https://www.anthropic.com/news/claude-in-amazon-bedrock-fedramp-high