Kimi K3 License Explained: Commercial Use Rules

This article is adapted from OpenRouter Blog’s analysis titled *《Is Kimi K3 Open Source? Weights, License, and How to Call It》*. Many AI builders confuse open-weight releases with true open-source software. When selecting foundation models for agent workflows, teams often focus on benchmark scores, pricing and context window size, while skipping deep review of license terms. Licensing clauses remain irrelevant for local personal testing, but they become binding legal constraints once the model is integrated into production commercial products.

OpenRouter’s analysis clarifies that "open weights" and "open source" answer two separate technical and legal questions.

• Open-weight: It only means trained model parameters are publicly released. Developers can download and inspect the checkpoint, but the attached license can be custom-written by the model publisher.
• Open-source: Following the definition from the Open Source Initiative (OSI), the license must satisfy the Open Source Definition and be listed in the OSI approved license catalog, such as Apache-2.0 and MIT, which carry SPDX identifiers.

Kimi K3 meets the definition of open-weight, but it is not OSI-compliant open source. Moonshot AI published its checkpoint on Hugging Face under the repository moonshotai/Kimi-K3, using a custom license named Kimi K3 License. This license has no SPDX identifier and is not present on the OSI license list. The license field on the model card simply marks the license as "other", labeled kimi-k3.

The phrase "Kimi K3 is open source" is legally inaccurate. The ability to download weights from Hugging Face and the qualification for open-source commercial usage are two distinct concepts.

1. Scope of Rights Defined in the Kimi K3 License

The license text defines the covered "software" as model weights, parameters, configuration files, inference and training code, plus associated documentation. The license grants broad rights: use, copy, modify, merge, publish, distribute, sublicense, sell copies, run, deploy, fine-tune, and create derivative works. This covers nearly all common operations developers would perform.

There are only two baseline mandatory conditions in Section 1:

1. Preserve copyright and license notices in all copies or substantial portions of the software.
2. All usage must comply with applicable local laws and regulations.

These two base rules impose minimal friction. The clauses that materially impact production launch are the two threshold-based commercial clauses.

2. Two Threshold Clauses Governing Commercial Deployment

The baseline rules apply to all users. The following two threshold provisions require review by legal teams before commercial release.

2.1 Model as a Service Revenue Trigger (Section 2)

The license defines MaaS (Model as a Service) as scenarios where a third party runs model inference or fine-tuning through APIs, retaining meaningful control over input, parameters and training datasets. Two exclusions apply: embedding model capabilities inside end-user products or harness applications, and forwarding requests to a third-party managed model.

Trigger condition: If you or affiliated entities operate MaaS services, and the aggregated revenue from related services exceeds 20 million USD over any consecutive 12-month period, you must sign a separate agreement with Moonshot AI before using this software or its derivatives in any commercial offering.

2.2 User Interface Attribution Requirement (Section 3)

If the software or its derivative works are used for commercial products or services, and the product monthly active users exceed 100 million, OR monthly revenue exceeds 20 million USD, the product user interface must prominently display the "Kimi K3" brand identifier.

3. Two Exempt Scenarios

Section 4 defines two exemption cases, which remove the obligation under the above two threshold clauses:

1. Internal usage: The software, outputs or underlying capabilities are not provided to external third parties. Common use cases include internal coding agents and private knowledge-base Q&A deployed within corporate intranets.
2. Services delivered via official Moonshot AI products or certified inference partners.

These exemptions are critical. Teams that only consume Kimi K3 through hosted APIs or run the model inside an internal intranet will generally not hit the threshold triggers. Only businesses that resell model inference capabilities as a standalone service need additional contractual negotiation with Moonshot AI.

The original license text referenced in this article corresponds to the version published on September 9, 2026. This article does not constitute legal advice. All teams must read the full license text before production deployment.

4. What is Contained Inside the Kimi K3 Checkpoint

The table below is sourced from the official Hugging Face model card, listing core model specifications.

The model card describes Kimi K3 as a native multimodal model, supporting text, image and video inputs. The thinking mode is enabled by default. The reasoning_effort parameter accepts three values: low, high, max, with max as the default value. The model card also lists three publicly available serving stacks: vLLM, SGLang, and TokenSpeed.

There is a practical deployment note: a 2.8T parameter checkpoint requires multi-node GPU infrastructure. Without specialized hardware, hosted API endpoints remain the only feasible way to run the model. Self-hosted deployment is not fully covered in the official documentation, and no baseline benchmark suite is provided.

5. Common Pitfall for Multi-turn Dialogue and Tool Calling

The official model card explicitly states: in multi-turn conversations and tool calling workflows, the complete assistant message returned by the API, including reasoning content and tool_calls, must be fed back into the message array.

This is the most frequent bug in self-built agent loops. Many developers only persist the content field in conversation history, discarding reasoning and tool_calls. This causes the model to lose track of prior reasoning steps and previous tool invocations in subsequent turns. When implementing agents, full message restoration must be treated as a hard rule in code, not an optional post-hoc debug step.

6. Minimal Integration Code Example

The following TypeScript SDK snippet replicates the official example published by OpenRouter.

// Example from OpenRouter official documentation
import { OpenRouter } from '@openrouter/sdk';

const openRouter = new OpenRouter({
  apiKey: process.env.OPENROUTER_API_KEY ?? '',
});

const result = await openRouter.chat.send({
  chatRequest: {
    model: 'moonshotai/kimi-k3',
    messages: [
      {
        role: 'user',
        content: [
          { type: 'image_url', imageUrl: { url: 'https://example.com/screenshot.png' } },
          { type: 'text', text: 'Summarize this screenshot and list the open questions.' },
        ],
      },
    ],
    reasoning: { effort: 'high' },
    stream: false,
  },
});

