Limits and budgets

A key can carry a monthly spend cap, set on the keys page. It blocks once spend has reached the cap, so the cap can be exceeded by at most one request. Reported to you the morning after an agent loop ran all night is not a budget; this is enforced before the request reaches a provider.

Give each environment its own key and its own cap. A staging key that cannot spend more than a few dollars is the cheapest insurance there is.

Every key is limited per minute, on both requests and tokens. The free plan allows 60 requests and 60,000 tokens a minute; Pro allows 600 and 1,000,000. Both are set per key on the keys page, where a key's own number can lower the plan's but never raise it.

Two limits rather than one because requests are a poor proxy for load: a single 200,000-token call costs more upstream than a thousand short ones.

The window slides rather than resetting on the minute. A fixed window would let a caller send a full allowance at 59.9s and another at 60.1s, which is twice the limit in a fifth of a second and exactly the burst the limit exists to stop.

Going over answers 429 rate_limit_exceeded with a retry-after giving the seconds until the window has room. The token limit is measured against tokens already used, because the count does not exist until the provider answers, so it can be crossed by one request's worth.

Each key allows a number of requests in flight at once: 3 on the free plan and 10 on paid ones. Provider quotas are shared across every customer, so without this one caller's burst becomes everybody's outage.

Going over answers 429 rate_limit_exceeded with a retry-after. A long stream occupies a slot for its whole life, which is the case worth remembering when sizing this.

The free plan includes 10,000 requests a calendar month. Enough to build something real and watch it work, not enough to run a product on. Paid plans have no request cap.

Running out answers 402 plan_limit_exceeded, and the message names the plan and what to do about it. It resets at the start of the next calendar month, deliberately: an allowance on a rolling window is one nobody can predict.

Each plan allows a number of API keys, seats, webhook endpoints, scheduled reports, saved views, stored prompts and spend alerts. The free plan allows 3 keys, 1 seat, 5 stored prompts and 1 spend alert; Pro lifts or removes each of them.

Asking for one more than the plan allows answers 402 plan_limit_exceeded, and the message names which limit it was. GET /api/orgs/:orgId/gateway/plan returns every allowance alongside how much of it you have used, so nothing has to be discovered by hitting the wall.

Two details worth knowing. A revoked key does not count: it is kept so old requests keep their attribution, and counting it would be a limit nobody could get back under. A seat is a member or an unaccepted invite, because counting only members would let a one-seat workspace send fifty invites and have every one of them land.

Prompt versions are unlimited on every plan. Only the number of distinct prompts is capped: the registry exists to make changing a prompt cheap, and charging for edits would push people back to editing in place.

The request log and every analytics page go back 7 days on the free plan, 90 on Pro and 365 on Enterprise. Ask for a longer window and you get your plan's, not an error: you wanted your data, not a refusal.

Each response says which window it actually used, so a page can tell you it showed seven days when you asked for thirty rather than quietly showing less and looking broken.

Spend alerts tell you when a threshold is crossed, by email and to any webhook subscribed to spend.alert. An alert is not a limit and stops nothing; budgets are what stop traffic. An alert that only reaches an inbox is one nobody can act on automatically, which is why it also goes out as an event.