Flat Rate Agent Memory Without Token Surcharges

Flat rate agent memory charges for memory operations, not tokens: each extracted memory counts as one add, retrieves are tiered in blocks of 10, and each tier is a fixed monthly quota from $0 to $260. Here is how both counters work and how to forecast your month.

Why flat rate agent memory bills operations, not tokens

LLM inference is priced in tokens because the work scales with input and output length. Every extra token adds compute in the forward pass, so a token meter tracks the cost driver directly. Memory operations do not work that way. The expensive part is extraction, embedding, indexing, and retrieval over your stored facts, not the length of any single message.

A short message can produce several durable memories. A long pasted log can produce none. Priced in tokens, a stack trace that yields two facts would cost more than a three-line convention note that yields three facts, even though the second case stored more useful state. That mismatch is why flat rate agent memory counts operations instead of tokens.

Audaxic Memory uses flat monthly pricing with no per-token fees and no overages. Each tier is a fixed price for a fixed quota of adds and retrieves per month. You pay $0, $12, $50, $125, or $260, and you budget against the quota.

The mem0-like API exposes the same five data-plane operations at every tier: POST /add, POST /search, GET /list, PUT /update, and DELETE /delete. Billing does not change which endpoints you can call. It changes how many adds and retrieves your quota covers. The pricing docs define both counters, and the pricing page lists the current tier quotas.

How one add request is counted

An add request is counted per memory extracted from a message batch. One /add call that extracts 5 memories counts as 5 add requests. The unit is the extracted memory, not the HTTP request, the message count, or the token count.

This distinction controls your monthly total. Suppose your agent sends one batch with a short design note and the extractor pulls out five facts: package manager, test command, branch naming rule, reviewer preference, and deploy target. That is 5 add requests. Suppose the next batch is a long pasted build log and the extractor finds one durable gotcha about a flaky test. That is 1 add request, even though the second batch carried far more text.

Batching does not reduce the count, and splitting does not increase it. Ten facts in one /add call count as 10. The same ten facts across ten calls count as 10. What matters is how many memories the extractor persists. A batch that yields zero memories adds zero to the counter.

Your extraction habit sets your add volume. An agent that stores one preference per session uses almost nothing. An agent that digests meeting notes and migration plans into dozens of atomic facts uses far more. Plugins for Claude Code, Codex, and OpenCode save facts as you work, and any MCP client writes through the same /add path, so the rule applies identically across plugins, MCP, and direct REST calls.

Store one fact per memory: one convention, one decision, one constraint, one gotcha. Atomic memories retrieve better and make the monthly math easier to forecast, because sessions per day times memories per session equals adds per month. The add endpoint reference covers the request shape, and Memory Layer Pricing Math: What 500K Adds Actually Cost walks through per-add arithmetic tier by tier.

How retrieve blocks of 10 are counted

Retrieve requests use tiered counting: the first 10 memories retrieved count as 1 request; each additional 10 counts as 1 more (25 memories = 3 requests). The counter increments on memories returned, not on searches issued.

Three cases show the rule. A POST /search that returns 8 memories counts as 1 retrieve request. A search that returns exactly 10 counts as 1. A search that returns 25 counts as 3: 1 for the first 10, 1 for the next 10, and 1 for the final 5. Any partial block of up to 10 counts as a full request.

Broad queries cost more than narrow ones. Returning 100 memories in one search counts as 10 retrieve requests. Returning 10 counts as 1. A session that runs three tight searches returning 8 memories each uses 3 retrieve requests. A session that runs one wide search returning 60 uses 6.

GET /list pages through stored memories with limit and offset, so the same habit applies: focused pages help the agent more than wide ones. PUT /update and DELETE /delete maintain stored facts rather than returning new memories for the agent to use. Only returned memories move the retrieve counter.

Every plan keeps a 10:1 ratio between adds and retrieves. Starter pairs 50,000 adds with 5,000 retrieves, Growth pairs 200,000 with 20,000, Pro pairs 500,000 with 50,000, and Enterprise pairs 1,000,000 with 100,000. Hobby pairs 10,000 adds with 1,000 retrieves. That ratio matches the block size in the counting rule and fits a normal workload where your agent writes far more than it reads back per session.

Flat rate tiers: what $0 to $260 covers

Five tiers, all with unlimited projects and graph memory included from Hobby through Enterprise:

