Do Claude's memory features cost extra?

Do Claude's memory features cost extra?

Claude's memory features do not carry a price of their own. Anthropic's published rates are per million tokens of input and per million tokens of output, with extra rates for prompt caching, and none of them is called a memory token. Storing the memory itself costs nothing on the Claude API (application programming interface), because the memory tool is client-side and the file lives on storage you own.

Memory still reaches your bill, because a remembered fact only changes an answer when it is inside the request Claude reads. Remembering means re-sending. That text arrives as input tokens and is charged at the model's ordinary input rate. Two numbers decide how much: how many tokens of remembered text you replay on each turn, and whether that replayed text can be served from the prompt cache.

On a Pro or Max subscription you are not billed per token at all, so memory spends your usage allowance rather than your money. The mechanism below is identical. Only the unit changes.

What "memory" means on each Claude surface

Three separate products share the word, and mixing them up is most of why this question feels confusing.

The memory tool on the Claude API. You add one entry to the tools array and implement the file operations in your own code.

{"type": "memory_20250818", "name": "memory"}

As of August 2026 this tool is generally available on the Messages API with no beta header, on Claude 4 and later models. It is client-side: Claude asks for an operation such as view /memories, your handler runs it against storage you control, and you return the result in a tool_result block. Anthropic never holds the file, so there is no storage charge to pass on. You pay for the round trip instead. The tool definition is sent in every request, and the file content that comes back stays in the conversation from that point on.

Anthropic publishes the fixed part of that overhead. On Claude Opus 5 with a tool choice of auto, the tool-use system prompt is 286 tokens, as documented in August 2026. That is paid once per request whenever any tool is present, memory or otherwise.

Claude Code. Two mechanisms load at the start of every session. CLAUDE.md files hold instructions you write. Auto memory holds notes Claude writes for itself, under ~/.claude/projects/<project>/memory/. Only the first 200 lines or 25KB of MEMORY.md is loaded, whichever limit comes first, and the topic files beside it are read on demand rather than at startup. Everything loaded at startup becomes part of the prefix that every later request in that session carries. How Claude Code recalls memory between sessions covers the loading order file by file.

Claude on the web. On claude.ai, memory is a set of entries Claude writes and updates as you chat, with a separate memory space for each project. Settings > Memory lists what is stored, and the toggle there offers Pause memory or Reset memory. This surface is billed by subscription, so memory here spends usage limits.

Why remembered text is billed as input tokens

The Messages API is stateless. It keeps nothing between calls, so your client sends the whole conversation on every turn and the model reads all of it again. Memory is not an exception to that rule. It is one more block of text in the same request.

The split is visible in the usage object on any response.

"usage": {
  "input_tokens": 412,
  "cache_creation_input_tokens": 0,
  "cache_read_input_tokens": 18240,
  "output_tokens": 236
}

input_tokens counts only the tokens that were neither read from the cache nor used to create it, which in practice means the tokens after the last cache breakpoint. Total input for the request is cache_read_input_tokens plus cache_creation_input_tokens plus input_tokens. A memory file Claude opened three turns ago sits inside that total on every turn since. It lands under cache_read_input_tokens while the cached prefix holds, and under input_tokens when it does not. Same text, two very different prices. Input and output tokens carry different prices, and memory only ever lands on the input side.

Where to see these numbers in your own usage

Do not take a figure from a blog post, this one included. Measure your own memory block. Token counting is free and has its own rate limit, so the measurement costs nothing.

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "system": "You are a scientist",
    "messages": [{"role": "user", "content": "Hello, Claude"}]
  }'

The response is one number, such as { "input_tokens": 14 }. Run it once with your memory text pasted into the system field and once without it, and the difference is what that memory costs you on every turn. Two cautions apply. The count is an estimate, and extra tokens Anthropic adds for its own system optimizations are not billed to you. Also count against the model you will actually run, because Claude 4.7 and later use a newer tokenizer that produces roughly 30 percent more tokens for the same text.

Inside Claude Code the same question is answered without any curl at all.

• /context shows what is loaded right now, memory files included, so you can see their share of the window before you type anything.
• /memory lists your CLAUDE.md files and opens the auto memory folder.
• /usage prints the session totals, cache reads and cache writes among them.
• The status line can display context window usage continuously, so growth is visible while it happens.

The /usage session block looks like this:

Total cost:            $0.55
Total duration (API):  6m 20s
Total duration (wall): 6h 33m 10s
Total code changes:    0 lines added, 0 lines removed
Usage by model:
   claude-sonnet-4-6:  1.2k input, 5.3k output, 940.0k cache read, 50.0k cache write ($0.55)

