Moonshot AI's 2.8-Trillion-Parameter Kimi K3 Comes to Amazon Bedrock

Amazon has added Kimi K3 from Moonshot AI to Amazon Bedrock, framing the launch around the economics of open-weight models at scale. AWS describes K3 as the first open model to reach 2.8 trillion parameters, with a one-million-token context window and native vision. It is also, per AWS, the first open-weight model on Bedrock to support explicit prompt caching.

What was announced

The specification list is short but unusual. K3 carries 2.8 trillion parameters, which AWS presents as a first for an open model. It handles a one-million-token context window and includes native vision rather than a bolted-on image encoder. Moonshot AI claims roughly a 2.5x improvement in scaling efficiency over Kimi K2.

On the platform side, K3 supports tool calling, structured output, reasoning, and response streaming, and it is OpenAI-compatible through the Responses and Chat Completions APIs. AWS says it is well suited to long-running coding and knowledge workflows.

The blog does not publish benchmark scores. That absence is notable for a model announcement of this size, and it means the case for K3 rests on its specification sheet, its open weights, and the scaling efficiency figure Moonshot provides, rather than on measured task performance. Teams should treat the 2.5x scaling efficiency claim as a vendor statement about training economics, not a statement about output quality.

AWS also does not disclose the active parameter count. At 2.8 trillion total parameters, K3 is almost certainly a sparse mixture-of-experts design, since dense inference at that scale would be prohibitive, but the announcement does not state the architecture and it would be wrong to assume specifics that were not published.

The prompt caching detail is the practical story

Being the first open-weight model on Bedrock with explicit prompt caching sounds like a footnote. It is not, and it is probably the most consequential line in the post for anyone doing agentic work.

AWS gives concrete parameters: a cache breakpoint requires a minimum of 1,024 tokens, cache retention lasts at least 30 minutes, and cached tokens are billed at a premium write rate but discounted on cache hits. Critically, cached input tokens do not count against input-tokens-per-minute quotas.

That last point changes what is buildable. A coding agent working across a large repository, or a document workflow that reloads the same 200,000-token corpus on every turn, normally hits throughput ceilings long before it hits a cost ceiling. Removing cached tokens from the TPM quota lifts a constraint that is usually harder to work around than price. Combined with a one-million-token window, this is the configuration that makes whole-codebase and whole-corpus prompting tractable rather than theoretical.

The 30-minute retention floor matters for session design. Interactive agent sessions typically fit comfortably inside that window; batch jobs with long gaps between calls will not, and will pay the write premium repeatedly.

Regional availability and pricing

K3 is available through cross-region inference profiles rather than pinned regional deployments. AWS lists us.moonshotai.kimi-k3 for the US geographic profile and global.moonshotai.kimi-k3 for the global cross-region profile. The company says global cross-region inference costs approximately 10% less than a geographic profile.

That discount is a straightforward trade of data locality for cost. Organizations with residency requirements will take the geo profile and pay the premium; everyone else has a 10% saving available for changing a model ID string. Full pricing sits on the Bedrock pricing page rather than in the announcement.

Getting started runs through the Bedrock console under Test and then Playground. Programmatic access requires Python 3.10 or later and IAM permissions covering bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream, and bedrock:CallWithBearerToken.

Data handling

AWS puts unusual emphasis on the data boundary, which reads as a direct response to the reason many enterprises have avoided models from smaller or overseas labs. Processing happens within the AWS data boundary. Data is not shared with the model provider and is not used for model training. Zero data retention is always enabled, and zero operator access prevents AWS staff from accessing prompts or completions.

This is the real argument for consuming an open-weight model through Bedrock rather than self-hosting it or calling the provider's own API. Self-hosting a 2.8-trillion-parameter model is out of reach for all but a handful of organizations. Calling Moonshot's API directly raises questions that many procurement teams will not clear. A managed endpoint with contractual data guarantees is the middle path, and it is the path AWS is selling.

The trade-off is that the openness of the weights becomes largely notional for most Bedrock users. You gain the option to leave, and pricing pressure from the fact that others can host the same weights, but you are not running the model yourself.

Ecosystem fit

AWS demonstrates K3 with OpenCode, an open-source model-agnostic coding assistant, and Hermes Agent, an open-source productivity assistant. The company says K3 is compatible with any framework that supports Amazon Bedrock or OpenAI-compatible providers.

The OpenAI-compatible surface is doing the heavy lifting there. Most agent frameworks now speak that protocol, so swapping in K3 is closer to a configuration change than an integration project. That lowers the cost of evaluating it, which is the point: with no published benchmarks, the only way to know whether K3 is good for a given workload is to run it.

Open questions

The announcement leaves several things unstated. There are no benchmark results. There is no active parameter count or architecture description. There is no latency guidance, which is a meaningful gap for a model of this size operating on million-token inputs. And there is no stated position on how K3 compares on price to the proprietary frontier models already in the Bedrock catalog, though the open-weight framing implies it is meant to compete there.

For teams, the sensible approach is narrow and empirical: pick one workload where a very large context and cache reuse actually change the design, run it against both K3 and an incumbent, and compare cost per completed task rather than cost per token.

What to watch

• Whether Moonshot AI or independent evaluators publish benchmark results for K3, since AWS's announcement contains none.
• Real cost per task with prompt caching enabled, given that cached tokens carry a write premium but bypass input-TPM quotas.
• Whether AWS extends explicit prompt caching to other open-weight models on Bedrock, now that K3 has established the pattern.
• Latency behavior on prompts approaching the one-million-token limit, which the announcement does not address.
• How the 10% global-profile discount holds up against data residency requirements in regulated sectors.