title: Limits description: Rate limits, size caps and timeouts, with the exact numbers LIBRA enforces.
Limits
Every number here is enforced in code. If you hit one, the error tells you which.
Request size
| Limit | Value | Error when exceeded |
|---|---|---|
| Request body | 4 MB | 413 request_too_large |
The cap covers the whole JSON body, so a long conversation history counts toward it, not just the newest message. If you are approaching it, trim older turns or summarise them rather than sending the full transcript each time.
Timeouts
| Limit | Value | Error when exceeded |
|---|---|---|
| Provider response | 180 seconds | 504 upstream_timeout |
This is how long LIBRA waits for the provider before giving up. Streaming responses are not affected once the first token arrives; the clock applies to starting the response.
Sign-in and account limits
These protect accounts from guessing attacks. They apply to the console, not to
/v1.
| Action | Limit | What happens |
|---|---|---|
| Failed sign-ins | 10 per 15 minutes, per email and per IP | "Too many failed attempts. Try again in 15 minutes." |
| Sign-ups | 5 per hour, per IP | "Too many signups from this address. Try again later." (HTTP 429) |
| Invitation accepts | 10 per hour, per IP | HTTP 429 |
| First-run platform setup | 5 per hour, per IP | HTTP 429 |
Unknown emails take the same time to reject as wrong passwords, so the response time does not reveal whether an account exists.
API request rate
There is no fixed requests-per-minute cap on /v1 today. What bounds your usage
instead is money: every request is checked against three budgets before it runs.
| Check | Error | Meaning |
|---|---|---|
| Organization balance | 402 insufficient_credits |
Prepaid balance is at zero |
| Workspace limit | 402 workspace_budget_reached |
Workspace spent its allowance for the period |
| Key limit | 402 key_budget_reached |
This key spent its allowance for the period |
Budgets are checked before the request is sent, not after. A key whose remaining budget is smaller than the cost of a single request is refused outright rather than part way through, so a limit of 1 IDR blocks everything.
Periods reset at 00:00 Jakarta time (WIB, UTC+7) on the day, week or month boundary you chose, not at UTC midnight.
If a request is ever rate limited you will get 429 rate_limited; back off and
retry, honouring Retry-After when present.
Guardrail limits
A key's guardrails can impose their own caps, set by your organization rather than by LIBRA:
| Guardrail | Effect |
|---|---|
| Allowed models | A model outside the list gives 403 model_not_allowed |
| Blocked providers | If every provider for a model is blocked, 403 provider_blocked |
| Max tokens per request | A larger max_tokens is silently clamped down, not rejected |
The clamp is worth knowing: ask for 4000 tokens against a 512 guardrail and you
get exactly 512 back with finish_reason: length. The request succeeds.
Data retention
| Data | Kept |
|---|---|
| Usage records | Indefinitely, so historic spend stays auditable |
| Request bodies | 7 days, and only when a key's guardrails enable logging |
Request bodies are purged nightly at 03:00 WIB. Deleting a key does not delete its usage history: the record stays so past spend remains attributable.
See Errors for the full list of error types and what to do about each one.