Read the last line carefully. The 940.0k cache read figure is the conversation, memory and all, being sent again on every turn at the cache rate. The 1.2k input figure is only the part that was new. Claude Code computes that dollar amount locally from list prices, so it ignores any discount you have and can differ from your invoice. The Usage page in the Claude Console is the authoritative number.

Then run the comparison directly. Ask the same opening question in two fresh sessions, one normal and one with auto memory switched off.

CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 claude

Run /context in each and compare the memory files entry. The gap is what your accumulated memory costs at the start of every session, before any work happens. A full breakdown of where Claude Code token usage goes is worth reading next to those two numbers.

How much does replaying memory cost per million tokens?

Prompt caching is the reason the same memory block can cost ten times more on one turn than on another. Anthropic publishes the cache rates as multiples of each model's base input price, so the relationship holds even when the dollar prices move.

[
  {
    "label": "Base input",
    "price_multiple": 1
  },
  {
    "label": "5 minute cache write",
    "price_multiple": 1.25
  },
  {
    "label": "1 hour cache write",
    "price_multiple": 2
  },
  {
    "label": "Cache read",
    "price_multiple": 0.1
  }
]

A cache read costs 0.1 times the base input price. Writing an entry with the 5 minute lifetime costs 1.25 times base, and the 1 hour lifetime costs 2 times base. Anthropic states the break-even plainly: caching pays off after one cache read at the 5 minute duration, or after two cache reads at the 1 hour duration. The break-even point for prompt caching is the calculation to run before you decide where memory belongs.

Those multiples turn the replay count into arithmetic. The next block is arithmetic from the published multiples above, not a measurement of any live workload. It prices a memory block three ways over a 100 turn session, expressed as the equivalent number of tokens charged at the plain base input rate.

[
  {
    "label": "4,000 tokens, never cached",
    "base_rate_equivalent_tokens": "400,000"
  },
  {
    "label": "4,000 tokens, 1 write and 99 reads",
    "base_rate_equivalent_tokens": "44,600"
  },
  {
    "label": "1,000 tokens, 1 write and 99 reads",
    "base_rate_equivalent_tokens": "11,150"
  }
]

A 4,000 token memory block that misses the cache on all 100 turns bills like 400,000 base-rate tokens. The same block behind one 5 minute cache write and 99 cache reads bills like 44,600. Prune it to a quarter of its size and keep the caching, and it bills like 11,150. The feature did not change across those 3 rows. Only the replay behaviour did.

The second row assumes each of the 99 later requests arrives while a cache entry is still alive. That assumption is where most real bills go wrong.

Why does the same question cost more after a break?

A cache entry has a lifetime, and the clock starts at the request that writes or reads it. The default is 5 minutes. The 1 hour option costs the 2x write shown above. In Claude Code the lifetime is one hour on a subscription, and it drops to five minutes once you are drawing on usage credits; on an API key or a cloud provider it is five minutes by default. Setting ENABLE_PROMPT_CACHING_1H=1 keeps the one hour lifetime while on usage credits.

So a one-line question typed into a session you left open over lunch is expensive because the cache entry expired while you were away. The whole prefix, memory included, is processed again at the base input rate and written to the cache again. The length of the pause set that price.

You can confirm this instead of believing it. On a Pro, Max, Team or Enterprise plan, the /usage breakdown flags any behaviour responsible for 10 percent or more of recent usage, and both long context and cache misses appear there by name. On the API, watch cache_creation_input_tokens jump back up to the full size of your prefix on the first request after a quiet period.

What quietly invalidates the cache

The cached prefix is ordered: tools, then system, then messages. A change at one level invalidates that level and everything after it. Editing a tool definition throws away the entire cache. Editing the system prompt throws away the system and message cache.

This is the trap for anyone who keeps memory in the system prompt and rewrites it as the agent learns. Each rewrite discards the cached copy of everything behind it, so the next request pays a full write again. Keep the stable material at the front and keep it stable, and let the volatile material sit late in the message list where invalidating it is cheap.

There is a second, quieter failure. Each model has a minimum cacheable prefix: 512 tokens on Claude Opus 5, 1,024 on Claude Sonnet 5, 4,096 on Claude Haiku 4.5, as published in August 2026. Anthropic's documentation is explicit about what happens below it: "Any requests to cache fewer than this number of tokens will be processed without caching, and no error is returned." A small memory file marked with cache_control therefore does nothing at all, silently. The symptom you can see is cache_creation_input_tokens staying at 0 while your prompt clearly contains a breakpoint.

Prune memory that no longer earns its place

Every line of memory costs tokens on every turn that carries it, so the question for each line is whether it changed an answer recently. Claude Code makes the limits concrete. Aim to keep a CLAUDE.md under 200 lines, because longer files consume more context and reduce how reliably Claude follows them. MEMORY.md is capped at the first 200 lines or 25KB at load time, and anything past that limit is dropped on the next session start, so an oversized index is paying tokens and teaching nothing.