if (result instanceof ReadableStream) {
  throw new Error('Expected a non-streaming response');
}

console.log(result.choices[0].message.content);

Explanation of key parameters:

• model: the official model identifier.
• messages.content: an array supporting mixed image and text input, reflecting native multimodal capability.
• reasoning.effort: controls reasoning depth, set explicitly to high in this example.
• stream: false: returns a complete JSON object rather than streaming chunks, requiring type checking to avoid errors when accessing .choices.

The response payload contains choices and usage metadata. In the official test run on September 11 for an equivalent request, the API returned a one-sentence image summary, a reasoning object, plus usage metrics: 96 prompt tokens, 119 completion tokens and 87 reasoning tokens.

Kimi K3 exposes additional reasoning-related parameters: reasoning, reasoning.exclude, and reasoning.enabled.

• Setting exclude: true strips reasoning text from responses, while the model still performs internal reasoning.
• Setting enabled: false removes the reasoning field entirely; the model embeds reasoning steps into the main content field, generating longer final answers.

The model card notes that thinking mode is always active. A single API request cannot confirm whether the endpoint performs internal reasoning or simply omits the reasoning field in returned payloads. enabled acts as a request parameter for the endpoint, not a guaranteed feature toggle.

7. Pricing: Not a Single Static Number, But Variable Across Endpoints

A common misconception: the same model ID does not guarantee identical pricing or capability across different endpoints. As of the catalog snapshot from September 09, 2026, kimi-k3 had 19 available endpoints.

• Prompt price range: $1.80 to $6.00 per million tokens
• Completion price range: $9.01 to $22.50 per million tokens
• Cache-read price range: $0.21 to $0.60 per million tokens
• Moonshot AI official endpoint fixed pricing: prompt $3.00, completion $15.00, cache read $0.30
• Maximum output length varies widely across endpoints, ranging from 16,384 to 943,718 tokens

Parameter support is inconsistent between endpoints. Some endpoints support tool calling while others do not; some support structured output while others lack this capability. For workflows relying on specific parameters, developers should set require_parameters: true. This routes requests only to endpoints that fully satisfy all required parameter constraints, preventing silent failures in production where an endpoint silently ignores unsupported parameters that passed local testing.

Other metadata fields in the catalog include moonshotai/kimi-k3, Batch API, prompt_tokens_details, cached_free_tokens. Each report contains token counts, pricing, and endpoint capability summary. All pricing and model capabilities are subject to change, and developers should refer to the official document for the latest information.

8. Comparison with Kimi K2: Same Base License, New MaaS Revenue Threshold

Kimi K2 and K2.5 used a modified MIT license. The MIT variant required prominent UI branding when commercial products hit 100 million monthly active users or monthly revenue above 20 million USD.

The Kimi K3 License retains this UI attribution clause and adds the new MaaS revenue threshold rule. The branding obligations remain identical from K2.5 to K3; the new clause only applies to teams selling model inference as a MaaS offering.

9. Practical Checklist for Agent Developers

1. Do not judge commercial usability solely based on Hugging Face weight availability. Always read the full license text.
2. Classify your use case before integration: internal usage, self-hosted deployment, official hosted API, or certified partners. This determines whether threshold clauses apply.
3. Build full message persistence for multi-turn agent loops, retaining reasoning and tool_calls inside assistant history.
4. For tool calling or structured output workflows, use require_parameters to filter compatible endpoints.
5. Avoid relying on a single pricing number; one model ID maps to variable pricing, parameter support, and max output limits on different endpoints.
6. License terms, pricing and endpoint catalogs are subject to updates. Refer to official documentation before launch. This article reflects license and catalog data from September 9, 2026 and is not legal counsel.

10. Operational Considerations for Multi-Endpoint Model Routing

When teams consume Kimi K3 across multiple endpoints, they must manage differences in pricing, feature support, rate limits and response schemas. Teams running multi-model agent workloads often need centralized traffic management to route requests to qualified endpoints, enforce parameter constraints, and aggregate token consumption metrics. An API gateway such as Treerouter can consolidate multi-endpoint routing logic, validate required model parameters before forwarding requests, and collect unified usage logs across heterogeneous LLM endpoints.

This routing abstraction separates agent business logic from endpoint selection and vendor-specific API differences. Agent code can reference the single moonshotai/kimi-k3 model ID, while the gateway handles endpoint filtering, cost-based routing, and quota enforcement behind the scenes. This is especially valuable for teams that need to switch between official Moonshot endpoints and third-party hosted endpoints dynamically without rewriting agent source code.

For teams building production-grade agent systems, endpoint variability creates hidden operational risk. Even with identical model identifiers, missing tool-calling support or lower maximum output limits on one endpoint can break long-running agent workflows. Centralized API orchestration helps surface these compatibility issues at the gateway layer before requests reach the model service.

Conclusion

The core takeaway from this license review is distinguishing open-weight release from OSI-certified open source. Kimi K3 provides publicly downloadable model weights under a custom Kimi K3 License, with broad rights for modification, fine-tuning and distribution. However, two high-revenue threshold clauses impose extra contractual obligations for MaaS services and large-scale commercial products.

For agent builders, the critical implementation rule is preserving complete assistant message history including reasoning and tool call payloads in multi-turn dialogue. Teams must also account for endpoint variance: pricing, parameter support and maximum output length differ widely, even for the same model identifier. Before launching commercial services, legal review of the license and validation of target endpoint capabilities are mandatory. Teams managing multiple model endpoints can leverage an API gateway to simplify routing, parameter validation and usage tracking for foundation model requests.

Learn more：https://treerouter.com