MemoryRouterCost model
How MemoryRouter usage-based memory maps to multi-user app economics.
Cost model
MemoryRouter is designed for app economics, not infrastructure allocation.
You should not pay as if every registered user is constantly using memory. Memory cost should follow actual memory activity.
registered users ≠ active users ≠ heavy memory usersThe app pattern
A consumer AI product might have:
100,000 registered users
18,000 monthly active users
4,000 weekly active users
600 heavy usersYour memory workload is driven by the users actually having AI interactions, and by the amount of memory retrieved or stored for those interactions.
Why this matters
If you build memory infrastructure yourself, you often pay for capacity before users create value:
- vector database capacity
- background ingestion jobs
- embeddings pipeline
- storage growth
- retrieval tuning
- operational maintenance
- scaling headroom for power users
With MemoryRouter, the integration is closer to usage-based memory as a service. Quiet users cost little. Heavy users consume more because they create more value and more retention.
Unit economics lens
Think in product terms:
| Metric | Why it matters |
|---|---|
| Registered users | Identity count. Should not define memory cost by itself. |
| MAU | Real audience size. Useful for forecasting. |
| AI sessions | Primary driver of retrieval and storage activity. |
| Heavy users | Highest cost, but usually highest retention and revenue value. |
| Memory imports | One-time migration or backfill events. |
Import and backfill costs
Backfilling existing transcripts, support history, profiles, or notes creates a one-time memory workload. After import, ongoing usage follows live AI activity.
Enterprise pricing
Enterprise plans can align committed usage, custom terms, DPAs, SLAs, and data residency with your product needs. Avoid modeling costs from total accounts alone. Model from expected active usage and memory intensity.