AWS rebuilds the AgentCore runtime: memory on demand, snapshot starts and a bill that follows the work

AWS has rebuilt the compute layer that keeps production AI agents running, and the changes go straight at the two things that hurt most at scale: what memory costs and how long a start takes. The new AgentCore runtime, announced on 18 September, pages memory in on demand, reclaims it when it goes cold and starts sessions from snapshots, with the company's own tests showing cold starts of about two seconds whether the container image weighs 200 MB or 2 GB. The pitch, in AWS's words, is a serverless model that bends to the workload instead of forcing the workload to bend to it. For anyone running agents that spike, idle and resume, that is the difference between paying for a session's peak all day and paying for what it actually uses.

AWS AI Watch analysis

What happened

AgentCore runtime is the managed compute layer of Amazon Bedrock AgentCore, the part that runs agents without developers maintaining infrastructure. AWS says thousands of teams have run production agents on it since launch, and frames the rebuild around how those agents have changed: from question-and-answer bots to coding agents that run for hours, to ambient, always-on agents triggered by events and increasingly launched by other agents.

Memory comes first. Sessions now start from a small resident footprint, page in more memory as the workload touches it, and hand memory back when it goes cold, rather than holding everything allocated until the session ends. The bill follows those changes across the session's lifetime instead of tracking the high watermark.

Starts come second. The runtime prepares an environment once, snapshots it, and restores that snapshot for each new instance, with caches and transient memory stripped so the snapshot stays roughly flat as images grow. In AWS's measurements, an empty echo agent called 5,000 times per version across five image sizes, from a client in one AWS region to agents in another over the public internet, started in about 2 seconds at P75 on the new runtime, against roughly 5.4 seconds to nearly 30 seconds on the original. Those are client-side figures that include the cross-region round trip, and the echo agent's own code ran in about 34 milliseconds, so nearly all of the wait is platform start time.

Billing changes shape too: a higher memory rate applied to far fewer GB-hours, which AWS says leaves most bills lower.

Our top picks

• Memory on demand
  Sessions start small, page in what the workload touches, and the runtime reclaims memory when it goes cold instead of holding it until the end.
• Snapshot-based starts
  The environment is prepared once and restored per instance, so one-off work such as loading model artefacts is paid once.
• Flat cold starts
  About 2 seconds at P75 from a 200 MB image to 2 GB in AWS's tests; the original ranged from roughly 5.4 to nearly 30 seconds.
• Usage-shaped billing
  A higher memory rate on far fewer GB-hours; AWS says the footprint drops more than the rate rises for most agents.
• Baseline pricing, coming soon
  Reserve a memory floor and burst above it, aimed at steady, always-active sessions that want predictable cost.
• x86 support, coming soon
  Existing x86 agents, tools and environments run as-is on x86 microVMs.
• Suspend and resume, coming soon
  Sessions paused and resumed with memory snapshotting, for greater lifecycle control.

Why it matters

The economics change which agents you can afford to run. Peak-billed memory punishes exactly the agents everyone says are coming: the spiky, event-triggered kind that sit idle most of the day and burst when something happens. Billing for real usage makes it cheap to keep many agents idle, which is a quiet but real shift in what an agent fleet costs.

Consistency matters as much as speed. A cold start is what a person feels when an agent paused for input needs to wake up, and a start that stays near two seconds whether the image is small or large removes the guesswork. AWS also passes on a practical trick: begin the session the moment a user opens the chat, before they type, so the environment warms while they read and type, and the start is mostly hidden by the time they hit send.

Our read

The design changes are the substance; the numbers are the illustration. AWS measured an empty agent precisely so the test isolates the platform rather than the workload, which is the honest way to do it, but your agent is not an echo agent. Treat the two-second figure as a property of the platform, not a promise about your latency, and treat 'most bills go down' as a claim with a measurable word doing the heavy lifting.

If you run spiky or long-lived agents on AgentCore, this is worth testing now. If your agents are steady and always busy, the baseline pricing on the roadmap is the part worth waiting for.

What to watch

• Baseline pricing
  The reserved memory floor option, and how its rates compare with consumption billing in practice.
• x86 microVMs
  When they land, and whether migration is as frictionless as 'as-is' suggests.
• Suspend and resume
  Whether snapshot-based pause and resume holds up for long-running sessions.
• Real-world bills
  What teams report once the new runtime meets production workloads.

Discussion spark: Peak billing punished idle agents and usage billing rewards them. Does cheap idleness make always-on agent fleets genuinely sensible, or just easier to over-provision?

not affiliated with or endorsed by Amazon Web Services (AWS)