Limits
The size, count and length bounds on every request, how requests for one end user are ordered, and what happens when your daily budget is spent.
Request size
| Limit | Value | Over it |
|---|---|---|
| Request body | 1,000,000 bytes | 413 body over 1000000 bytes |
Items per add | 1 to 500 | 422 |
Ids per list in forget (items, sessions, threads, events) | up to 500 each | 422 |
Ids per status | 1 to 500 | 422 |
about tags per item | up to 20 | 422 |
The body limit is checked against Content-Length before the body is read, and counted as it arrives when the
body is chunked. A large document is the usual reason to reach it: split it into several documents, or send
fewer items per add.
Text lengths
| Field | Bound |
|---|---|
query (search), pattern (grep) | 1 to 2,000 characters |
Names: ids, paths, session, title, role, subject, attribute, scope, place, author fields, each about | up to 512 characters |
replacement (correct) | up to 4,000 characters |
Item text | at least 1 character; bounded by the body limit |
Dates: at, expires, before, after | must begin YYYY-MM-DD and be a real day; up to 40 characters |
X-Twin-Account | see End users & tenancy |
2026-13-01 is refused with 422, as is "last week": dates are ISO, never words.
Result sizes
Search takes no count. It returns what the question needs: up to 8 records in a ranked list, and passages of up to 1,400 characters each. A grep match is a fragment of up to 320 characters.
Concurrency
- One request per end user at a time. Requests for the same end user run one after another, in the order they arrived. Requests for different end users run side by side.
- A service-wide cap. When the service has as many requests in hand as it can take, a new one is refused at
once with a plain
503. Retry with backoff.
If you add many items for one end user, send them as batches of up to 500 rather than one request per item.
Rate limits
There are no per-key or per-project request rate limits today. Plan limits Soon.
Daily budget
Two steps call a model: reading conversations into records, and the filter that keeps what a search needs. Both count against your organisation's daily budget, which you set in the console.
When the day's budget is spent:
- Reading waits. New items still land and are searchable by their words and meaning. They are read into records the next UTC day, once the budget allows.
- Search answers unfiltered. It returns the ranked passages and records without the model call, so it
spends nothing against the budget.
heldis absent from the response. - Nothing is refused. No request fails because of the budget.
Related
- Errors: every status and message.
- Idempotency & retries: when to retry.