Long-context coding agents have a cost problem that has nothing to do with the model’s intelligence. Every turn resends the same repository instructions, tool definitions, and reference documents, and you pay input tokens for context the model already saw. On September 18, 2026, AWS announced that Kimi K3 from Moonshot AI is available on Amazon Bedrock, and the interesting part for builders is not the parameter count.
What actually shipped
According to the AWS Machine Learning Blog, Kimi K3 is Moonshot AI’s most capable model and the first open model to reach 2.8 trillion parameters. It combines native vision with a 1-million-token context window and, per Moonshot AI, delivers roughly 2.5x better scaling efficiency than Kimi K2. AWS frames the target workload as long-running coding and knowledge work that needs sustained context across large repositories, documents, and images.
The detail worth acting on: Kimi K3 is the first open-weight model on Bedrock to support explicit prompt caching. That is a configuration surface, not a default.
Explicit caching means you draw the line
With explicit mode, you mark the exact end of a reusable prompt prefix by adding a prompt_cache_breakpoint to a supported input content block. The prefix must be at least 1,024 tokens. Tokens written to cache are billed at a higher rate, then stay cached for at least 30 minutes. Matching follow-up requests get discounted input tokens and, notably, cached input does not count against your input-tokens-per-minute quota.
That last point matters more than the discount if you are running parallel agents against the same repository. Quota pressure is often what forces you to serialize work you would rather fan out.
resp = oai_client.responses.create(
model="global.moonshotai.kimi-k3",
extra_body={"prompt_cache_options": {"mode": "explicit"}},
input=[
{
"type": "message",
"role": "system",
"content": [
{
"type": "input_text",
"text": SYSTEM_PROMPT,
"prompt_cache_breakpoint": {"mode": "explicit"},
},
],
},
],
)The practical design question is where to put the breakpoint. A long static system prompt is the obvious candidate. Multiple breakpoints let you layer a cache, so a stable prefix can sit under a semi-stable one. If you have already tuned prefix reuse for another Bedrock model, the mechanics will look familiar — our earlier post on where the 90% input savings on Bedrock prompt caching come from covers the same tradeoff of paying more to write cache in exchange for cheaper reads.
Routing and the data boundary
Kimi K3 is invoked through a cross-Region inference profile. AWS recommends the global profile, global.moonshotai.kimi-k3, for workloads without regional restrictions, and says global routing costs roughly 10% less than a geographic profile. The US geographic profile, us.moonshotai.kimi-k3, keeps processing inside the US for data residency requirements.
On the security side, AWS states that data is processed within the AWS data boundary, is not shared with the model provider, and is not used to train the underlying model. Zero data retention is always on for inference requests, and zero operator access prevents AWS operators from reading prompts and completions during inference.
Wiring it into tools you already run
Bedrock exposes Kimi K3 through the OpenAI-compatible Responses and Chat Completions APIs plus the native Invoke and Converse APIs, so existing OpenAI SDK code mostly needs a base URL and a token. AWS shows a Python example using the aws-bedrock-token-generator library to mint short-term bearer tokens.
Two integrations are called out. OpenCode has a native amazon-bedrock provider that uses the Converse API; you set the model to amazon-bedrock/global.moonshotai.kimi-k3 in opencode.json and switch with /models. Hermes Agent also supports Bedrock natively, though AWS notes a current wrinkle: if you manage multiple credentials with named profiles, you need to set the AWS_PROFILE environment variable or fall back to your default profile, with an open issue tracking config-file support.
What to check before you commit
The supplied material does not include per-token pricing, so the caching math is something you will have to run against the Bedrock pricing page. The 30-minute cache window is also a real constraint: if your agent goes quiet longer than that between turns, you pay the write premium again on the next request. Before migrating a long-running workflow, measure your actual inter-turn gaps and confirm your stable prefix clears 1,024 tokens. If it does not, explicit caching will not help you yet.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.