If you run agents in production, two numbers probably keep you up: how long a new session takes to become ready, and how much memory you pay for while it sits idle. AWS says the new AgentCore runtime, announced on September 18, 2026, targets both.
The short version: instead of booting and initializing a fresh environment on every cold start, the runtime prepares the environment once, snapshots it, and restores that snapshot for each new instance. Memory is paged in on demand and reclaimed when it goes cold, rather than held at the session’s peak until the session ends.
What the old model cost you
AgentCore runtime is the managed compute layer for deploying agents without maintaining infrastructure. The original version was serverless, session-isolated, scaled to zero, and billed by consumption. The problem showed up as agents moved from short chat exchanges to long-running, event-triggered work.
Two gaps stand out in AWS’s description. First, a session held memory from the moment it was allocated until the session ended, so a bursty agent paid for its high-water mark around the clock. Second, cold starts varied: a session landing on an already-initialized environment started in under 100 milliseconds, but keeping environments that warm means reserving compute. Most sessions therefore booted a fresh environment, and that penalty grew with image size and concurrency — worst under exactly the bursty traffic where most sessions arrive.
AWS notes that teams often built their own workarounds: spare hot environments, manual memory tuning, teardown logic to control the bill. That is undifferentiated work, and it still breaks when a burst outruns the reserve.
The measured cold-start numbers
AWS ran 5,000 cold invocations per agent across both runtime versions and five image sizes, using an empty echo agent that calls no model and no tools, so the timing reflects the platform’s start path rather than application work. A Python client on EC2 in us-west-2 called agents in us-east-1 over the public internet with no VPC peering, using the boto3 SDK. These are client-side numbers, so each includes the cross-region round trip on top of platform start time.
Measured that way, the new runtime held a P75 cold start of about 2 seconds from a 200 MB image up to 2 GB — image size had no effect. The original runtime rose from roughly 5.4 seconds to nearly 30 seconds across the same range. In the echo test, the agent’s own code ran about 34 milliseconds at P75, so nearly all of that time is platform start.
One practical tip AWS offers for interactive agents: open the session as soon as the user engages — when they open the chat, before they type — so the environment warms while they read and type.
How the snapshot changes the billing shape
The mechanism is worth understanding because it changes what you optimize. The runtime launches your container, waits for it to report healthy, then captures a snapshot of the running environment. One-time initialization — loading model artifacts, fetching static config — is already baked in. New instances restore that snapshot instead of initializing from scratch.
AWS also strips caches and transient memory from the snapshot, so its size stays roughly flat as the container image grows. That is what keeps restore latency steady across image sizes.
On cost, the tradeoff is explicit: the new runtime charges a higher rate but on far fewer GB-hours, because you pay for memory the agent actually uses rather than holding the whole container image in memory for the session. AWS says that for most agents the footprint drops more than the rate rises, so the bill goes down. That is a claim about typical workloads, not a guarantee for yours — a steady, memory-hungry agent may land differently, and the supplied material does not include per-agent pricing math.
If you are still deciding whether a managed runtime is the right call at all, the earlier post on what changes when you stop owning the agent container covers that tradeoff directly.
What to check before you migrate
Two things are worth verifying against your own workload. First, whether your agent’s initialization is genuinely one-time — anything that must run per session, like a fresh credential fetch or a per-tenant config load, needs to happen after restore, not before the snapshot. Second, whether your memory profile is bursty or flat. The reclaim behavior rewards agents that spike and go quiet; it does less for agents that hold a large working set continuously.
AWS also says more capabilities are coming around pricing, compute, and compatibility, but the supplied material cuts off before naming them, so treat that as an open item rather than a roadmap. The concrete change today is narrower and more useful: cold starts no longer scale with your image, and your memory bill follows usage instead of your peak.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.