Quotas and limits

What is measured

A quota caps one of: input tokens, output tokens, spend, or request count. It applies to a person, a team, or a service token, optionally narrowed to one model or managed model. A team’s quota counts only requests made while working under that team (a team token or the Working under selector).

Prompt-cache writes count toward spend quotas at the cache-write rates, but not toward input-token quotas.

When several quotas apply at once they combine with AND — the most restrictive one decides.

Windows

Calendar windows (per day, per week, per month) reset on UTC boundaries. Rolling windows (24 hours, 7 days, 30 days) slide continuously, so the oldest usage drops out as time passes.

On breach

You are warned at 80% and again at 95% by default; an administrator can configure different warning percentages per quota rule. Warnings for a personal quota go to you; warnings for team and service-token quotas, and every breach, go to administrators. When the limit is reached, the next request is refused with HTTP 429 and a reset_at timestamp. For rolling windows reset_at is the latest time; capacity comes back gradually as older usage leaves the window.

By default a request already in flight is allowed to finish, and the overage is recorded — which is why administrators are advised to set limits with headroom. A quota can instead be set to hard-kill; while any hard-kill quota applies to a request, its stream is cut as soon as any of your limits is crossed.

{
  "error": {
    "message": "Your per day quota of 1000000 input tokens has been used up. Access resumes at 2026-08-16T00:00:00Z.",
    "code": "policy.quota_exceeded",
    "type": "rate_limit_error",
    "reset_at": "2026-08-16T00:00:00Z",
    "retry_after": 34200
  }
}