How to Run Kimi K3 via API in 2026 (Price, Context, License Caveats)

You can run Kimi K3 through any OpenAI-compatible API by changing the base URL and model ID. No new SDK required. K3 is a ~2.8-trillion-parameter mixture-of-experts model with ~104B active parameters, as reported by Moonshot AI as of 2026-08-20. This guide covers pricing, context, license caveats, and every realistic way to run it.

Key takeaways

• Kimi K3 is ~2.8T total parameters with ~104B active per token (as reported by Moonshot AI, as of 2026-08-20). It's a sparse MoE, so per-token compute is a fraction of its total size, but you still need to fit all weights in memory to self-host.
• Any OpenAI-compatible client works: swap base_url and the model ID, keep your existing code.
• Self-hosting requires roughly 2.8 TB of GPU memory at FP8 (about double at BF16) before KV cache: multi-node territory.
• There is no single K3 price; each host sets its own rates. Open-weight MoE APIs typically run at a fraction of frontier closed-API pricing, but compare published pricing pages. DeAI News had no verified K3 price as of 2026-08-20.
• License: read the model card before commercial use. Recent K-series releases shipped under a modified MIT license with an attribution clause at very large scale.

What is Kimi K3?

Kimi K3 is Moonshot AI's flagship open-weight model and the successor in the K series that includes K2 and K2.6. It is a sparse mixture-of-experts (MoE) model: ~2.8 trillion total parameters, with ~104 billion activated per token, as reported by Moonshot AI as of 2026-08-20.

That architecture matters for two practical reasons. First, inference cost per token scales with the active parameters, not the total, which is why hosted K3 endpoints can be priced far below what a dense 2.8T model would cost to serve. Second, the total parameter count still determines the memory footprint, which is why self-hosting is a datacenter-scale project (more on that below).

Moonshot positions K3 at coding, reasoning, and agentic tool-use workloads, per its launch materials. Treat that as a vendor positioning statement and validate against your own tasks. Weights are published on Hugging Face under the moonshotai organization, and you can track availability and metadata on DeAI's model pages.

Is Kimi K3's license OK for commercial use?

This is the caveat most teams skip and shouldn't. "Open weight" does not automatically mean "open source". Our explainer on open-weight vs. open-source licenses covers the distinction and why it matters for compliance.

Recent releases in the Kimi K series have used a modified MIT license: broadly permissive, commercial use allowed, but with an additional clause requiring prominent attribution for products above very large usage or revenue thresholds. Whether K3 carries identical terms is something you must verify on the K3 model card itself, because Moonshot can change terms per release.

A practical pre-deployment checklist:

• Read the LICENSE file in the official repo itself, not a summary or a blog post.
• If you redistribute weights or fine-tunes, check the naming and attribution requirements for derivatives.
• If you operate at consumer-product scale, have counsel review any threshold-based clauses before launch, not after.
• If you use a hosted API, the provider's terms of service apply on top of the model license.

For most ordinary commercial workloads (internal tools, SaaS features, agents), permissive open-weight licenses of this type are workable. The risk is in assuming, not in reading.

How does Kimi K3 benchmark against its peers?

Only cited numbers belong here, and as of 2026-08-20 the verified public anchor is the architecture itself: ~2.8T total / ~104B active parameters, as reported by Moonshot AI.

Moonshot's launch materials report results placing K3 at or near the top of open-weight models on coding and agentic suites. Those are vendor-run evaluations, so weight them accordingly. For independent signal, community-driven rankings such as LMArena are the standard first stop, and the serious move is to re-run your own eval harness against K3 before migrating production traffic.

One dimension most benchmark tables ignore is refusal behavior: how often a model declines benign requests. DeAI's refusal-index methodology scores exactly that, and results are published on each model's page as they complete. Worth checking for K3 if you run user-facing agents where over-refusal is a real cost.

Where can you run Kimi K3?

First-party and hosted APIs

Catalogs change weekly, so treat this as a checklist of places to look rather than a permanent directory:

• Moonshot AI's first-party platform (platform.moonshot.ai) is the reference endpoint, typically first to receive updates and full feature support such as tool calling.
• Aggregators such as OpenRouter route K3-class models across multiple underlying hosts through one API, useful for price comparison and failover.
• Hosted inference providers including Together AI, Fireworks AI, Groq, DeepInfra, Novita, Nebius, Baseten, and SiliconFlow have all carried recent open-weight flagship releases; confirm K3 in each provider's model catalog.
• Decentralized options include Morpheus, a decentralized inference marketplace, where independent operators serve open-weight models; the same evaluation criteria apply as to any host.

