Kimi K3, the open weights model that closed the gap

Kimi K3, the open weights model that closed the gap

Moonshot AI released Kimi K3 in mid July 2026 and published the full weights eleven days later. It is a mixture of experts model with around two point eight trillion parameters in total and roughly one hundred four billion active during generation, with a context window reaching a million tokens.

The numbers impress, and the most important thing is different: this is a model with public weights matching leading closed models on some tasks, particularly coding and agentic work. Until recently those two properties excluded each other.

What that means in practice

A mixture of experts architecture means a fraction of the parameters work on each token. The model computes as fast as a hundred billion parameter model while drawing quality from the whole.

One practical consequence deserves knowing before planning hardware. Everything must load into memory, not only the active part. A model of two point eight trillion parameters, even at its native four bit quantisation, needs at minimum one node holding eight data centre cards, and for real production traffic the vendor recommends a multi node configuration. Running it on a laptop is out of the question.

A million tokens of context lets you drop an entire mid sized repository or several hundred pages of documentation into a request. That changes how analytical work is done, and it costs: processing that input takes time and tokens, so retrieval remains better for repeated queries.

The model is also natively multimodal: it understands text, images, and video in one pass, with no separate vision model bolted on. Reasoning is permanently on, so a response carries the reasoning trace alongside the answer proper, and all you steer is its depth.

The licence

This is the first thing to check and the most often skipped with models from this part of the world.

The weights are public, but the licence is bespoke, based on a permissive one with additional conditions. At large operating scale, measured by user count or revenue, a requirement appears to mark the product with the model's name. For most companies that condition is immaterial; for a large consumer platform it is not.

The thresholds are stated outright: the naming requirement applies to a product with more than a hundred million monthly active users or more than twenty million dollars in monthly revenue. A separate, stricter condition covers offering the model itself as a service: a company running such a business and exceeding twenty million dollars of revenue over any consecutive twelve months must enter a separate agreement with the vendor before any commercial use.

Both conditions carry an exemption that in practice covers most deployments. Neither applies to internal use, meaning use where neither the model nor its capabilities are made available to third parties, nor to access through the vendor's official products and its certified partners.

The practical conclusion matches other models opened by commercial companies: read the licence text before building the model into a product. The word "open" in marketing material does not mean the terms match a permissive licence without reservations.

If you need a licence without additional conditions, the right direction is models released under a classic permissive licence, from Mistral for instance.

Working through the API

The interface follows a popular format, so integration comes down to changing the address and the model name.

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.ai/v1",
)

response = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "Analyse this module and name its weak points: ..."}],
)

That compatibility matters practically when comparing. The same code with a different model name and address lets you run your own cases through several models and compare results rather than relying on somebody else's benchmarks.

Two things depart from a typical call, though, and both can surprise you on a first integration. The first is reasoning that cannot be switched off; all you steer is its depth, through the reasoning_effort field, which takes low, high, and max, defaulting to the highest. Dropping to low on routine work cuts cost and latency more than any prompt change.

The second is how a conversation is carried. The model was trained with reasoning history preserved, so on later turns and on tool calls you must hand back the whole assistant message, reasoning trace included, rather than the answer text alone.

history = [{"role": "user", "content": "Tell me three random numbers."}]

response = client.chat.completions.create(
    model="kimi-k3",
    messages=history,
    reasoning_effort="low",
)

history.append(response.choices[0].message.model_dump(exclude_none=True))
history.append({"role": "user", "content": "What are the other two you had in mind?"})

Skipping that step returns no error and quietly degrades results instead: the model loses its own reasoning from the previous turn and, across longer sequences, starts dropping conclusions it had already reached.

The official price list carries two input rates and one output rate, and the gap between the input rates is tenfold. A million input tokens costs 0.30 USD on a context cache hit and 3 USD on a miss, while a million output tokens costs 15 USD. That is exactly Claude Sonnet 5 territory rather than a fraction of closed frontier pricing, and a steep jump over the same vendor's earlier models. It only comes out cheap beside the strongest closed models, so the argument for this one is access to the weights rather than the rate itself.

