Rate limits and quota

Osyra applies two different controls that clients should not conflate:

1. Request-rate limits bound traffic over a short rolling window. Edge selects a bucket from the authenticated principal, route class, and deployed configuration.
2. Subscription quota counts successful, billable model requests against the current subscription period.

There is no public per-key concurrency allowance today. The Billing catalog has no concurrency limit dimension, so clients must control their own worker-pool size instead of relying on an advertised concurrency ceiling.

Subscription periods

Quota periods are subscription-relative, not calendar months. Use the reset timestamp returned by the service; do not calculate it from the first day of a month.

Only successful, uncached responses on the billable inference routes settle a reserved quota unit. Public endpoints, GraphQL control-plane operations, model-list reads, failed model calls, and cache hits are not described as billable by this contract.

Enterprise quota is soft by default. For other plans, a deliberate exhausted-quota decision returns 429 and OSY-RATE-2010. A quota dependency failure is a different condition: production may allow the request without quota headers rather than misrepresent an unknown counter state.

Request-rate headers

When the general Edge rate limiter evaluates a request, it emits both the compatibility and standards-track header families:

X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 999
X-RateLimit-Reset: 42
RateLimit-Limit: 1000
RateLimit-Remaining: 999
RateLimit-Reset: 42
RateLimit: limit=1000, remaining=999, reset=42

For the general limiter, reset values are seconds until the rolling window resets. A denied request also carries Retry-After; wait at least that many seconds and add jitter before retrying.

The actual ceiling is deployment- and route-specific. Osyra does not publish the general Edge buckets as paid-plan entitlements, and the console does not currently expose a customer control for changing them.

Subscription-quota headers

When the subscription-quota middleware has an authoritative counter result for a billable request, it emits:

X-Quota-Limit: 100000
X-Quota-Used: 48231
X-Quota-Remaining: 51769
X-Quota-Percentage: 48.2
X-Quota-Reset: 1784371200

X-Quota-Reset is the Unix timestamp at which the subscription period ends. The other values describe the same post-settlement counter snapshot. These headers are not promised on every response: they are absent on non-billable routes and when the quota service cannot produce an authoritative result.

Sandbox API-key allowance

Sandbox API keys have a separate, identity-bound rolling allowance: 100 requests over 24 hours. Rotation, revocation, or re-minting does not reset that allowance because Edge keys it to the verified organization, workspace, and user tuple—not the key ID.

That middleware emits X-RateLimit-* and RateLimit-* headers. Its legacy X-RateLimit-Reset value is an absolute Unix timestamp; the standards-track RateLimit-Reset value is a delta in seconds. On exhaustion it returns 429, OSY-RATE-2001, and Retry-After. If distributed accounting is unavailable, Sandbox requests fail closed rather than bypassing the allowance.

Budgets and overage

Cost & budgets exposes real budget records and their current utilization when the Billing bridge is wired. A budget can declare soft or hard mode, but public documentation must not treat every configured budget as a guaranteed request-time stop unless the target environment reports the complete Billing → Broker → Edge enforcement path as active.

Automatic overage prices, warning emails, and forecast calculations are not part of this page's shipped contract. Contracted Enterprise terms and any overage behavior are governed by the signed order form, not a hard-coded documentation table.

Client behavior

1. Read the header family that matches the decision (RateLimit-* for short-window rate, X-Quota-* for subscription quota).
2. On 429, preserve the OSY-* code and X-Request-ID, then honor Retry-After with jitter.
3. Do not retry a policy or validation denial as though it were rate limiting.
4. Bound client concurrency locally; no Osyra plan currently promises a server-enforced concurrency allowance.

What's next

• Errors — OSY-RATE-* recovery decisions
• Governance & policy — real budget and policy surfaces
• Pricing — live enforced plan allowances