Agent memory cost has two bills: the tokens you keep resending to the model, and the retrieval or memory layer you pay to avoid resending them. Start with dollars per 1,000 agent queries. If the recalled context is small or reused rarely, context-stuffing can be cheaper; if it grows, priced retrieval becomes easier to reason about.
Last updated: June 20, 2026.
The answer: price memory as a query economy
Do not begin with a vague monthly platform fee. Begin with one repeatable unit:
| Cost line | What it measures | Formula |
|---|---|---|
| Context stuffing | Input tokens resent into the model | queries x context tokens x input price |
| Answer Engine memory | Credits used for search and retrieval | queries x credits per query x cost per credit |
| Decision view | Which line is higher under your assumptions | compare dollars per 1,000 queries |
Provider pricing pages make the first line measurable. OpenAI, Anthropic, and Google publish model input pricing per million tokens, and those prices vary by model family and caching path: see OpenAI API pricing, Anthropic Claude API pricing, and Google Gemini API pricing. The right number for a calculator is the input-token price for the model you actually call.
The second line should come from the product’s real billing model. In Answer Engine, the public memory cost calculator uses the same billing-plan loader as the pricing page, then counts one agent_search_query credit and one agent_data_retrieval credit per query from CREDIT_COSTS. That makes the calculator sensitive to plan and credit changes instead of copying a static price into content.
Why context stuffing looks cheap until it is not
Context stuffing is easy to understand: collect prior messages, snippets, summaries, and source text, then put them back into the prompt. It is a reasonable baseline when the agent has a short memory, low query volume, and a small number of sources. It is also useful for experiments because there is no new system to operate.
The catch is repetition. If a workflow resends the same large context every time, the model input line scales with both query volume and context size. Even when prompt caching helps, cache economics depend on provider support, cache lifetime, cache read/write rules, and prompt stability. Anthropic documents separate prices for base input, cache writes, cache hits, and output tokens on its pricing page, and its prompt-caching guide explains that cache reads and writes use different multipliers from ordinary input tokens: Anthropic prompt caching.
That means “just stuff the context” is not free. It is a design choice with a meter attached. The meter may still be acceptable, especially for low-volume tools. The point is to write the meter down.
What memory credits are buying
A memory layer is not only a cheaper prompt. In a production agent, memory has to retrieve the right facts, expose the source trail, support deletion, separate tenants, and keep superseded facts from silently winning. The agent memory complete guide covers those controls in more depth.
For cost modeling, keep the first pass narrower. Ask: what does one memory-backed query cost before we add broader product value? In the launch calculator, Answer Engine counts:
| Answer Engine action | Credit count | Why it is in the query model |
|---|---|---|
agent_search_query | 1 | The search step finds candidate memory. |
agent_data_retrieval | 1 | The retrieval step returns the selected source-aware memory. |
| Total | 2 | The calculator multiplies this by plan cost per credit. |
This is still an estimate. It does not include ingestion, document QA, output tokens, model reranking, engineering time, or accuracy. That restraint is intentional. Launch content should not smuggle a benchmark into a calculator.
How to use the calculator without fooling yourself
Use the interactive memory cost calculator in three passes.
- Enter your current query volume and average context size.
- Enter the model input price from your provider’s pricing page.
- Select the Answer Engine plan you would actually buy.
Then look at dollars per 1,000 queries and monthly delta. If context stuffing is lower, say so. If Answer Engine memory is lower, treat that as a result for those inputs, not a universal claim. The shareable URL preserves only the calculator values, so you can paste the result into an issue, procurement memo, or architecture review without sending source content.
For vendor comparison, pair this with the agent memory systems comparison. Cost should sit beside inspectability, erasure, portability, multi-source recall, and tenant isolation, not replace those criteria.
What not to claim yet
Do not publish “memory saves X%” unless the claim is computed from a stated workload or backed by a reproducible public harness. Do not say the system improves itself until the shipped product has the logged retrieval traces, evaluation set, and release gate to prove it. Do not use an accuracy number until the gated evaluation issue lands.
The honest launch claim is simpler: Answer Engine gives teams a source-aware memory path with visible pricing, and the calculator shows the cost of that path against context stuffing under your assumptions. That is strong enough for the launch site because it lets buyers inspect the math instead of trusting a slogan.
FAQ
What is the simplest way to price agent memory?
Use dollars per 1,000 agent queries. One side is input-token cost for resending context. The other side is the memory system’s query cost, such as Answer Engine credits per search and retrieval.
Is context stuffing always more expensive than memory?
No. Context stuffing can be cheaper for low-volume, small-context, or cache-friendly workflows. Memory becomes easier to justify when context grows, when teams need inspection and erasure controls, or when repeated context starts dominating the model input line.
Does the calculator include output tokens?
No. It isolates the memory decision by comparing input context cost with memory credit cost. Add output tokens, caching, ingestion, and infrastructure in your own model if they materially change the decision.
Why does the Answer Engine side use credits?
Credits are the customer-visible billing unit on the launch pricing page. The calculator uses the current plan’s effective cost per credit so the estimate changes when the billing model changes.