Limits and keys
Spend limits, rate limits and prompt capture.
A key is the unit of control. Everything you can cap, you cap per key, so one runaway service cannot drain the wallet the rest depend on.
Key options
| Field | Type | Description |
|---|---|---|
namerequired | string | Shown in the dashboard and on every request log line. |
spend_limit_nano | integer | A ceiling in nano-USD. Requests that would cross it are refused with 402 before they reach a provider. |
spend_period | daily | weekly | monthly | When the counter resets. Omit for a lifetime cap. |
include_byok_in_limit | boolean | Whether traffic on your own provider keys counts toward the limit. |
allowed_models | string[] | An allow-list of model ids. Empty means every active model. |
log_bodies | boolean | Opt in to storing prompts and responses for this key. Off by default. |
Rate and concurrency
Each key has a requests-per-second budget with a burst allowance, and a cap on requests in flight at once. Exceeding either returns 429 with a Retry-After header. Back off and retry; do not spin.
Prompt and response capture
- Off unless you turn it on, per key.
- Stored for seven days, then dropped with the partition.
- Long strings such as base64 images are elided by length, so an image payload is recorded as a stub rather than a megabyte.
- Captured bodies are readable by you and by nobody else. Operators have no path to them.
Wallet-level guards too
Beyond per-key limits, a request against an empty wallet is always refused, and settlement can never take the balance below zero without leaving a ledger entry that explains it. See credits.