Two habits keep it small. Move detail out of the index and into topic files, which Claude reads on demand instead of at startup. Move workflow instructions out of CLAUDE.md and into skills, which load only when invoked. For memory files that already begin with frontmatter, Claude Code records the write time in a modified field as an ISO 8601 timestamp, in version 2.1.214 or later, and that timestamp is the fastest way to spot a fact that has gone stale. Pruning stale agent memory goes through the review process in more depth.

When retrieval beats loading everything into context

The memory tool exists to support just-in-time retrieval. Instead of loading everything up front, the agent records what it learns and reads a file back only when a task needs it. That changes the arithmetic, because a file read costs its tokens once and then sits inside the cached prefix, while a permanently loaded block costs on every single turn.

A simple rule follows from the two charts above. Text that nearly every turn uses belongs in the stable cached prefix. Text that one turn in twenty uses belongs behind a view call. The break-even moves with your replay count, not with anything Anthropic charges.

On the API you can also let the platform trim the conversation. Context editing clears old tool results once the conversation crosses a threshold you set.

{
  "edits": [
    {
      "type": "clear_tool_uses_20250919",
      "trigger": {"type": "input_tokens", "value": 30000},
      "keep": {"type": "tool_uses", "value": 3},
      "clear_at_least": {"type": "input_tokens", "value": 5000}
    }
  ]
}

The defaults are a trigger of 100,000 input tokens and 3 tool uses kept. Read the interaction with caching before you enable it: clearing content invalidates the cached prefix at the point of the clear, so you pay a cache write on the next request. That is what clear_at_least is for. It holds off clearing until the saving is big enough to justify the write. The response reports exactly what happened under context_management, with cleared_tool_uses and cleared_input_tokens, so the trade is measurable rather than theoretical. Managing the context window in Claude Code applies the same idea to a coding session.

What does have its own line item

Memory has no charge of its own, but some features genuinely do, and it is worth knowing which. These are the published Claude API rates as of August 2026.

• Web search: $10 per 1,000 searches, plus the ordinary token cost of everything the search puts into context.
• Code execution: 1,550 free hours per organization each month, then $0.05 per hour per container. It is free when used alongside web search or web fetch.
• Claude Managed Agents: session runtime at $0.08 per session-hour, on top of the usual token charges.
• Web fetch: no additional charge, only the token cost of the fetched content.

Memory appears on none of those lines. It appears in your input token count, which is exactly where you can measure it, and exactly where pruning and caching can reduce it. If you are budgeting an agent that runs unattended on a virtual private server (VPS), the cost controls for an AI agent on a VPS are the next thing to put in place, because an agent with a growing memory file and no pruning gets more expensive every week without anything reporting it.

FAQ

Is there a separate charge for Claude's memory features?

No. Anthropic's price list has rates per million input tokens, per million output tokens and the prompt caching multiples, with no memory line. On the Claude API the memory tool is client-side, so the files sit on storage you already pay for. What memory adds is input tokens, billed at the model's normal input rate on every turn that carries them.

Does turning memory off make Claude cheaper?

It lowers the token count of each request, which lowers the cost of each request. Whether that saves money overall depends on what happens next. If Claude has to re-read three files and ask you two questions to rebuild what the memory already held, those tokens cost more than the memory did. Measure it rather than guessing: run /context in a session with auto memory on and in one started with CLAUDE_CODE_DISABLE_AUTO_MEMORY=1, then compare the total tokens spent on the same task.

Why did my usage go up when I did not change anything?

The most common cause is a cache miss after a pause. Cache entries live 5 minutes by default, or one hour on the extended setting, so the first request after a break reprocesses your entire prefix at the base input rate and writes it again. The second common cause is a prefix edit: changing a tool definition invalidates the whole cache, and changing the system prompt invalidates the system and message cache. On a subscription plan, the /usage breakdown names the behaviour when it accounts for 10 percent or more of recent usage.

Should memory live in the system prompt or behind a tool call?

Put it in the system prompt when almost every turn uses it, because it then sits in the cached prefix and costs the cache read rate. Put it behind a view call when only some tasks need it, because a file that is read once costs its tokens once instead of on every turn. The deciding number is your replay count, and the usage object gives you that number directly.

Do memory features count against subscription usage limits?

Yes, indirectly, because subscription limits are consumed by the tokens each request carries. Anthropic's help documentation states that longer conversations which trigger automatic context management consume more of your usage limit. Memory makes each request slightly longer, and a long session replays that length on every turn. How Claude's usage limits actually work covers what resets when.