One entry condition sits alongside that in the price list: the model unlocks only after topping the account up by at least one dollar, and the cumulative top up determines the request and token limits per minute and per day. Check the current price list at source anyway, since rates on open models change more often than on closed ones.

Running it yourself

Since the weights are public, the model can run on your own infrastructure. You only need to know what that entails.

The full weights need server machines with many cards and a serving stack supporting distributed inference. That is not an afternoon's installation but an infrastructure project. Without that groundwork, the right route is renting from a provider offering this model, which preserves independence from a single company.

Smaller and quantised variants released by the community lower the requirements at a cost in quality. That is a reasonable compromise on tasks where data privacy matters more than peak accuracy.

The weights themselves run on three inference servers the vendor names, and starting one comes down to a single command exposing an interface in the same format the official API uses. The example below uses vLLM, because it batches incoming requests on the fly and therefore holds throughput across many simultaneous conversations instead of serving them one after another.

vllm serve moonshotai/Kimi-K3 \
  --served-model-name kimi-k3 \
  --tensor-parallel-size 8 \
  --max-model-len 262144 \
  --api-key "$LOCAL_KEY"

The card count in the parallelism flag and the context length depend on the hardware you have, so take the specific topology from the recipe published for this model rather than guessing. The weights are natively quantised, since quantisation was folded in during training, so it need not be added as a separate step and does not carry the usual quality penalty.

Cutting the context from a million tokens down to what you actually use is the simplest way to reduce the memory requirement here. The server reserves room for the longest permitted conversation, so declaring a million tokens in a service handling ten thousand token requests is expensive caution.

More on running models locally sits in the piece on Ollama, remembering that single user tooling will not deliver the throughput many users need.

Renting instead of your own infrastructure

Since running the full weights yourself is a project rather than an installation, the middle route deserves knowing.

Cloud providers offering models with public weights bill per token, as with closed models, and you keep two things. The first is the ability to move to another provider of the same model, since the weights are public, so you are not tied to one company. The second is the ability to move onto your own infrastructure once volume justifies it.

That difference is underrated. A closed model means that on a price change or a version retirement your options are migration or acceptance. A public weights model gives a third option, and its mere existence changes your negotiating position.

Check what a provider actually offers, though. The same weights served by different stacks give different latency, different context limits, and different tool calling behaviour. A model name alone does not warrant assuming identical results.

Parallel processing

Tasks where many calls run at once are a working pattern in their own right, worth knowing before you try shortening response time any other way.

An agent task split into a dozen independent subtasks executed serially takes a dozen times longer than one. Running them in parallel shortens the wall clock to the longest of them, at the cost of higher momentary consumption.

That pattern suits reviewing many files at once, checking several hypotheses, and batch processing where each item is independent. It does not suit steps that depend on each other, since parallelism then has nothing to speed up.

Mind the cost too. Ten parallel calls cost the same as ten serial ones, only faster. The saving is in time rather than money, so on tasks where nobody waits, parallelism adds nothing but a usage spike.

What it is good for

Three areas recur in this model's applications and are worth knowing before you start comparing.

The first is code work. On benchmarks measuring real repository issue resolution the model performs comparably with the closed leaders, which a year ago would have been a surprise. On tasks spanning many files and long sessions that advantage registers.

The second is agentic work. The model is built for tool calling and long step sequences, which was often a weak point in open models.

The third is long document analysis. A million tokens of context lets it read an entire contract, specification, or log dump at once, with no chunking and no retrieval to build.

Language remains the boundary. Models from this part of the world perform best in English and Chinese and typically weaker elsewhere, so with content in another language a test on your own examples is mandatory.

Data and compliance

With a model from a vendor outside your jurisdiction a question arises that public weights answer unusually.

Using the official interface means sending content to the vendor's servers, under terms and a data location they determine. With personal data or trade secrets that needs checking before deployment, exactly as with any other external vendor.

Public weights, though, give an exit a closed model does not. The same model run at a provider in a chosen region or on your own infrastructure processes data where the requirements allow. The data transfer question then stops concerning the model and starts concerning infrastructure alone.

