# Daily limits you can read

October 1, 2026 · API

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.limit`** is on every refusal by a daily ceiling: `name` (what it counts), `scope` (`person`, `application`, `account` or `platform`), `max` and `resetsAt`. 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 unavailable` with `Retry-After`, not `429 build_limit`. Nothing was built, and the person has not reached a limit. Retry with the same key.
- **The MCP `order` tool** returns `refusal` when it refuses to start a build: `code` (the REST code), `retryable`, and the same `limit`.

## 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](https://developer.layout.link/reference/limits#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.