On October 2, my AWS account received a Health notice. Amazon Bedrock AgentCore short-term memory was changing its pricing. The old rate was a flat $0.25 per 1,000 new events, and reads were included. Starting October 6, 2026, it bills three things separately:

DimensionNew priceHow size is counted
Ingestion$1.00 per GBEach event clamped to 12 KB min, 64 KB max
Retrieval$0.20 per GBEach event clamped to 12 KB min, 64 KB max
Storage$0.10 per GB-monthActual size, prorated hourly over the event’s TTL

AWS says more than 95% of customers will pay less, and names the exceptions: large payloads, extended TTL, and frequent retrieval. Credits cover any increase through December 31, 2026.

“Frequent retrieval” was the part I could not size from the notice. My first draft of this post answered it with turn counts: reload the full history every turn and you pass the old price at turn 30 with 64 KB events. That was true in my model and mostly useless. At turn 30 that history would be about 1.5 million tokens, above the 1M-token context window used in this comparison.

So this version asks the question that matters for a design: next to what the agent already spends on tokens, when does the new memory price change anything?

Short answer

  • Each event has a re-read budget. A 12 KB-or-smaller event can be read back about 99 times, and a 64 KB event about 14 times, before it costs more than the old $0.00025 flat fee.
  • Full-history reads often hit the context limit first. In the 30-day-TTL full-history cases, most crossovers needed a history over the modeled 1M-token context window. But 1 KB events crossed after about 200 turns while the history still fit. Context overflow is not the only way the new price can exceed the old one.
  • Next to tokens, memory is small. For 50-turn sessions sent to Claude Sonnet 5.5 at the full input price, memory was 0.01% to 0.62% of memory plus history tokens in every setup I modeled.
  • It is not small for tiny events on cheap tokens. With 1 KB messages, Claude Haiku 5.5, and cache reads, memory reached 42% of that total. The 12 KB minimum bills a 1 KB message as 12 KB, and the tokens do not. Even there, the new price was below the old one.
  • Long storage can cost more without reads. In the model, 10 million 256 KB events a month, kept for 365 days and never read, cost $3,712 instead of $2,500, about 48% more than the old flat fee. That is a size-and-TTL bound, not a measured workload; I did not verify the service’s maximum event size.

This is a cost model, not a bill. I made no AWS or model calls. The code and raw output are in yopa-experiments (commit fb7ffcd).

The re-read budget

The old price charged per write. The new one charges per byte written, per byte read, and per hour kept. For one event, the break-even is simple arithmetic:

Event sizeWrite (new)Each read (new)Reads before it passes $0.00025
1 KB or 12 KB$0.000012$0.0000024about 99
64 KB or more$0.000064$0.0000128about 14

That budget is the number to carry around. An agent that reloads the whole session every turn reads the event written on turn 1 once on every later turn. That is where the old turn counts came from: an event at the start of a session runs out its 99 reads around turn 100, and the session average passes the old price around turn 200.

Two assumptions sit under this, and both are mine:

  • Retrieval is billed per event returned, with the 12 KB minimum. The pricing page applies the clamp “per event” to retrieval. I did not confirm how list and pagination calls are metered. If the minimum does not apply to reads, small events get a much larger budget.
  • One read per turn. My model reads the session once per turn. An agent that lists history before every model call inside a turn (tool loops) spends the budget faster.

As a sanity check, the model reproduces the AWS pricing example: $1.20 ingestion, $0.24 retrieval, and $0.0296 storage against AWS’s $0.03 (hourly proration over a 730-hour month, decimal units).

What the SDK actually reads

Whether your agent reloads every turn is not a guess. It is in the code. I read the Strands integration that ships in the AgentCore SDK:

  • The session manager’s list_messages asks for MAX_FETCH_ALL_RESULTS = 10000 events when no limit is given (session_manager.py L49, L783). There is no default window.
  • Strands calls it without a limit when an agent is initialized, and restores the whole list into agent.messages (repository_session_manager.py L274-L292). After that, new messages are only written, not read back (L97).

So the read pattern depends on one line in your handler. If you build a new Agent per request, you read the whole session every turn. If the agent object lives for the session, you read it once per session. Same library, same feature, very different retrieval line.

One more detail from the same code: batch_size defaults to 1, which writes one event per message (config.py L94). Every short message is billed as 12 KB. Setting it higher combines buffered messages into one create_event call, which is the lever against the minimum.

Memory next to the tokens of the same history

The reload has two bills: memory charges to read the history, and the model charges to take it as input. I modeled 50-turn sessions with 2 events per turn and a 30-day TTL, at 100,000 sessions a month. Token rates are from the Bedrock pricing page on October 9 (Global cross-region, US East selected): Claude Sonnet 5.5 at $2.00 per million input tokens, and Claude Haiku 5.5 at $0.10. I used 2.5 bytes per token, from Anthropic’s models overview. I ignored output tokens and the system prompt, so the token side is a floor and the memory share is a ceiling.