That is a recurring pattern in regulated organisations. A project starts on the vendor's interface because it is fastest, and after the first audit part of the pipeline moves to a model run elsewhere. Plan for that split from the start, since a thin layer with one call shape makes the change a day's work.

How to compare it against your current model

Public benchmarks measure tasks that rarely resemble yours, so run the comparison yourself. It takes an afternoon and yields an answer a decision can rest on.

Start with thirty real cases from the last month of work. They should cover easy tasks, hard ones, and ones where your current solution failed, since those separate models most.

Run them through two or three models on an identical prompt and record the results side by side. Reading twenty answers in a table says more than any number, since you see not only whether an answer is correct but how it reads.

Add a number for the measurable parts: share of cases solved correctly, response time, and cost per run. Tools like Promptfoo do that for you and compare models on the same set with one command.

The configuration fits in a dozen or so lines, because an interface following the familiar format lets you declare this model as an ordinary provider with the address swapped out.

providers:
  - id: openai:chat:kimi-k3
    config:
      apiBaseUrl: https://api.moonshot.ai/v1
      apiKeyEnvar: MOONSHOT_API_KEY
  - id: anthropic:messages:claude-sonnet-5

prompts:
  - file://prompts/analysis.txt

tests:
  - vars:
      ticket: "Payment went through but the order was cancelled"
    assert:
      - type: contains
        value: refund

The same file run a month later tells you whether anything shifted, and with rapidly developed models it shifts more often than most teams assume. That is the main advantage of a recorded set over eyeballing: it can be repeated.

Kimi against the alternatives

Choosing among the rows comes down to three questions: do you need weights, what hardware do you have, and which language do you work in. A model with public weights you have nowhere to run gives exactly what a closed model gives, only with worse support.

Remember too that a benchmark lead does not transfer directly to your tasks. Thirty real cases run through two models say more than any ranking and take an afternoon.

The most sensible arrangement on a larger deployment is in fact using several models at once. Bulk and simple work goes to the cheaper model, hard work to the stronger one, and the choice happens in the layer routing traffic. Public weights help precisely here, because they let you staff the first role without paying per token.

Common mistakes

The first is planning hardware by active parameter count. Everything enters memory, so generation speed does not reduce memory requirements.

The second is skipping the licence. Public weights do not mean a permissive licence without reservations, and the conditions at scale deserve knowing before building the model into a product.

The third is assuming a benchmark result transfers to your domain. Differences between models depend on language, code style, and task type more than on ranking position.

The fourth is dropping a million tokens of context into repeated queries. At a hundred questions a day, vector database retrieval comes out many times cheaper and faster.

The fifth is skipping a test in your own language. That is where models in this family perform worse than in English, and the gap sometimes exceeds the one between generations.

The sixth is having no layer separating logic from the vendor. Interface compatibility eases switching only when your code calls one function of your own rather than a specific company's client in twenty places.

FAQ

What is Kimi K3?

A language model from Moonshot AI with a mixture of experts architecture, around two point eight trillion parameters in total and a context window up to a million tokens. Released in mid July 2026, with weights published publicly late that same month.

Are the weights genuinely available?

Yes, though the licence is bespoke, based on a permissive one with additional conditions. At large operating scale a product attribution requirement appears. For most applications that is immaterial; before building the model into a product, read the licence text.

What hardware is needed?

The full weights need server infrastructure with many cards, so running it yourself is a project rather than an installation. The realistic alternative is renting from a provider offering this model or taking quantised variants with lower requirements and lower quality.

Is it good for code work?

Yes, and that is its strongest side. On benchmarks measuring real issue resolution it performs comparably with the leading closed models. On your own repository, check that across a few dozen tasks, since differences depend on the programming language.

How does it handle languages other than English?

Worse than English, which holds for most models outside a given language's sphere. For applications in another language, compare it against a European model on your own examples before deciding.

The model and licence are described on the Moonshot AI site, and a release analysis appears in Simon Willison's write up.