Evaluate every option on identical criteria: does the catalog actually list K3, what are the published per-token rates, what context length does the endpoint expose (hosts sometimes cap it below the model maximum), which regions are served, and what is the data-retention policy. Note that zero-retention and "operators can't see prompts" statements are policy claims, not independently verified facts. If privacy is a hard requirement, prefer providers with published policies you find credible, or self-host.

What are Kimi K3's self-host requirements?

Here the verified anchor does the math for you. At ~2.8T parameters:

• FP8 (1 byte/param): ~2.8 TB of memory for weights alone.
• BF16 (2 bytes/param): ~5.6 TB for weights alone.
• Plus KV cache, which grows with context length and concurrent requests. That's significant for a long-context model.

In hardware terms, that is multiple 8-GPU nodes of 80 GB-class accelerators at FP8, connected by fast interconnect (NVLink within nodes, InfiniBand across them), using tensor and expert parallelism. vLLM and SGLang are the standard serving stacks for large MoE models, and both document multi-node deployment. Community quantization builds can shrink the footprint further, with the usual quality trade-offs, so validate on your workload.

Honest assessment: self-hosting K3 is a six-figure infrastructure commitment. Unless you have strict data-residency requirements or very large steady-state volume, a hosted API is the rational starting point.

How do you call the Kimi K3 API?

Every host above exposes an OpenAI-compatible endpoint, so integration is a two-line change. Model IDs vary by provider (e.g., kimi-k3, moonshotai/Kimi-K3-...), so copy the exact string from your provider's docs.

Python:

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_PROVIDER_KEY",
    base_url="https://YOUR-PROVIDER-ENDPOINT/v1",  # the only line that changes
)

resp = client.chat.completions.create(
    model="kimi-k3",  # exact model ID from your provider's catalog
    messages=[{"role": "user", "content": "Explain MoE routing in one paragraph."}],
    stream=True,
)
for chunk in resp:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="")

curl:

curl https://YOUR-PROVIDER-ENDPOINT/v1/chat/completions \
  -H "Authorization: Bearer YOUR_PROVIDER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3",
    "messages": [{"role": "user", "content": "Explain MoE routing in one paragraph."}],
    "stream": true
  }'

Provider quirks to check before production: supported parameter ranges, tool-calling schema support, whether max_tokens defaults are sane for a long-context model, and rate limits on the tier you're on.

Kimi K3 vs K2.6: should you switch?

K3 is the next generation at a larger scale (~2.8T total / ~104B active parameters as reported by Moonshot AI as of 2026-08-20), while K2.6 remains available on many endpoints. Switching is mechanically trivial (a model-ID change on the same base URL), but do three things first: diff pricing between the two on your host, confirm the context window you need is exposed on the K3 endpoint, and re-run your eval suite, because generation-to-generation behavior shifts, including refusal patterns, can break prompts that were tuned against K2.6. If K2.6 meets your quality bar at a lower price on your provider, there is no forced march.

FAQ

Is Kimi K3's license OK for commercial use? Read the LICENSE file on the official Hugging Face model card before deploying. Recent Kimi K-series releases used a modified MIT license that permits commercial use but adds an attribution requirement for very large products. Terms can change per release.

How much does the Kimi K3 API cost? There is no single price: each host sets its own per-token rates, and DeAI News had no verified K3 price as of 2026-08-20. Open-weight MoE APIs typically cost a fraction of frontier closed APIs. Compare providers' published pricing pages.

What's the difference between Kimi K3 and K2.6? K3 is Moonshot's next generation at ~2.8T total and ~104B active parameters, as reported by Moonshot AI as of 2026-08-20. Migration is usually a model-ID swap on the same endpoint, but re-run your own evals, because behavior and refusals can shift.

What do you need to self-host Kimi K3? Roughly 2.8 TB of GPU memory at FP8 (about double at BF16) for weights alone, plus KV cache. That's multi-node cluster territory with fast interconnect. vLLM and SGLang are the usual serving stacks. Most teams use a hosted API instead.

What is Kimi K3's context length? Confirm the exact window on the model card, and on your provider's endpoint, since hosts sometimes cap context below the model maximum. Long prompts raise both latency and cost, so size your context budget before committing.