Skip to main content

​
Rate Limits & Fair Usage

Your primary quota is your plan’s request allowance per usage window (for example, 20 requests per 5 hours on Free, 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 API key — 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 API key.

​
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 API key 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
  • For typical interactive IDE use, you will not hit it
  • For unattended or high-frequency agents, Auto Agent plans offer higher per-minute caps (up to 99 requests per minute) 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.

​
Behavior on exceed

The API returns HTTP 429 Too Many Requests with one of:
  1. Plan quota or burst limit — Messages such as “Request limit exceeded (800 per 5 hours)”, “Weekly request limit exceeded”, or “Too many requests per minute”. Per-window and weekly quota overage may be bypassed with on-demand credits when configured; the per-minute burst limit is not bypassed by credits.
  2. 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.
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.

​
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.