AWS AgentCore Runtime V2: snapshot cold starts and memory you give back

AWS shipped a new version of AgentCore Runtime on September 18, 2026. It changes two things about running agents on AWS. New sessions start by restoring a snapshot of an agent that has already finished starting up, so cold starts stay around two seconds whatever the container size. And memory the agent stops using is taken back during the session, so the bill follows what the agent uses instead of its peak.

You opt in per runtime by setting `platformVersion` to `V2`. V1 stays the default. The switch is one field, but the snapshot changes how your agent code has to be written, and that is the part most teams will trip on.

Sources for this post are the AWS Machine Learning blog post The new AgentCore runtime: Elastic, optimized, and consistently fast starts, the What's New announcement, the developer guide pages on how the runtime works and platform versions and optimizing your agent for V2, and the AgentCore pricing page, all checked October 9, 2026.

Move an agent to V2 when people wait on it to start, when its container image is large, or when it runs for a long time with bursts of memory use. Before you switch, move anything that must be unique or fresh out of startup code and into the request handler: random values, tokens, credentials, timestamps, instance IDs, and anything you might change without redeploying, such as a tool list from a gateway. Then load test it in your own account. V2 is in five AWS Regions, CloudFormation and the CDK cannot set it yet, and environment variables have a smaller size limit than on V1.

AgentCore Runtime is the managed compute layer inside Amazon Bedrock AgentCore. You hand it a container or a code bundle, and each user session runs in its own microVM with separate CPU, memory, and filesystem. There is nothing to provision, idle runtimes scale to zero, and a session can last up to 8 hours. When a session ends, the microVM is shut down and its memory is cleared.

AWS names two problems with the first version once agents run longer:

• Memory was billed at the peak. A session kept every bit of memory it had allocated until it ended. An agent that spiked once and then sat idle kept paying for the spike.
• Start time varied. A session that lands on an already-running environment starts in under 100 milliseconds, but most sessions start cold: boot a fresh environment, pull the image, and run the agent's startup code. That got slower as images grew and as more sessions started at once, which is exactly when a burst of users arrives.

AWS says customers worked around this by keeping spare environments warm and tuning memory by hand, and paying for that reserve capacity whether or not it did any work.

The blog lists four changes:

1. 1Memory on demand. A session starts with a small amount of memory and gets more as the agent touches it. When the agent releases memory, for example per-request buffers or cached data that expires, the runtime takes it back instead of holding it until the session ends.
2. 2Start once, then snapshot. When you create or update a V2 runtime, AgentCore starts your container, waits for it to report healthy, and snapshots the running environment. Every new instance restores that snapshot. Imports, model files, and static config loaded at startup are already in memory.
3. 3A small, steady snapshot. AWS strips caches and short-lived memory out of the snapshot so it holds only what an instance needs to resume. That is why restore time stays flat as the image grows.
4. 4A higher rate on fewer GB-hours. V2 bills for the memory the agent uses, not for holding the whole image in memory all session. The per-unit price is higher.

AWS tested an empty echo agent that calls no model and no tools, so the timing shows only the runtime's own start path. A Python client on EC2 in us-west-2 called agents in us-east-1 over the public internet with `boto3`. AWS sent 5,000 cold invocations per agent across both versions and five image sizes.

• V2 had a P75 cold start of about 2 seconds (1.9 to 2.0 seconds in the announcement) for every image size from 200 MB to 2 GB.
• V1 went from about 5.4 seconds to nearly 30 seconds as the image grew.
• The echo agent's own code ran in about 34 milliseconds at P75.

These are client-side numbers that include the round trip between two Regions. They are also AWS's numbers on a toy agent. In a real agent most of the wait comes from the agent loop and its model calls. AWS's tip for chat apps is to start the session when the user opens the chat, before they type, so the start is done by the time they send the first message.

This is the part that can break an agent without any error. Your agent now has two phases. Startup code runs once, before the snapshot, and every restored instance gets a copy of its results. The request handler runs on every request on every instance. AWS takes one snapshot per runtime version and keeps it until you update the runtime.

AWS's rule: compute a value at startup only if it stays the same for the life of that version. Compute it in the handler if it changes per request or can expire.

Do at startup:

• Import dependencies, load model weights, and read static config from the bundle.
• Build your SDK clients and make one warm-up call, so endpoint and credential lookup and the connection pool setup are saved in the snapshot. The open socket does not survive a restore, so the first call after a restore reconnects on its own.
• Finish within 120 seconds. AgentCore takes the snapshot on the first healthy `/ping`. If the agent is not healthy in 120 seconds, creation fails. With the AgentCore SDK, do this work at module level before `app.run()`. If you run your own HTTP server, return healthy from `/ping` only after startup finishes.

Do in the request handler:

• Random values, IDs, and tokens. A value made at startup is copied into the snapshot and is the same on every instance. Python's `random` module is seeded at startup too, so restored instances repeat the same sequence.
• Secrets and keys. AWS's docs say snapshot-safe builds of crypto libraries do not currently reseed after a restore on AgentCore Runtime. AWS says to get random bytes straight from the operating system (`secrets` or `os.urandom` in Python, `crypto/rand` in Go, or `/dev/urandom`). Random values from a library such as OpenSSL can repeat across instances.
• The current time and elapsed time. A startup timestamp is frozen at snapshot time, and `time.monotonic()` does not move forward across a restore, so durations measured from a startup reference come out wrong.
• Credentials. Anything loaded at startup can expire before an instance is restored. Refresh it when it expires.
• Instance IDs. Every restored instance reports the hostname `localhost` and PID 1. If you build log streams, metrics, or lock owners from either, the whole fleet looks like one machine.

