The South China Morning Post reports that Moonshot revised K3’s licence in July to require a paid arrangement when a company or its affiliates hosts the model as a service and generates more than US$20 million in aggregate annual revenue. That makes Amazon’s adoption an important commercial test, although availability alone does not establish a payment or revenue-sharing agreement.
For enterprise buyers, those commercial questions sit alongside a more immediate decision: whether K3’s long-context and visual capabilities justify adding another model to an application. AWS’s documentation provides enough detail to make that evaluation specific—and shows why changing a model identifier is only part of the work.
Kimi K3 gives Bedrock customers a new long-context option
AWS describes Kimi K3 as a model for coding and knowledge work, combining native vision with a one-million-token context window. A context window is the amount of material a model can work with in a request, measured in tokens rather than documents or pages. Here, AWS identifies large code repositories, multi-document analysis, scanned pages, screenshots and extended agent workflows as intended uses.
The change on September 18 was K3’s general availability through Bedrock, not the model’s original release. The South China Morning Post places that earlier release in July. Keeping those dates separate matters: this announcement establishes a new managed distribution channel, rather than evidence of a newly trained model arriving for the first time.
For teams already using Bedrock, that channel puts K3 within an existing service boundary. AWS says it runs with the same access, encryption and auditing controls used for proprietary models on the platform. That can reduce the operational work associated with evaluating a model compared with operating its infrastructure directly, although it does not establish that every model has identical contractual terms or application behavior.
The headline size figures deserve restraint. AWS attributes to Moonshot the description of K3 as a 2.8-trillion-parameter model and an approximately 2.5-times improvement in scaling efficiency over Kimi K2. These are vendor claims, not independently reproduced measurements of application quality, response speed or cost. “Scaling efficiency” should not be read as a promise that an existing coding assistant will become 2.5 times faster.
The useful evaluation target is therefore narrower than “a bigger model.” K3 is worth considering where an application actually needs substantial repository context, multiple documents or visual inputs. A large context window establishes capacity; it does not, by itself, prove that the model will find the right evidence or produce a correct code change.
Moonshot’s reported licence makes distribution a revenue test
The commercial issue is the separation between making model weights available and allowing every form of commercial hosting without payment. Open-weight describes access to the model’s weights; it should not be treated as a guarantee that every deployment is commercially unrestricted.
According to the South China Morning Post, Moonshot’s July licence revision creates a paid-arrangement requirement for qualifying hosted services above the reported US$20 million aggregate annual revenue threshold. The newspaper connects that provision with its report that AWS’s AI business exceeded a US$25 billion annual revenue run rate in July.
Those figures explain the newspaper’s interest, but they do not settle the contractual result. An annual revenue run rate is not the same measure as revenue earned over a completed year, and a company-wide business figure does not tell readers exactly how a licence defines qualifying revenue. The full licence wording and the AWS–Moonshot agreement would be necessary to establish how the provision applies here.
No payment amount or revenue-sharing arrangement has been publicly disclosed in the reporting available for this launch. The specific licence threshold and AWS revenue figure rest on the South China Morning Post’s reporting; the AWS launch announcement confirms neither. It would therefore be premature to describe Bedrock availability as proof that Moonshot has already collected licensing income from Amazon.
The earlier commercial discussions offer context, not a substitute for those missing terms. Tech Wire Asia, citing Reuters, reported that Moonshot had been negotiating with Microsoft, Amazon and Google and seeking as much as a 30 percent share of revenue from K3-related services. That is a secondhand account of a negotiating position, not evidence of the percentage Amazon ultimately agreed to pay.
For customers, the distinction is equally important. Purchasing inference through Bedrock and operating a separate hosted model service are different activities. The reported threshold should not be converted into a blanket claim that every business using K3 owes Moonshot a separate fee—or that every business below the threshold has unrestricted rights. Companies planning their own hosting or resale offering need the actual contractual terms before making that decision.
Bedrock’s K3 geography choice changes both routing and price
AWS documents two cross-Region inference profiles for Kimi K3. Cross-Region inference means that the Region receiving a request need not be the Region that processes it. The profile selected by the application determines the permitted routing scope.
The US geographic profile, us.moonshotai.kimi-k3, routes requests only among US-geography Regions. The Global profile, global.moonshotai.kimi-k3, may route requests to any supported commercial AWS Region worldwide. Selecting a US endpoint is not a substitute for selecting the appropriate routing profile.
AWS says K3 is available through cross-Region inference in all Regions where Bedrock is available. That statement should not be interpreted as a promise of direct, single-Region processing everywhere. An organization with a requirement to keep inference in one particular Region should not treat the US geographic profile as equivalent: its documented boundary is the US geography, not one Region.
The distinction also affects the bill. AWS’s K3 model card lists these Standard-tier prices, each per one million tokens:
| Token category | Global cross-Region inference | US cross-Region inference |
|---|---|---|
| Input | $3.00 | $3.30 |
| Output | $15.00 | $16.50 |
| Cache read | $0.30 | $0.33 |
| Cache write, 30-minute category | $3.75 | $4.125 |
The US rates are 10 percent higher across the listed categories. That is a straightforward price comparison, not a reason to choose Global when a workload requires US-only processing. The routing constraint belongs ahead of cost optimization.
The table also puts the one-million-token window in perspective. At the listed Global Standard input rate, one million ordinary, uncached input tokens would cost $3 before output charges. That arithmetic is an illustration of the published tariff, not a measurement of a typical K3 request or a promise that every request can devote its entire context budget to input. Actual spending depends on the token counts and billing categories used.
AWS’s shared security boundary addresses another part of the deployment decision: access controls, encryption and auditing. It does not remove the need to decide which source code, documents and images an application is permitted to send. Geographic routing, service controls and organizational permission are separate checks.
Kimi K3 caching and service tiers reward deliberate API choices
Prompt caching is one of the more useful features of K3’s Bedrock release. AWS calls K3 the first open-weight model on Bedrock to support explicit prompt caching, which lets an application identify reusable context rather than relying solely on automatic caching.
That is relevant when successive calls reuse a substantial body of material, such as reference documents or repository context. AWS documents implicit caching by default, and recommends explicit cache controls to improve the cache-hit rate. Its K3 model card lists a minimum of 1,024 tokens per cache checkpoint and retention of at least 30 minutes.
The economics depend on reuse. In the Global Standard price table, a cache read costs $0.30 per million tokens, compared with $3 for ordinary input, while a cache write costs $3.75. The lower read rate can make repeated context cheaper, but the write charge means “caching is enabled” is not enough to establish a saving. The application has to reuse eligible cached material.
There is also an API boundary: AWS documents explicit caching for the Responses and Chat Completions APIs only. A team using Converse cannot assume that it receives the same explicit cache controls merely because it is invoking the same model. An evaluation should therefore compare the intended integration path, not just a model name.
Service tiers follow a similar boundary. Standard is pay-per-token access without a commitment; applications select it by omitting service_tier or setting it to "default". Priority uses "priority" and costs 1.75 times the applicable Standard token rates. Flex uses "flex" and costs half the applicable Standard rates, with AWS positioning it for flexible, non-time-sensitive workloads.
AWS documents service-tier selection only for Responses and Chat Completions. Converse and Invoke support Standard on-demand inference for K3, without those tier choices. The practical trade-off is explicit: a team choosing an API also chooses which pricing and performance controls it can use.
Kimi K3’s Converse limitations can disrupt existing agents
AWS recommends the bedrock-runtime endpoint for new applications and specifically recommends Chat Completions for K3. Its model card also advises using the OpenAI-compatible Responses or Chat Completions APIs instead of Converse where possible. That recommendation is backed by documented compatibility limitations.
The most consequential issue concerns multi-turn conversations. AWS says Converse can return InternalServerException when a request includes reasoning content from earlier turns. The documentation identifies default configurations of LangChain and Strands Agents as affected by this behavior. A successful first response therefore does not establish that an agent’s subsequent turns will work.
For applications that must use Converse, AWS documents a workaround: remove reasoning blocks from prior turns before sending the multi-turn request. That is a specific change to the conversation payload, not advice to delete all prior conversation history. Alternatively, AWS recommends the OpenAI-compatible APIs.
Document inputs create a separate limitation. AWS says Converse rejects attached documents such as PDF and HTML for K3. This matters because the launch’s broad promise of document analysis can otherwise be mistaken for universal support for every document type through every API. Native vision and a large context window do not erase request-format restrictions.
Image handling also varies by interface. AWS says K3 can produce better answers when image blocks appear before text blocks in combined requests, but describes this as prompt-dependent and recommends testing both orders. The image detail setting is honored only by Chat Completions: "low" selects lower-cost processing and "high" selects higher-fidelity understanding. Responses always processes images at high detail. Bedrock does not support attaching video inputs to K3 requests.
These are concrete reasons to test more than a short text prompt before adopting the model. For an agent, the relevant check is a multi-turn exchange with the same conversation structure the application will send. For a document or image workflow, the relevant check is the intended input format through the intended API.
Evaluate Kimi K3 around the workload you will actually deploy
Teams with long-context coding, document or image workloads have a supported reason to trial K3 on Bedrock. Teams whose applications already work well with short text requests do not have evidence from this launch alone that a migration would improve results. The useful first decision is which capability the trial is meant to validate.
A focused evaluation can follow the documented boundaries without assuming undisclosed performance or commercial advantages:
- Choose
us.moonshotai.kimi-k3when the inference workload requires US-geography routing, and do not substitute the Global profile simply because the receiving endpoint is in the United States. - Prefer the documented OpenAI-compatible API paths for new K3 integrations, particularly when explicit caching, service tiers or multi-turn agent behavior matter.
- If retaining Converse, account for the documented reasoning-block failure and rejection of attached PDF and HTML documents before treating an existing integration as compatible.
- Estimate cost using the intended geography, service tier, input and output volumes, and actual cache reuse rather than the model’s ordinary input price alone.
- Keep Bedrock purchasing separate from any plan to host or resell K3 yourself, because the reported Moonshot licensing trigger does not establish the obligations of every downstream customer.
Kimi K3’s Bedrock arrival gives enterprises a concrete service to evaluate, with enough published detail to identify both promising workloads and integration traps. It also gives Moonshot a prominent distribution channel through which its commercial licensing strategy can be tested. The customer decision can proceed on documented capabilities, routing and cost; the claim that this represents a proven new source of licensing income must wait for disclosed commercial evidence.