> ## Documentation Index
> Fetch the complete documentation index at: https://docs.atlaso.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Limits & quotas

> Payload sizes, rate limits, storage quota, idempotency, deletion, and viewing memory in the dashboard.

Everything you need to know before you scale Atlaso Build.

## Payload sizes

| Field               | Limit                                 |
| ------------------- | ------------------------------------- |
| `text` (per memory) | 1 byte – 64 KB UTF-8                  |
| `tags`              | ≤32 per memory, each ≤128 chars       |
| `q` (recall query)  | ≤2048 chars                           |
| Recall `limit`      | Default 5; values are clamped to 1–50 |

Empty or oversized text, tags, or queries return `400`. Some validation
responses do not include an `X-Atlaso-Error` header. A missing or mistyped
parameter returns `422`; recall `limit` is clamped rather than rejected.

## Rate limits

Atlaso uses two-level fair sharing so one busy account can't starve the
platform.

* **Per credential (project key or device credential):** 60 `remember`/min and
  120 `recall`/min. All subjects using the same project key share that key's
  limits; separately minted device credentials have separate limits.
* **Per live process:** once an account is placed on a process, that process
  provides a **600 requests/min floor**, with opportunistic bursting up to
  10,000/min when it has headroom. This is process-local capacity, not a
  durable account-wide SLA.

Data-plane rate limiting returns `429` with a `Retry-After` header — honour it
and add a little jitter. Provisioning endpoints may return `429` without that
header; if it is absent, retry with exponential backoff. A `503
placement_denied` means the server is momentarily full; retry with backoff.

<Note>
  Within a single account, sharing is best-effort — a very large fleet
  (\~25+ devices hammering at once) can temporarily crowd out the same account's
  other clients. Spread bursty writes out, or contact us if you're planning a
  large rollout.
</Note>

## Storage

Each account can hold up to **5,000,000 live memories** and **20 GiB** of memory
text. Over quota, `remember` returns `413 storage_quota_exceeded`. Deleting
memories or purging subjects frees the quota. Need more? Email
[support@atlaso.ai](mailto:support@atlaso.ai).

## Idempotency

Only `POST /memories` and `POST /device-credentials/batch` accept an
`Idempotency-Key` header. Atlaso uses it for best-effort deduplication per
`(project, key)`.

* Same key, **same** body → the original result is returned, no second write.
* Same key, **different** body → `409` (you reused a key for a different
  operation).

Use a fresh UUID per logical operation. Keys have no documented expiry, so a
reused key can continue to replay or conflict indefinitely.

## Deletion & GDPR

* **[Delete a memory](/build/api-reference#delete-a-memory)** — a real erase of
  the memory, its search index, and its conflict links. Not a tombstone.
* **[Purge a subject](/build/api-reference#delete-a-subject-gdpr)** — removes an
  end-user's entire bag in one call, for "delete my data" requests.
* Both are idempotent and free the storage they used.
* A lapsed Build subscription **never deletes anything** — data returns on
  renewal.

## Viewing memory in the dashboard

Everything your API writes is visible in the Atlaso dashboard: open the
**Memory** tab and switch to the **Build** view to browse memories grouped by
project and subject. Each project also shows daily **usage** — `remember` and
`recall` calls, hits, and bytes — so you can see what your integration is doing.

## Key & credential lifecycle

* Up to **10 live project keys** per project; revoke instantly from the
  dashboard.
* Device credentials: 50 per subject, 100,000 per project; revoke one by id or a
  whole fleet by `group_id`.
* Revocation takes effect immediately — the next call gets `401`.