Tier Limits & Caps
Every tier has limits on atoms, bootstraps, storage, and compute resources, enforced by the MCP tools. Deliberate over-limit atom writes via the raw API are billed as metered overage up to your spend cap (the hard stop). This page explains exactly what each limit means, where it is enforced, and what your AI experiences when a limit is reached.
Limits per tier
| Limit | Starter | Solo | Professional | Team |
|---|---|---|---|---|
| Max atoms | 1,000 | 10,000 | 100,000 | 500,000 |
| Bootstraps / month | 200 | 1,000 | 10,000 | 20,000 |
| Storage | 100 MB | 500 MB | 2 GB | 10 GB |
| Substrates | 1 | 2 | 3 | 5 |
| Container memory | 256 MB | 512 MB | Dedicated | Dedicated |
| Container CPU | 0.5 cores | 1.0 cores | Dedicated | Dedicated |
| Hosting model | Shared host | Shared host | Dedicated droplet | Dedicated droplet |
What each limit means
Atoms (max stored)
Your tier's included atom allowance. The MCP tools enforce it — a session_checkpoint that would exceed the limit returns a cap_hit error. If you deliberately write above the limit via the raw API, excess atoms are billed as metered overage at $0.01/atom (see Plans → Overage pricing), up to your monthly spend cap (the hard stop). Set a spend cap to bound overage charges.
The limit applies to live (non-tombstoned) atoms. When you tombstone an atom via session_checkpoint, it is removed from the count. If you are near the limit, tombstone obsolete atoms to reclaim capacity.
Important: writes are all-or-nothing. If a session_checkpoint tries to store 5 new atoms but you only have room for 3, the entire write is rejected — no partial writes occur. This protects data consistency.
What your AI sees when the cap is hit:
MCP tool error: cap_hit — maximum atoms reached (10000/10000).
Tombstone unused atoms or upgrade your plan.Overage pricing: If you exceed your atom limit, excess atoms are billed at $0.01 (USD) per atom per month above your tier limit. This only applies if you deliberately work above the cap via the API. The MCP tools enforce the limit by default. All prices are in US dollars (USD).
Bootstraps per month
The maximum number of memory_session_bootstrap calls per calendar month (resets on your billing cycle date). This is enforced at the API level — once exhausted, bootstrap calls return 429 Too Many Requests until the next cycle.
How to plan your bootstrap usage:
- Each Claude session uses 1 bootstrap call
- Starter: 200/month ≈ 6 sessions/day
- Solo: 1,000/month ≈ 33 sessions/day
- Professional: 10,000/month ≈ 333 sessions/day
- Team: 20,000/month ≈ 667 sessions/day
If you are hitting the bootstrap limit regularly, consider upgrading your plan. You can check your remaining bootstraps on the Dashboard under My Substrate → Usage. Team plans include 20,000 bootstraps per month.
Storage
Total disk storage for your atom values and Merkle tree data. In practice this limit is rarely hit before the atom cap — average atom values are small (under 200 bytes each). Storage is monitored but soft-capped: you receive a warning when you approach the limit, and the system starts rejecting new atom writes once the limit is exceeded.
Container memory and CPU
These are the compute resources allocated to your MMPM container. They affect how quickly your instance can process parallel requests and how large your in-memory Markov model can grow. You do not configure these directly — they are set automatically by your tier and adjusted during tier changes.
| Tier | Memory | CPU |
|---|---|---|
| Starter | 256 MB | 0.5 cores |
| Solo | 512 MB | 1.0 cores |
| Professional | Dedicated server resources | Dedicated server resources |
| Team | Dedicated server resources | Dedicated server resources |
In practice, higher compute resources mean faster bootstrap responses, quicker Merkle proof generation, and better handling of concurrent requests from multiple AI clients.
Substrates
Each account can run multiple memory substrates depending on tier (Starter 1, Solo 2, Professional 3, Team 5). Each substrate is your own isolated memory instance with its own atom storage, bootstrap counter, and MCP endpoint.
What happens when limits are hit
| Limit hit | Behaviour |
|---|---|
| Atom cap | New writes rejected with cap_hit. Existing atoms unaffected. |
| Bootstrap cap | Bootstrap calls return 429. Other API operations (read, write atoms) still work. |
| Storage cap | New writes rejected with storage_full. Read operations unaffected. |
| Spend cap | Instance paused after 15-minute grace period (see Spend Caps). |
Checking your current usage
Go to Dashboard → My Substrate. You will see live counters for:
- Atoms used vs. limit
- Bootstraps used this month vs. limit
- Storage used vs. limit
The Dashboard refreshes every 60 seconds during active use.
How to reduce atom count
If you are approaching the atom limit:
- Tombstone obsolete atoms — in your AI config, have Claude call
session_checkpointwith atombstonearray containing keys that are no longer relevant - Review your atom naming — atoms with similar conflict keys replace each other automatically; if you name atoms correctly, redundant atoms overwrite stale ones
- Audit your atoms — call
memory_list_atomswith a prefix filter to review what is stored and identify candidates for removal
Tombstoned atoms are removed from the live count within seconds of being recorded.