Pricing AI memory by tokens is wrong once agents reuse context — one study found 83% of token spend was just re-reads.

This explores how to actually price a memory system once it's running in production, and the corpus's most useful move is to challenge the obvious answer — counting tokens. A 115-day case study found that 82.9% of tokens were cache reads, which means when context persists and gets reused, dividing spend by tokens massively overstates cost; the honest denominator becomes completed artifacts, not individual tokens Do persistent agents really cost less per token?. So the first measurement question isn't 'how much per token' but 'what's the meaningful unit of work' — and for persistent agents that unit shifts underneath you.

The second trap is assuming memory cost is a storage cost. Research on long context argues the real bottleneck isn't holding the data but the compute to consolidate evicted context into fast internal weights — an offline 'sleep' phase whose cost scales with how many consolidation passes you run Is long-context bottleneck really about memory or compute?. That reframes operational cost as a compute line item that grows with task difficulty, not a fixed memory footprint. The same theme shows up at the hardware level: on memory-bound devices, recomputing a block twice can be cheaper than moving weights, so 'cost' depends entirely on whether you're bottlenecked on movement or on FLOPs Does recomputing weights cost less than moving them on mobile?.

If you want a cost number that actually tells you where to intervene, the corpus points hard at module-level accounting. Decomposing memory into storage, extraction, retrieval, and maintenance stages exposes which component is burning resources rather than just reporting whether the task succeeded — end-to-end scoring hides all of that How should we actually evaluate agent memory systems?. Operational cost measured per-module is what lets you see, say, that maintenance is expensive while retrieval is cheap.

Retrieval strategy is itself a cost lever, not a fixed price. Reconstructing memory on demand through active graph traversal — pruning paths as evidence accumulates — cut both token and runtime cost versus a fixed retrieve-then-reason pipeline while improving accuracy Can agents reconstruct memory on demand instead of retrieving it?. So any cost metric should be measured against the retrieval architecture, because the same stored memory can cost very differently to use. And cost isn't only compute: multi-turn agents degrade when memory lacks gating, accumulating errors and constraint drift — a schema-governed committed state prevents that Can agents fail from weak memory control rather than missing knowledge?. The failure-rate that weak memory control produces is an operational cost too, just one that shows up as rework rather than a bill.

The thread across all of these: don't measure memory cost with a single number. Measure it as cost-per-artifact instead of per-token, count the consolidation compute that storage metrics hide, break it down per module to find the real spender, and price it against your retrieval and gating design rather than in isolation. What you didn't know you wanted to know is that memory architecture has quietly become the primary scaling dimension — returns from restructuring memory now exceed returns from adding parameters — which means these cost measurements aren't bookkeeping, they're where the leverage moved Has memory architecture replaced parameter count as the scaling frontier?.