Seats, plans and quota planning for a team
Shared methods · A shared method; linked tool guides explain the exact steps.
This page covers tools outside your selection. You can still read it. Find matching guides
Usage is uneven enough that averages mislead. Size from a pilot, and expect a handful of people to account for most of the consumption.
Two decisions get made together and should be separated: how many people get access, and which tier they get. Conflating them produces the common outcome of unused licences alongside the same three people still hitting limits every Thursday.
Why averages mislead here
Consumption across a team is not normally distributed. It clusters.
A person using chat conversationally and a person running agentic sessions all afternoon differ by more than an order of magnitude, and the difference has little to do with seniority or how valuable their work is. It follows from which surface they use, and an agentic loop reads a great deal. See Quota discipline in an agentic loop.
Sizing from a mean therefore over-provisions most of the team and under-provisions the people driving the value. Size from the shape instead.
Sizing from a pilot
Run the pilot with the specific aim of learning the distribution, which is a different aim from learning whether people like it.
- Pick a group that spans the surfaces, so the sample includes at least one heavy agentic user. A pilot of chat users tells you nothing about your eventual bill.
- Give it a month. Weekly allowances reset on a fixed schedule per account, so shorter runs sample the cycle unevenly.
- Record consumption per person, then look at the spread rather than the average. What you want is the ratio between the heaviest and the median.
- Ask the heavy users what they were doing. Sometimes it is genuinely valuable work. Sometimes it is one unbounded loop nobody had reason to bound.
- Then size: the tier that suits the heavy tail, and a lower tier for everyone else.
Mixed tiers are usually correct
The instinct is one plan for everyone, because it is simpler to administer and feels fairer. It is also how organisations buy the top tier for people who would never notice the difference.
A defensible split for most teams: the higher tier for people doing agentic work daily, a standard paid tier for everyone else, and a review date to move people between them as their work changes. Say out loud that the tier tracks the work rather than the person, or the allocation becomes a status question.
Before adding seats, look at the workflow
A limit reached repeatedly is a signal with two possible causes, and buying is the right answer to only one of them.
Consumption is dominated by what gets re-sent each turn. A team that never starts a fresh session, attaches everything by habit, and runs the top model for bulk reading will exhaust any allowance you buy. The workflow guides put numbers on this — the same job split across models routinely costs half.
Check the habit first. It is cheaper, and if the habit was the cause, the extra seats would have bought you a later version of the same Thursday.
What goes wrong
Sizing from the average. Over-buys for most people and still leaves the heavy users constrained.
A pilot of only chat users. Predicts none of the agentic consumption.
One tier for everyone. Expensive in one direction or limiting in the other, and usually both at once.
Buying before checking the workflow. A larger allowance consumed the same way runs out later.
Per-person usage analysis without the participation step. Slower and more expensive to unwind than to sequence properly.
How to check it worked
A month after sizing, look at whether the same people are still hitting limits. If they are, either the tier is wrong for the tail or the constraint was never the allowance — and those two have completely different fixes.
Sources
- What is the Max plan? — Anthropic Help Center Tier 1 2026-08-31
- Get started with Claude Cowork — Anthropic Help Center Tier 1 2026-08-31
- Best practices for Claude Code Tier 1 2026-08-31
Something wrong with this page?
Say what you expected and what you got. That is usually the shortest route to a correction, and it goes on the public issue tracker so the fix is visible.