Fresh agent per request, full history every turn:

Event sizeMemory, newMemory, oldHistory tokens, Sonnet 5.5History tokens, Haiku 5.5Largest call
1 KB$709/mo$2,500/mo$196,000/mo$9,800/mo39K tokens
12 KB$720/mo$2,500/mo$2.35M/mo$117,600/mo470K tokens
64 KB$3,839/mo$2,500/mo(over context)(over context)2.5M tokens

In this 50-turn table, the only row where memory costs more than before exceeds the 1M-token context window used in the comparison. At 12 KB, the memory line went from $2,500 to $720 a month while the tokens for the same history were $2.35 million with Sonnet 5.5. For that modeled session, the history-token bill is the larger cost to address.

Where memory does show up is the other end. With 1 KB messages on Haiku 5.5, memory was 6.75% of the total at the full input price, and 42% if every history token were a cache read ($0.01 per million). A last-10 window does the same thing: it cuts the tokens more than it cuts the memory reads, so memory’s share goes up while the total goes down. In all of those cases the new memory price was still under a third of the old one.

Storage is the one that does not need reads

Here the agent only writes events and never reads them back. I used the same workload as the table above: 100,000 sessions × 50 turns × 2 events = 10 million events a month. At the old $0.25 per 1,000 events, that month cost $2,500, however long the events were kept.

Under the new price, each month’s events pay two things: a one-time write charge (size clamped to 12–64 KB, at $1.00 per GB) and storage for every hour they are kept (actual size, at $0.10 per GB-month, with a 730-hour month). Worked through for the biggest case, 256 KB kept 365 days:

  • Write: 256 KB is billed as 64 KB. 10,000,000 × 64 KB = 640 GB, × $1.00 = $640.
  • Storage: 10,000,000 × 256 KB = 2,560 GB. 365 days is 8,760 hours, or 12 billing months. 2,560 GB × $0.10 × 12 = $3,072.
  • Total: $640 + $3,072 = $3,712, against $2,500 before.
One month’s 10 million eventsKept 30 daysKept 365 days
12 KB each$132 ($120 write + $12 storage): 95% cheaper$264 ($120 + $144): 89% cheaper
64 KB each$703 ($640 + $63): 72% cheaper$1,408 ($640 + $768): 44% cheaper
256 KB each$892 ($640 + $252): 64% cheaper$3,712 ($640 + $3,072): about 48% more expensive

Takeaway: without reads, the new price only loses to the old $2,500 when events are both large and kept for a long time. In this grid, that is the single 256 KB, 365-day cell.1

Storage bills actual size, not the 64 KB cap. A 256 KB event kept for a year costs about 1.5 times the old flat fee ($0.000371 against $0.00025 per event), read or not, and the TTL cannot be changed after the event is written. I did not check the maximum event size, so treat the 256 KB row as a bound, not a common case. The SDK sends messages of 100,000 characters or more as blob events, so large payloads are not hypothetical. In AgentCore Memory events, strategies, and isolation I said to define an event expiry for privacy reasons. That choice now has a price too.

Limits

  • Model, not invoice. Published rates and my assumptions, not a Cost Explorer line. I did not measure real event sizes, because reading them would itself make billed calls.
  • Token side is a floor. No output tokens, system prompt, or tool definitions, so real memory share is lower than shown.
  • Not modeled: long-term memory, the storage exemption for events created before October 6, and the credits.

What to do

  1. Check how your handler builds the agent. A new Agent per request means a full-history read per turn. That is the pattern that spends the re-read budget.
  2. Fix the tokens first. If you reload full history, the model input is the bill, not memory. The sliding window and summarization advice in Tokenomics on AWS cuts both lines at once.
  3. If your messages are tiny, batch them. A batch_size above 1 stops paying the 12 KB minimum on every short message.
  4. Keep large payloads out of short-term events, especially with a long TTL. Store them in S3 and write a reference.
  5. Look at the AgentCore Memory usage types in Cost Explorer before December 31, when the credits stop hiding any increase.

For the rest of an always-on agent’s bill, where the infrastructure around the model can matter as much as the model, see How much does it cost to run Hermes Agent on AWS?

References

  1. As new cost divided by old, the six cells are 0.05 and 0.11 (12 KB), 0.28 and 0.56 (64 KB), and 0.36 and 1.49 (256 KB), for 30 and 365 days. Those are the ratios the experiment’s model.py prints. Dollar amounts are rounded to the nearest dollar. ↩︎