Rate Limits

OffRail applies rate limits to ensure fair usage and protect platform stability. Limits are evaluated in a few independent layers:

• Per-organization endpoint limits — a requests-per-minute cap on every API endpoint, scoped to your organization.
• Free model limits — additional limits specifically for zero-cost models.
• Provider limits — upstream limits enforced per provider/model when applicable.

Per-Organization Endpoint Limits

Every API endpoint is rate limited per organization using a rolling 60-second window. The limit is independent for each endpoint, so traffic to /v1/chat/completions does not consume the budget for /v1/embeddings.

The default limits (requests per minute, per organization) are:

Trust Tiers (account age or spend)

For regular (pay-as-you-go) organizations, limits scale with a trust tier. An organization qualifies for a tier when its account is old enough, or when its lifetime usage spend is high enough and the account meets the tier's minimum age. The tier raises the per-endpoint RPM limits and the daily/monthly USD spend caps below.

Spend alone never promotes a brand-new account: each spend-qualified tier also requires the minimum account age shown, so the fastest possible path to Tier 4 is 14 days — no amount of day-one usage unlocks higher limits.

For example, an org past 30 days old (or with $100+ of usage) is Tier 2: chat completions rises from 600 to 2,400 RPM, with a $500/day and $5,000/month spend ceiling.

Qualifying spend counts usage billed to your credit balance only — usage served through your own provider keys (BYOK) does not count — and is net of refunds: every refunded payment is deducted, so refunded or clawed-back money never raises limits. Refunded top-ups still count against the top-up allowance below — refunding does not free up top-up headroom.

Daily & Monthly Spend Caps

Regular organizations also have hard USD spend ceilings — a daily and a monthly cap set by the trust tier above — so a brand-new account has a tight dollar velocity limit that rises as it ages or spends. Only real paid usage counts; free models are exempt, as are enterprise (no caps) and dev/chat plan orgs (which have their own plan limits). When a cap is reached, requests return 429 until the counter resets (UTC midnight for daily, first of the month for monthly).

Top-Up Limits

Credit top-ups are also velocity-limited by trust tier: each organization can add at most a tier-scaled gross USD amount to its balance per rolling 24-hour window. This applies before any charge is made — a top-up attempt over the allowance is rejected with 429 and no card is charged.

The limit covers dashboard top-ups (card and hosted checkout), auto top-up, and Dev plan pay-as-you-go top-ups. Enterprise organizations are exempt — contact us if you need a higher allowance. Your current allowance and usage are shown on the Settings → Limits page. Hosted checkout links expire after 30 minutes.

Dev and Chat Plans

Organizations on a Chat plan have their own, tighter per-endpoint limits and do not receive the spend-based multiplier.

Dev plans are inference-only and only cover chat completions, messages, responses, the models list, and OCR, each at a flat 120 requests-per-minute floor. The other endpoints (embeddings, moderations, images, speech, videos) are not available on Dev plans and are marked — below.

Enterprise

Organizations on the Enterprise plan have no per-organization rate limits at all — no requests-per-minute caps, no spend caps, and no top-up limits. Your throughput is limited only by your credit balance and any upstream provider limits.

Free Models

Free models (models with zero input and output pricing) have additional rate limits that depend on your account's credit status:

Base Rate Limits

For organizations with zero credits:

• 5 requests per 10 minutes
• Applies to all free model requests
• Resets every 10 minutes

Elevated Rate Limits

For organizations that have purchased at least some credits:

• 20 requests per minute
• Applies to all free model requests
• Resets every minute

Provider Limits

Some providers and models enforce their own upstream request limits. When a provider limit is reached, OffRail returns a 429 and includes provider-scoped headers (X-RateLimit-Limit-Provider, X-RateLimit-Remaining-Provider). Where possible, fallback routing automatically retries the request on a healthy provider.

Rate Limit Headers

When a request is rate limited, the 429 response includes:

Retry-After: 12
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1640995200

• Retry-After: Seconds to wait before retrying
• X-RateLimit-Limit: Maximum number of requests allowed in the current window
• X-RateLimit-Remaining: Number of requests remaining in the current window
• X-RateLimit-Reset: Unix timestamp when the rate limit window resets

Rate Limit Exceeded

When you exceed a rate limit, you'll receive a 429 Too Many Requests response:

{
	"error": {
		"message": "Rate limit exceeded for /v1/chat/completions. Please retry after 12 seconds.",
		"type": "rate_limit_error",
		"code": "rate_limit_exceeded"
	}
}

This uses the standard OpenAI-compatible error envelope. Requests to the Anthropic-compatible /v1/messages endpoint receive the Anthropic error shape instead. See Error Handling for the full format and status-code reference.

Best Practices

• Respect Retry-After. Implement exponential backoff when you receive 429 responses, starting from the Retry-After value.
• Watch the headers. Monitor X-RateLimit-Remaining to back off before you hit the limit.
• Spread traffic across endpoints. Limits are per endpoint, so unrelated workloads don't compete for the same budget.
• Scale with usage. Regular organizations unlock higher limits automatically as lifetime spend grows; contact us about an Enterprise plan to remove per-organization limits entirely.