Limits and availability

Layout meters the connector for two reasons, and only one of them is abuse. The other is that some calls cost real money the moment they run, so an enthusiastic loop is expensive rather than merely noisy.

Rate limits

Every tool call is limited per person and per connecting client, and a call has to pass both. The limit is a token bucket, so a short burst is fine and a sustained loop is not. It is kept in each server instance's memory, so it stops one caller's loop rather than a distributed flood. The limits that protect money, such as the daily spending limit, the live menu allowance and the cap on texted codes, are kept in the database and hold across every instance.

A rejected call comes back as a rate limit with a stable error code, not as an empty result. A host model that receives an empty menu concludes the restaurant has no food; one that receives a rate limit knows to wait.

The metered read

Reading a live menu opens a real browser against a real website, which costs us cents rather than fractions of a cent. Two guards apply to it:

• A daily allowance per person. Generous for ordering, finite for browsing.
• A cooldown on reading the same restaurant again. A repeat call while a read is running attaches to that read instead of starting a second one.

Both are stated to the caller when they bite, and both exist because of a real incident rather than a theory: a question a model could not use with the answer it got was immediately asked again, and the second read cost the same as the first.

Timeouts, and why a build takes minutes

Building a cart at a restaurant takes a couple of minutes when Layout has to work through the restaurant's ordering site from the start. That is a real browser on a real site, and it is bounded: a session has a hard ceiling, so a stuck run ends rather than running up a bill.

The consequence for a host is that order may return a "building" status and finish later. That is a normal answer and not an error. The right response is to relay the tracking link and poll order_status, which is free. Starting a second build is the one action that produces two carts and two charges, so it is worth saying plainly: do not.

Idempotency

State changing calls require an idempotency key. A retry with the same key and payload replays the stored result; the same key with a different payload is refused. This is what makes a network timeout safe to retry.

Availability

Current status, incidents and history: status.layout.link.

Layout depends on a restaurant's own website being up. When theirs is down, ours reports a failure that is honest about whose it was, because "we could not reach the restaurant" and "we broke" send a person to two different places.

Early scale

Layout is early and sized for it. We would rather say that than imply a capacity we have not tested. If you are planning something that would put real volume through the connector, talk to us first at contact@layout.link so the answer is a plan rather than a rate limit. Building an app on Layout has its own limits and sandbox, documented at developer.layout.link.