Daily limits you can read
A 429 from a per-minute brake and a 429 from a spent daily ceiling call for different handling. Your code can now tell them apart without reading the message.
What changed
error.limitis on every refusal by a daily ceiling:name(what it counts),scope(person,application,accountorplatform),maxandresetsAt. A per-minute brake has none.- Every daily refusal names its number. Provisioning, build sessions and verification texts used to say only that a limit was reached.
- A build budget Layout cannot read is now
503 unavailablewithRetry-After, not429 build_limit. Nothing was built, and the person has not reached a limit. Retry with the same key. - The MCP
ordertool returnsrefusalwhen it refuses to start a build:code(the REST code),retryable, and the samelimit.
Why it matters
A client that is not a model, such as a texting service or an app, can stop retrying until resetsAt and tell the person why.
What to do
When error.limit is present, do not retry before resetsAt. See Handling a 429.
Breaking changes
None for a spent limit: its status code and error code are unchanged, and the fields are additive. A build budget Layout could not read used to answer 429 build_limit; it now answers 503 unavailable, which a client that retries a 5xx already handles.