Clearer sandbox build limits
A sandbox build has to clear several daily limits, and until now a refusal did not say which one it hit. The account-wide sandbox limit was also low enough to cap every one of your apps together, and it shared a counter with production. All three are fixed.
What changed
- 250 sandbox builds a day per developer account, across every application you have created. It was 50.
- Its own counter. Production builds no longer use up your sandbox builds.
- A refused build spends nothing else. When your app's own sandbox allowance is already used up, the build is refused before any shared limit is counted, so one app retrying past its allowance cannot drain the room your other apps share.
- Refusals that name the limit. Every sandbox limit refusal says which limit stopped it and the number, and your account's limits also say how to raise them.
What each refusal tells you
| Limit | Sandbox | How to get past it |
|---|---|---|
| Person, per credential | 25 | Provision another test user |
| Application | 50, unless raised | Request a higher limit from Usage |
| Developer account | 250 | Email developer@layout.link |
| Credential, every person | 50,000 | Email developer@layout.link |
When Layout's own capacity for the day is reached, the refusal says it is Layout's limit, not yours. Every limit resets at midnight UTC.
A refused build is not an HTTP error. The order tool answers normally with no cart and a userMessage such as:
"This test user has reached today's limit of 25 builds per person for this credential. It resets at midnight UTC. To keep testing today, provision another test user."
Production stays plain
In production the person reading the refusal is your end user, so the userMessage stays plain and never mentions developer limits, and the assistantInstruction names the limit for your model and tells it not to mention developer limits to the person. For how production builds are pooled, see Safer codes, fairer limits.
The rate limits page
Rate limits and idempotency now lists every limit that can refuse you, what each counts, and which ones share a counter between sandbox and production. Provisioned users and build sessions still count sandbox and production together. Sandbox sends no verification texts, so it uses none of that limit.
What to do
Nothing. If you were working around the old limit of 50, you have five times the room. Usage raises one application's allowance only; to raise the account limit, email us.
Breaking changes
None. Refusal messages have new wording, so if you matched on the old text, match on the absence of a cart instead.