Skip to main content

​
Rate Limits & Fair Usage

Your primary quota is your plan’s request allowance per usage window (for example, 30 requests per 5 hours on Promo, 800 per 5 hours on Pro). Every plan also has a weekly request cap that resets Monday 00:00 UTC. Openference additionally applies a per-minute burst limit — a hard cap on requests per minute per account (all of your API keys share one burst budget) — to keep the platform responsive for all users. Your window quota resets on a fixed schedule (your full allowance returns at each reset; the exact time is shown in the dashboard). The per-minute burst limit is enforced over a sliding 60-second window per account.

​
Your plan quota

Each plan includes a request allowance per usage window, which resets in full on a fixed schedule. See the per-plan limits table for every plan’s window allowance, weekly cap, and burst limit, or check the Pricing page and the dashboard under Billing, where your next reset time is shown. When you exceed your included requests in the current window, on-demand overage or credit balance can continue to cover usage (when configured on your account).

​
Weekly usage cap

In addition to the per-window allowance, every plan has a weekly request cap. This is a soft ceiling on total requests over a 7-day period — it prevents sustained round-the-clock usage from monopolizing shared capacity, while leaving comfortable headroom for normal heavy workloads.
  • Each plan’s weekly cap is listed in the per-plan limits table (for example, 13,000 requests per week on Pro).
  • The weekly cap resets every Monday 00:00 UTC. Your full weekly allowance returns at each reset.
  • The dashboard shows your weekly usage as a percentage of your plan’s weekly quota, plus a countdown to the next Monday reset, in the Included Request Usage card.
  • When you reach the weekly cap, on-demand overage or credit balance can continue to cover usage (when configured on your account) — the same behavior as the per-window allowance.
  • The per-minute burst limit (below) is separate and unaffected.
If you consistently reach the weekly cap, upgrade to a plan with a larger weekly allowance.

​
Burst protection

The burst limit is not your plan quota. It is a hard per-minute request cap that prevents any single account from overwhelming shared capacity. Requests beyond it return 429 immediately and it is not bypassed by credits — only your per-window allowance can be extended with on-demand credits.
  • Applies to any 60-second rolling window, per account (all of your API keys share one budget)
  • For typical interactive IDE use, you will not hit it
  • For unattended or high-frequency agents, paid plans offer higher per-minute caps (up to 25 requests per minute on Pro and above) and larger per-window allowances
  • If you are hitting burst limits regularly, upgrade your plan or add credits for on-demand overage

​
What counts

A request counts toward limits when the final status recorded is:
  • success
  • client_error (4xx from client or bad request)
Upstream errors and capacity unavailable (502, and 529 “Overloaded” when no providers are available) do not count. A counted request does not always cost one request’s worth of allowance: each model has a ratio (roughly 1x–2.5x) that decides how much of your window and weekly caps it consumes. See Model Request Ratios for the full table. The exact charge for each call comes back on the response — see Quota headers — and every call’s charge is listed in the dashboard under Usage (with a quota_cost column in the CSV export).

​
Behavior on exceed

Every limit response tells your client exactly when to retry — machine-readable, not just prose:
  • 429 responses carry a Retry-After header (seconds). For the per-minute burst limit it is the exact time until your sliding 60-second window frees capacity; for the hourly per-key limit it is the time until that window resets.
  • 429 bodies carry type: "rate_limit_error", a code, and a retry_after_seconds field. Codes: rate_limit_exceeded (per-minute burst), hourly_limit_exceeded (per-key hourly cap), token_limit_exceeded (per-key lifetime token cap — permanent, does not reset).
  • Quota exhaustion without credit balance returns 402 Payment Required with a code (window_quota_exceeded, weekly_request_limit_exceeded, or weekly_token_limit_exceeded) and a resets_at timestamp (ISO-8601) for when your allowance returns. Per-window and weekly quota may be bypassed with on-demand credits when configured; the per-minute burst limit is never bypassed by credits.
  • On /v1/messages (Anthropic-native), limit errors use the Anthropic error envelope: { "type": "error", "error": { "type": "rate_limit_error", ... } }.
  • Abuse/capacity throttle — "Temporary rate limit applied due to high load" Applies a temporary lower burst limit to this key only. Credits do not bypass. This is a rate reduction, not a block — retry shortly at the reduced rate using the short Retry-After header (or retry_after_seconds in the body), which is typically under a minute and is not the full throttle duration.
Example burst-limit 429:
When no providers are available for a model, the API returns 529 Overloaded (Anthropic-native) with a Retry-After header; this does not consume quota.

​
Rate limit headers

Every admitted proxied response includes burst-budget headers so SDKs and agents can back off before a 429 happens: 429 responses carry the same headers with X-RateLimit-Remaining: 0.

​
Quota headers

Burst headers cover the per-minute cap. These two cover the plan allowance, which is where per-model ratios apply: X-Quota-Cost is present on any request that got far enough to resolve a model; requests rejected earlier (malformed body, unknown model) are charged a flat 1. X-Quota-Remaining is read at admission, so with requests still in flight it can read slightly higher than the settled figure — the dashboard is the exact number.

​
Temporary abuse throttling

When automated signals detect a single API key sending disproportionately high volume, Openference may apply a temporary reduced burst limit to that key for a short period. This protects shared capacity for all users. Normal interactive IDE use within plan limits should not trigger it. The throttle is a rate reduction, not a lockout: the key keeps serving requests at the reduced rate (returned in the max_rpm field) throughout that window, so you can retry shortly at the lower rate instead of waiting out the full duration. The Retry-After header and retry_after_seconds body field give the short wait until your next retry under the reduced rate (typically under a minute) — they do not reflect the remaining throttle time, so do not infer a long wait from them. See Plans & Usage for how window allowances and overage work.