Tier Limits & Caps#

Every tier has hard limits on atoms, bootstraps, storage, and compute resources. 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#

What each limit means#

Atoms (max stored)#

The maximum number of atoms your substrate will hold simultaneously. This is a hard cap — once reached, session_checkpoint calls that would exceed the limit return a cap_hit error.

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.001 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.

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: Unlimited

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 have unlimited bootstraps.

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.

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 has one active memory substrate. This is your dedicated memory instance with its own atom storage, bootstrap counter, and MCP endpoint.

What happens when limits are hit#

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:

1. Tombstone obsolete atoms — in your AI config, have Claude call session_checkpoint with a tombstone array containing keys that are no longer relevant
2. Review your atom naming — atoms with similar conflict keys replace each other automatically; if you name atoms correctly, redundant atoms overwrite stale ones
3. Audit your atoms — call memory_list_atoms with 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.