Rate limits
Provider rate limits are retried for you and surface on the task, not as an HTTP error. A key's spending limit is a 402, not a 429.
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.
Capacity limits can apply to protect the service. Do not build code that
assumes a key can send without limit. If you get a 429, slow down and retry
with backoff. There is no Retry-After header. The CLI exits with code 6
for a 429.
A key's spending limit is not a rate
limit. It answers 402 spending_limit_exceeded, and a retry does not clear
it. The key's day, week, or month has to roll over, or you raise the cap.
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.