# Limits

What one request, rule, release or call may hold at most, and why each limit sits where it does.

- `rules_per_release` (`10000`): Rules one `rules.json` may hold.

- `description_length` (`200`): Characters in a rule's description.

- `pins_per_rule` (`100`): Pins one rule may hold, at unique positions.

- `pins_per_query` (`100`): Pins one engine query may place.

- `targets_per_query` (`4`): Boost and bury targets in one engine query, which is one section of a response. The engine pays 2^n - 1 sub-searches for n targets and silently drops weights beyond its scale fuel, which `compose.yaml` sets to pay for exactly this many.

- `keys_per_query` (`96`): Engine rules one query switches on, pins and targets together. Each key costs the engine one unit of filter fuel; beyond this many, it drops rules.

- `hidden_per_query` (`100`): Entity ids one query may hide; hiding more for every request is an overlay.

- `phrases_per_operator` (`100`): Phrases in one `is`, `contains` or `starts_with`.

- `nesting_depth` (`3`): Levels of `any`, `all` and `not` in one expression.

- `per_page` (`100`): Hits one page of a response may hold.

- `reachable_hits` (`1000`): Hits one search's pages reach, however many match: the engine ranks every hit up to the page asked for, so a page's time grows with its depth, and the deepest stays within the search latency budget. Totals are counted exactly past it; a response says how many hits are reachable.

- `token_dimensions` (`8`): Fields one type's combination tokens combine: the variant-level values its facets count. A variant holds up to 2^n - 1 tokens for n of them, so twenty would make a million.

- `filter_combinations` (`1000`): Combinations of chosen values one request's filters may name across the variant-level fields they narrow, such as three colors in two sizes for six.

- `redirect_patterns` (`500`): Patterns in `redirects.json`. Every URL no exact entry matches runs through all of them; a table of exact entries has no limit of its own.

- `counted_facets` (`30`): Facets a page counts on every request before the shopper opens any: the first of its layout, and every one a choice or a request's `facets` names. The engine pays for each facet it counts each time, and the cost grows with the facets, not with the values they hold, so a page of a hundred facets counts the first thirty and lists the rest without values (`deferred`).

- `facet_values` (`50`): Values a counted list or swatch facet carries before `more` says there are others: the most frequent ones, and every chosen one. A request that names the facet in `facets` gets all of them, and a layout may set another number per facet (`limit`).

- `offers_per_call` (`1000`): Offer changes one `PUT /api/v1/offers` carries. A larger batch is refused whole, so a shop sends its changes in batches of this size; each batch is one revision.

- `placements_per_page` (`8`): Banners one page of a response shows, top, grid and bottom together. Placements past it are left out in rule order, and the trace says so.

- `synonyms_per_call` (`1000`): Synonym entries one add carries, such as the lines of one paste. A larger batch is refused whole.

- `words_per_check` (`50`): Words one synonym check searches for; an entry with more is refused whole.

- `events_per_call` (`100`): Clicks and views one `POST /v1/events` carries, well within the 64 kB a browser's beacon may send. A larger batch is refused whole.

- `event_hours` (`48`): Hours after an answer that its clicks and views are taken and joined to its search; an event for an older answer is refused by its query ID's time, without a lookup, and counted as late.

**Guide:** [Limits](/docs/rules#limits)
