Rate limits
The 429 you can hit is a key's spending limit. Provider rate limits are retried for you and surface on the task, not as an HTTP error.
Mynth is built for production traffic, and a normal app should not need a backoff loop. There are two kinds of limit to plan for, and they show up in different places.
Limits on your requests#
A request refused before a task exists answers 429. The 429 you can hit
through your own settings is SPENDING_LIMIT_EXCEEDED, the
spending limit on a key. It clears
when the key's day, week, or month rolls over, not on a retry. A key without a
limit never returns it.
Capacity limits can also apply to protect the service. Do not build code that
assumes a key can send without limit. If you get a 429 with a code other
than SPENDING_LIMIT_EXCEEDED, slow down and retry with backoff. There is no
Retry-After header. The CLI exits with code 6 for such a 429.
Limits at the provider#
Providers rate-limit Mynth. A refused attempt is retried on another provider, within the attempt budget on tasks, and you do not see those retries.
When every attempt is refused, the item fails on a task that was already accepted:
| Code | Means | Do |
|---|---|---|
RATE_LIMITED | Providers kept rate-limiting the request | Send a new request shortly |
PROVIDERS_BUSY | No provider has capacity for this model right now | Retry later, or pick another model |
Neither is an HTTP 429 on the create call. The code sits on the failed
image or video inside a completed task, and failed items are not charged.
Errors lists every task code.
Next steps#
- Authentication: set a spending limit on a key.
- Tasks: attempts and time budgets.
- Errors: every HTTP status and task code.