Amazon Bedrock added Kimi K3, and its agent runtime now starts in about two seconds

Amazon Bedrock published two changes on September 18, 2026, and they answer different questions. The first is which model you can call: Kimi K3 from Moonshot AI is now generally available, with a context window of 1 million tokens and native vision. The second is what your own agent runs inside: the next generation of AgentCore Runtime changes how memory is billed and how long a cold start takes.

What Kimi K3 brings, and who is claiming what

AWS states the availability and the platform behavior; the specifications of the model itself come from its maker. According to Moonshot AI, Kimi K3 is its most capable model and the first open model to reach 2.8 trillion parameters, with an improvement in scaling efficiency of approximately 2.5 times over Kimi K2. AWS adds that it combines native vision with a context window of 1 million tokens, and that is the part that changes the work: a large code repository or a stack of scanned pages fits into a single call.

The platform claim is AWS's own and is narrower: Kimi K3 is the first open-weight model on Amazon Bedrock to support explicit prompt caching. Bedrock also says your data is processed inside the AWS data boundary, is not shared with the model provider and is not used to train the model, that zero data retention is always enabled for inference requests, and that operators have no access during inference.

Prompt caching is where the cost changes

Explicit caching does not switch itself on. You mark the end of a reusable prompt prefix with a prompt_cache_breakpoint, after at least 1,024 tokens, and later requests that match that prefix reuse the stored content. Tokens written to the cache are billed at a higher rate, they stay cached for at least 30 minutes, and matching requests are billed at a discounted input rate.

There is a second lever, and it has nothing to do with caching. Kimi K3 is invoked through a cross-Region inference profile, and AWS says the global profile global.moonshotai.kimi-k3 costs approximately 10% less than a geographic one. The profile us.moonshotai.kimi-k3 keeps processing inside the United States for anyone bound by data residency rules. Availability is described as every AWS Region where Bedrock exists, through cross-Region inferencing.

AgentCore Runtime changed what you pay for and how long you wait

The second announcement replaces the serverless microVM compute that agents run inside on Amazon Bedrock. Each session now starts with a small memory profile, takes more on demand, and hands back memory that is no longer in use instead of holding it until the session ends. AWS puts it without hedging: you pay for actual usage rather than the peak.

Cold starts were rebuilt around a snapshot. The runtime prepares the agent environment once, snapshots it, and every new instance restores from that snapshot instead of repeating the startup sequence. In AWS's own testing that produced a P75 cold start of 1.9 to 2.0 seconds for container images from 200 MB to 2 GB, against 5.4 to 30 seconds on V1. The spread was the problem in itself, because a larger image meant a slower start.

• The new runtime is available in us-east-1, us-east-2, us-west-2, eu-west-1 and ap-northeast-1.
• It is switched on by hand: set platformVersion to V2 when creating or updating a runtime.
• Nothing else changes. There is no pre-provisioning, scaling still goes to zero, and session isolation is still enforced in hardware.

What this changes when you choose where to run an agent

Neither announcement is an independent measurement and neither should be read as one. The Kimi K3 figures are the description Moonshot AI gives of its own model, which AWS passes on. The cold-start figures are AWS measuring its own service against its own previous version. Both are still worth having, because these are the numbers the bill is calculated from rather than points on a leaderboard.

This suggests the interesting part is neither the model nor the runtime on its own, but that the two arrived on the same day. A context of 1 million tokens is expensive to resend on every call, and explicit caching and a runtime that releases idle memory are the two places where that cost comes down. One possible explanation for the timing is exactly that: long-context agents are the workload both changes were built for.