Two more from the docs. Do not bind a fixed source port, because the reconnect after a restore can collide with it. And do not load anything at startup that you might change without redeploying. AWS's own example is a tool list fetched from AgentCore Gateway: it is slow to load, so it looks like a good startup value, but caching it there freezes the agent's tools at snapshot time. If you use the hub pattern from our post on AgentCore Gateway as a multi-account MCP hub, a new team's tools would not show up until you redeploy the agent.

• Create and update take minutes. V1 reaches `READY` in seconds. V2 runs for several minutes while it builds the snapshot.
• Poll for a final status. Create and update return while the runtime is still `CREATING` or `UPDATING`. Calling update or delete before it finishes returns `ConflictException`, so poll `get_agent_runtime` until it is `READY` or `FAILED`.
• Smaller environment variables. V2 allows 1.5 KB of environment variables in total for direct code deployments and 2.5 KB for containers, against 4 KB on V1. Larger configs fail with `ValidationException`. AWS says it will raise the limit to match V1.
• Snapshots follow endpoints. AgentCore keeps one snapshot for each version an endpoint points to, so a runtime with dev and prod endpoints on different versions has two. After an update, the old snapshot is deleted once existing sessions end, which can take up to 8 hours.
• No infrastructure as code yet. CloudFormation and the AWS CDK cannot set `platformVersion` today. You set it in the console, the CLI (`--platform-version V2`), or the SDK. If your runtimes are managed by CloudFormation or CDK, plan how you will keep that setting from drifting.
• Regions. V2 is available in us-east-1, us-east-2, us-west-2, eu-west-1, and ap-northeast-1.

When we checked the pricing page on October 9, 2026, Runtime V1 was listed at $0.0895 per vCPU-hour and $0.00945 per GB-hour. V2 consumption pricing was listed at $0.1276 per vCPU-hour and $0.0169 per GB-hour. So V2 costs more per unit. AWS's claim is that for most agents the drop in GB-hours is larger than the rise in rate, so the bill goes down. Whether that holds for your agent depends on how much of its peak memory it gives back. An agent that holds steady memory all session may not save anything.

The pricing page also lists a committed baseline price for V2 ($0.0997 per vCPU-hour and $0.0132 per GB-hour) as launching by October 2026. The blog describes it as a memory floor you reserve per session, with bursts above it billed on demand, for steady always-on agents. AWS lists more on the way: more RAM, vCPU, and storage, x86 microVMs, suspend and resume with memory snapshots, hooks to save state before a session ends, and a scoped identity per session for unattended agents. AWS labels all of these as coming soon.

AWS's material does not mention OpenClaw, Hermes, or Grok Bot, and this post does not claim any of them run on AgentCore Runtime.

The tradeoff is still useful if you are choosing where an agent runs. With a self-hosted agent such as OpenClaw or Hermes, you keep a machine running, you pay for it whether the agent is busy or not, and you decide what it can reach. See trust boundaries for self-hosted AI agents and the self-hosted AI agent deployment checklist. Cursor Self-Hosted Machines is another mix: the agent loop runs in the cloud and the work runs on machines in your network. AgentCore Runtime is fully managed: a fresh, isolated microVM per session, scale to zero, and nothing kept warm on your side. V2 removes much of that model's start-time penalty and moves cost closer to actual use. In exchange your code has to follow the snapshot rules above, and each session lasts at most 8 hours.

A rough guide:

1. 1Confirm your Region is one of the five that support V2.
2. 2Measure your environment variables against the 1.5 KB or 2.5 KB limit.
3. 3Search startup code for random values, UUIDs, tokens, keys, timestamps, `time.monotonic()` references, hostname or PID use, and cached credentials. Move them into the handler.
4. 4Generate secrets with the operating system's random source in the handler.
5. 5Do not cache tool lists or other config you change without redeploying.
6. 6Build clients at startup and make one warm-up call. Expect a reconnect after restore.
7. 7Make sure startup finishes and `/ping` turns healthy within 120 seconds.
8. 8Update deploy scripts to wait for `READY` or `FAILED` and to allow several minutes.
9. 9Run AWS's load test example (linked from the launch post) or your own against a copy of the agent, and compare cold starts and memory cost with V1.
10. 10Keep your own tests for agent behavior. A faster start does not change what the agent does. See testing AI agents before production.

OrchestriAI does not run AWS accounts for this. AI agent systems covers which tools an agent may call, where a person approves, and how it behaves when a run restarts. Systems integration covers credentials, tokens, and logging between the agent and the systems it touches. MCP development builds the tool servers an agent reaches through a gateway.

OrchestriAI is an independent implementation provider. Product names are used for identification only. OrchestriAI is not affiliated with, endorsed by, or sponsored by Amazon Web Services, OpenClaw, Nous Research / Hermes, or Cursor. This article summarizes the AWS Machine Learning blog post The new AgentCore runtime: Elastic, optimized, and consistently fast starts (September 18, 2026), the matching What's New post, the AgentCore developer guide pages on platform versions and V2 optimization, and the AgentCore pricing page, as checked on October 9, 2026. Performance figures are AWS's own test results. Prices, Regions, limits, and roadmap items can change, so confirm current AWS documentation before you size a rollout.