Agent door
Rate limits
Four independent limits protect the door from runaway traffic. They are operational abuse controls — not a billing meter and not an included-calls allowance.
The door enforces a four-dimension rate-limit matrix. A call must pass every applicable dimension. The limits below are the current defaults; they are operational settings and may be tuned per deployment.
These are abuse limits, not billing. Passing or hitting a rate limit says nothing about price or an included-call quota — it is purely a guard against runaway or hostile traffic. There is no per-call charge on the door today.
The four dimensions
| Dimension | Default limit | Where it applies |
|---|---|---|
| Per-session burst / sustained | 60 burst, 30 / minute sustained | Every transport request. A token bucket per session. |
| Per-grant daily | 10,000 / day | All tool calls under one grant, per UTC day. |
| Per-organization daily | 20,000 / day (tier-derived) | All tool calls in one workspace, per UTC day. Scaled by plan (see below). |
| Per-tool daily | 200 / day for write tools | Calls to a single tool under one grant, per UTC day. |
How the per-organization cap scales
The per-org daily cap is derived from the workspace plan. Relative to the base cap (20,000/day): Enterprise gets the base, Agency gets 2×, Partner gets 3×. Any other or unreadable plan tier is limited to one-tenth of the base — the cap fails closed rather than open.
What happens at the limit
- Transport (per-session) limits return HTTP
429with aRetry-Afterheader. - Tool-level limits (per-grant, per-org, per-tool) return an MCP
rate_limitederror with aretry_after_secondshint. - A rejected call consumes no quota on any dimension, and a rejection only ever reveals the caller's own budget.
Relationship to authority
Rate limits are checked after the capability gate, so a call the grant is not allowed to make is denied before it can spend any quota. Every counter is keyed to the authenticated session, grant, and organization — never to anything in the request body.