To size rate limits for a coding assistant team, start from per-user tokens and requests per minute, then reduce the per-user figure as the team grows, because fewer people are active at the same moment. Cap the assistant's workspace share so it cannot starve production, and revisit the numbers after a pilot.
What the vendor suggests
Anthropic's cost page for its coding tool gives per-user recommendations for tokens per minute and requests per minute, based on organization size. The direction is the useful part. Per-user tokens per minute fall as team size rises: a team of one to five users sits at the high end of the table, and an organization of five hundred or more sits at the low end. The page explains why: fewer users tend to use the tool concurrently in larger organizations. It also says the limits apply at the organization level, not per person, so a single user can temporarily consume more than their calculated share when others are idle.
| Team size band | Direction of the per-user figure |
|---|---|
| Very small team | Highest per-user share |
| Tens of users | Mid-range |
| Hundreds of users | Lower per-user share |
| Five hundred or more | Lowest per-user share |
Check the current table on the page for exact values, since vendors revise them. The page also warns that unusual high concurrency, such as live training sessions with large groups, may need higher allocations.
The arithmetic
The page gives an example: with two hundred users, you might request twenty thousand tokens per minute per user, which is four million in total. The pattern is simple:
- Pick the per-user figure for your band.
- Multiply by the number of users to get the organization request.
- Compare with your current tier limits for the model class in use.
- If the total exceeds your limit, ask for an increase before rollout.
Protect production
Assistant traffic is bursty and developers work at similar hours. If it shares an organization limit with a customer-facing feature, a busy afternoon could slow customers. The page says that in the Console, the tool's traffic counts toward your organization's limits, and suggests setting a workspace rate limit on the tool's workspace to cap its share. Treat that as the default for any internal tool that shares limits with production. See how to set spend and workspace limits.
Worked example: a hundred developers
This example is illustrative. A company with one hundred developers plans a rollout. Production serves customers with a steady load and has its own workspace. The platform team plans as follows.
- Look up the band for one hundred users and compute the total tokens per minute.
- Compare it with the organization limit for the model class. The total is a large fraction of the limit.
- Request an increase two weeks before rollout, and describe the peak and the expected cache share.
- Put the assistant in its own workspace with a rate cap so production keeps a guaranteed share.
- Roll out in three waves of about thirty people, watching the usage page and error rates.
- After a month, compare actual peak with the plan and adjust.
What to monitor
| Signal | Why |
|---|---|
| Peak input and output tokens per minute | Shows how close you run to the limit |
| Rate limit errors by workspace | Shows who is being throttled |
| Cache rate | Higher cache reads ease input limits on most models |
| Spend per user per day | Finds outliers |
| Time of day | Shows whether peaks align across time zones |
Cache matters for limits
On most models, only uncached input counts toward input limits, so teams with repeated project context benefit. See cache-aware input token limits. Habits that shrink context also lower the load, as described in why a long agent session uses so much.
Fairness inside the team
A shared pool means one heavy user can slow everyone. If that happens, look at the heaviest sessions before you add capacity. Often a loop, a very large file read or a long running scheduled job is the cause. A short conversation with the owner can save an increase request.
Governance
Rate limits are a throughput control, not an access control. Decide who may use the tool, what repositories it may touch and what it may execute, using permission rules and managed settings. For agents that hold identities and tool access, Safeguard offers agent identity and policy features that sit alongside provider-side limits.
When to revisit the numbers
Revisit after four events: a big hiring wave, a change of model, a new feature in the assistant that adds background activity, and any month in which rate limit errors appear. Keep the sizing worksheet in version control with the date, the table you used and your reasoning. When someone asks why the limit is where it is, you can answer from the record instead of memory.
Also schedule a quarterly check of the vendor's page. The recommendations are guidance, and vendors revise them.
What this means for you
If you are the person asked to roll out a coding assistant, the main thing to know is that limits are shared. A team limit is a pool, not a personal allowance, and a pool behaves differently from a quota. Most of the time nobody notices it, because people work at different moments. A few times a month, many people work at once, and that is when the pool matters.
So size for the busy hour, not the average day. Ask when your developers actually work, whether they are in one time zone or several, and whether any events, such as a hackathon or a training day, will line up everyone's activity. Then compare that peak with the limits for the models you plan to use.
Common mistakes
The most common mistake is to size from the average and be surprised at the peak. The second is to let the assistant share a limit with a customer-facing feature, so a busy afternoon of coding slows customers down. The third is to skip the increase request until after rollout, when the answer takes days and people are already frustrated. The fourth is to forget that cached input helps limits on many models, so a team with a stable project context needs less headroom than one that sends fresh material every turn. The fifth is to assume one number works forever, when team size, models and habits all change.
A step by step sizing routine
- Count the developers who will use the tool in the first three months, not just the pilot group.
- Look up the vendor's per-user guidance for that team size and compute the total.
- Check the total against your current limits for the model classes in use.
- If it does not fit, write the increase request with your peak, your expected cache share and your rollout dates.
- Create a separate workspace for the assistant and cap its share.
- Roll out in waves and watch the usage page and the error rates after each wave.
- After a month, compare reality with the plan and write down the adjustment.
Following these steps turns a vague worry about limits into a short list of tasks with owners and dates.
Try it yourself
Click through it at your own pace, or open it full screen. It shows a command line tool running locally against a project. Think about how many developers could run something like it at once, and what that does to a shared limit.
Quick check
Why does the per-user figure fall as teams grow?
The vendor page says fewer users tend to use the tool at the same time in larger organizations, so the shared limit can be spread thinner.
Are these limits per person?
No. The page says they apply at the organization level, so one person can temporarily use more than their calculated share.
How do I stop the assistant from affecting production?
Put it in its own workspace and set a rate limit on that workspace to cap its share.
Sources
Last reviewed: 19 October 2026.
