# Usual menus answer first

October 23, 2026 · API

When you ask for the menu of a location Layout has not read yet, `POST /v1/menus` and the MCP `menu` tool now answer at once with the restaurant's usual menu, if Layout knows it. Before, the answer was `status: "reading"` and the usual menu came back only if that read failed. See [POST /v1/menus](https://developer.layout.link/reference/api#post-v1-menus).

## What changed

- **Order of answers.** This location's own recent menu first. Then the restaurant's usual menu, marked `scope: "chain"`. A live read starts only when Layout knows neither.
- **No allowance spent.** A usual menu draws nothing from your live menu read allowance. The per-person request limit still applies.
- **The location is still read.** Asking counts toward Layout reading this location, so a later ask can return its own priced menu, with no `scope`.

## Why it matters

You get a menu on the first call for most locations of a restaurant Layout already knows, instead of polling a read.

## What to do

Nothing, if you already handle `scope: "chain"`. If you do not, treat it as what this location probably carries, not its exact menu, and show no prices for it.

## Breaking changes

None. No field was added or removed. You may see `scope: "chain"` more often, and `status: "reading"` less often.