Hobby costs $0/month and requires no credit card. Enterprise adds one option beyond quota: on-premise deployment available on request. Everything else about the tiers is quota size. Compare your counters against the published tier table before you pick a tier.

Effective cost per add stays nearly flat across paid tiers because quotas scale with price. Starter works out to $0.24 per 1,000 adds, Growth and Pro to $0.25, and Enterprise to about $0.26. Per retrieve the same pattern holds: roughly $2.40 per 1,000 retrieves on Starter, $2.50 on Growth and Pro, and $2.60 on Enterprise, with each retrieve request covering up to 10 memories.

Flat monthly means the invoice does not move with message length. A month of long pasted logs that extract few facts costs the same as a month of short messages, provided extracted and returned counts match. A bulk import of past Claude Code, Codex, and OpenCode conversations goes through the same per-memory add rule, so an import month counts each imported memory as an add. Keep the machine-readable pricing file in version control to catch quota or price changes over time.

For a quota-for-quota comparison against mem0 list prices as of August 2026, read Mem0 Alternative: Cheaper Memory Layer for Coding Agents — Pricing Compared. That post carries the dated comparison table so this explainer stays focused on counting.

Forecast a month from session habits

Forecasting needs two inputs: memories extracted per session and searches run per session. Multiply by sessions per day and working days:

monthly adds = memories per session x sessions per day x working days
monthly retrieves = searches per session x sessions per week x 4, adjusted for block size
example: 20 memories x 3 sessions x 22 days = 1,320 adds

Start with adds. A solo developer running 3 sessions a day for 22 working days runs 66 sessions. At 20 memories per session, that is 1,320 adds for the month, well inside Hobby. At 50 per session, the same schedule produces 3,300 adds, still inside Hobby. At 300 per session during a migration month with heavy note-taking, the total reaches 19,800 adds, which fits Starter at $12/month.

Now add retrieves. Each session runs 3 searches returning 8 memories each. Each search counts as 1 retrieve request, so each session uses 3 requests and the month uses 198. That fits Hobby with room to spare. Widen the searches to 25 memories each and each search counts as 3 requests, so each session uses 9 and the month uses 594. Adds have not changed, but retrieves have tripled. Both counters must fit the tier.

Two habits make forecasts accurate. First, measure one normal week before projecting. Page through GET /list output and count what your workflow actually stored per session instead of guessing. Second, separate steady-state months from import months. Importing past conversations adds a one-time block of memories under the same per-memory rule, so budget the import month on its own total.

A team forecast multiplies the solo math. Five developers each producing 19,800 adds reach 99,000 team adds, which fits Growth at $50/month. Retrieval stays modest in the same scenario: five developers at 198 requests each total 990 retrieves against a 20,000 quota. Adds drive the tier decision in almost every workload because extraction volume outruns search volume by a wide margin.

When to move tiers: quota math only

Move tiers when either counter no longer fits, and pick the lowest tier that covers both. Flat rate agent memory has no token surcharge to model and no per-request meter to reconcile. The decision is two comparisons against published quotas.

First, compare monthly adds against the boundaries: 10,000, 50,000, 200,000, 500,000, and 1,000,000. Move to the first tier whose adds quota covers your forecast or your last full month. A solo developer at 8,000 adds stays on Hobby. At 19,800 adds the same developer needs Starter. A team at 99,000 adds needs Growth. A team at 250,000 adds needs Pro.

Second, compare monthly retrieves against the boundaries: 1,000, 5,000, 20,000, 50,000, and 100,000, remembering the block rule. Most workloads pass this check without attention because the 10:1 quota ratio leaves wide headroom. The case that fails it is retrieval-heavy: many broad searches returning dozens of memories each. When searches regularly return 40 to 50 memories, each search consumes 4 to 5 requests, and a busy month can approach the retrieve quota while adds still look comfortable. Narrow the queries first, then re-check before moving.

Recheck at month end during growth phases. When adds approach the quota for two consecutive months, move up before the month you expect to cross it. When a single month spikes on an import or a refactor and the next month returns to baseline, budget that month at the higher tier. Tiers differ only in quota — projects stay unlimited and graph memory stays included — so the move changes headroom and nothing else.

Quota definitions live in the pricing docs. Check them when your estimate sits near a boundary.

FAQ

Written by Efe — Oct 11, 2026 · More articles · X @AudaxicTech