Limits and billing

What actually decides access

Every API request is admitted (or refused) from live account state, evaluated per request. The authoritative chain, as the backend evaluates it:

1. The key is valid — it exists, its state is ACTIVE, and it has not expired. A recognized but revoked/expired key gets a 403; an unknown key gets a 401.
2. The account is usable — status ACTIVE, no reconciliation hold on the account, and no open reconciliation hold records.
3. The authority is synchronized — the account carries a synchronized access authority: either an active legacy grant or a fully synchronized subscription period whose paid-through cutoff still covers the request time. One valid source is enough; a separately valid grant is not invalidated by subscription state, and vice versa.

Discovery (GET /v1/models) is available to authorized keys and reflects the same access decision plus the effective model policy. Portal changes (an upgrade, a renewal) are read per request rather than from startup snapshots — but the portal recording a change and the underlying authority being synchronized are different moments. After a plan change, a request can still be refused until synchronization completes; if a refusal persists, check billing state and contact support with the metadata in Troubleshooting.

Where to see your own numbers

This page prints no prices, token allowances, or reset dates: those belong to your plan and change over time, so any number typed into a docs file would be an unreliable promise. The live surfaces are:

• Portal → Billing — your plan, subscription state, and invoices.
• Portal → Usage — your consumption and allowance state.
• GET /v1/models — the model policy currently in force for calls (limits and capabilities, with policy_revision).
• /pricing — the public plan comparison.

Subscription and allowance semantics

Access follows the synchronized authority, not the portal UI alone: while an active grant or a current paid-through subscription period is synchronized, authorized requests are admitted subject to policy; when authority lapses or enters reconciliation, admission refuses with 403 until the state is resolved. A portal change does not by itself guarantee the very next request succeeds — access resumes once the synchronized state covers the request. Refund, reset, and proration policy are governed by the portal and the terms on the pricing/billing surfaces, not by this page, so nothing here restates them.

Concurrency: what is and isn't promised

No fixed account-concurrency number is advertised, and none should be assumed. Concurrency is governed by your account plan and its current allowance. Rate/concurrency rejections (429, with retry-after / x-ratelimit-* headers when supplied) are a dependable signal that you are over pressure for the moment, but they are not the only source of information about your allowance — plan state and usage visibility in the portal matter too. Practical rules:

• Unknown headroom → start with one in-flight request and ramp based on observed responses.
• Any 429 → lower local pressure immediately; a client-side semaphore cannot reserve capacity against your other applications or teammates.
• Never hardcode a worker count as if it were an entitlement.

Keeping the account callable

• One key per integration; revoke what you don't use — a revoked key stops authorizing; it is not a billing event.
• Watch for 403s after plan changes: they mean account/entitlement/synchronization state, not code bugs (Troubleshooting).
• Support can see request metadata (timestamps, request ids, statuses) — never send them your key or prompt content.