A three-trillion-class model shipped with one setting
Moonshot AI put Kimi K3 into the world on 16 July with a sentence that does the marketing for it: the world's first open 3T-class model, designed for frontier intelligence across long-horizon coding, knowledge work, and reasoning. The specification behind the sentence is real. K3 carries 2.8 trillion total parameters in a mixture-of-experts design that activates 16 of 896 experts on any given token, built on what Moonshot calls Kimi Delta Attention and Attention Residuals, trained with quantisation awareness so the weights sit in MXFP4 and the activations in MXFP8. The native context window is one million tokens. Vision is not bolted on afterwards; the model takes images and video directly.
The detail that governs your invoice is not in the announcement. It is in the quickstart documentation. Moonshot describes K3's reasoning as natively configurable, with a thinking depth you set per call, and then notes that the setting currently supports the max effort level only. Read that twice, because it inverts the usual arrangement. On most frontier APIs the effort control is how you buy a cheap answer to a cheap question. On K3 today there is one gear. The model reasons at maximum on the trivial request and the hard one alike, and the meter does not know the difference.
Everything else in the interface is built for people who intend to spend. Context caching runs automatically, with no cache identifier to manage and no time-to-live to tune. Tool definitions load dynamically rather than sitting in every request. Structured output is enforced against a schema. Streaming separates the reasoning tokens from the answer tokens, so you can watch the model think in one channel and write in another. These are the features of a system that expects long, expensive, agentic sessions, and Moonshot has built the plumbing for exactly that.
The open model you cannot download until 27 July
The word open is doing eleven days of unpaid work. Moonshot's announcement states that the complete K3 weights will be published on 27 July. Until then, the world's first open 3T-class model is reachable one way: through Moonshot's paid API, on Moonshot's servers, in Beijing, under whatever terms are current that morning. Every property that makes an open-weight model worth choosing in the first place, the ability to inspect it, to host it inside your own perimeter, to pin a version that nobody can retire underneath you, to walk away without a migration, arrives on the later date. What arrived on 16 July is a closed product with an open-source release scheduled.
The licence has not landed either. Moonshot released the K2 family under a modified MIT licence, which is why K2 became one of the genuinely usable open-weight models rather than one of the merely downloadable ones, and the expectation across the industry is that K3 follows the same path with a technical report alongside the weights. Expectation is the correct word. There is no published model card, no licence text and no weights file, so an organisation that has already been told the model is open has been told something that is scheduled rather than something that is true. The distance between those two states is the whole of your legal review.
This is not an accusation of bad faith. It is a calendar problem, and calendar problems are the ones that quietly reset procurement. A team that evaluates K3 this week is evaluating the API. The findings, the latency numbers, the cost per task, the quality on your own workload, all describe a hosted service. On 27 July a different artefact appears, and the honest position is that you have not yet tested it. If the plan was ever to run K3 on your own hardware, the evaluation that matters has not started, and the one you are running now is measuring somebody else's infrastructure.
Fifteen dollars a million, and some answers take half an hour
K3 costs 0.30 dollars per million tokens on a cache hit, 3 dollars per million on a cache miss, and 15 dollars per million on output, or roughly 0.26, 2.60 and 13 euros. The ten-to-one gap between a cache hit and a cache miss is the loudest number in that list, and it is why Moonshot made caching automatic. A workload that reuses a long prefix, the same codebase, the same policy document, the same customer file, pays a tenth of what a workload that arrives cold pays. A workload that rebuilds its context on every call finds the expensive path all by itself, and nothing in the API will warn you.
Output is where a max-effort-only model gets interesting, because reasoning tokens are output tokens. Moonshot has described K3 as a model built for deep reasoning rather than quick turnaround, and generations of over 30 minutes have been reported on the heaviest tasks. A model that thinks at maximum by default, bills its thinking at 13 euros a million, and can spend half an hour on a single request is not priced per token in any way that a finance team can use. It is priced per completed task, and the only number that means anything is what one finished job costs on your own workload.
So measure the task, not the token. Take ten real jobs from the queue, the ones you would actually hand to a model, run them end to end, and divide. That figure is comparable to a contractor's day rate and to the cheaper model you are already running, and it is the only figure that survives contact with a budget. The per-million rate on the pricing page tells you almost nothing when the model decides for itself how long to think, and today it has no instruction to think briefly.
Moonshot published the benchmarks it loses
The most useful line in the launch is the one that concedes. Moonshot states that among the models it tested, K3's overall intelligence ranks second only to Claude Fable 5 and GPT-5.6 Sol. Labs are not required to say that, and most find a chart on which they come first. Underneath, the numbers are specific and mixed on purpose: GPQA-Diamond at 93.5, MathVision with Python at 97.8, Terminal Bench 2.1 at 88.3, DeepSWE at 67.5, and BrowseComp at 91.2. On the agentic evaluations Moonshot puts K3 ahead of the frontier it otherwise defers to, with GDPval-AA v2 at 1687 against Claude Opus 4.8 Max at 1600, and AA-Briefcase at 1527 against GPT-5.6 Sol Max at 1495.
Read that shape rather than the individual scores. The claim is not that K3 is the best model. The claim is that K3 is close enough on general intelligence and ahead on long, tool-using, browse-and-act work, which is the workload it has been engineered and priced for. A vendor that names Fable 5, GPT-5.6 Sol, Opus 4.8, GPT-5.5 and GLM-5.2 in its own comparison table has chosen the field it wants to be judged on, and has quietly told you which of your tasks it expects to win.
The money agrees with the positioning. Moonshot's most recent round values the company at about 31.5 billion dollars, roughly 27 billion euros, after a May round of 2 billion dollars at a 20 billion dollar valuation. A company whose valuation has risen by half in two months does not need to win a benchmark; it needs enterprises to believe that the gap to the closed frontier is small enough to stop paying for. Publishing a second-place finish is a cheaper way to make that argument than claiming a first.
Three things to settle before the weights land
First, decide which K3 you are buying, because there are two and they arrive eleven days apart. If the answer is the API, then the open-weights story is marketing that does not apply to you, and K3 should be judged as a hosted Chinese frontier service on price, latency, data handling and the terms attached to your prompts. If the answer is the weights, then nothing you learn this week transfers, the licence text is a gating document rather than a formality, and the real evaluation starts on 27 July on hardware you control.
Second, find out what one job costs before you find out in production. Run your ten hardest real tasks, record wall-clock time and total output tokens including reasoning, and set the number against the model you run today. A max-effort-only model with a 30-minute ceiling and a 13-euro-per-million output rate can be excellent value on work that used to take a specialist a morning, and indefensible on a request that a small model answers in four seconds. The same model, the same price list, opposite verdicts, and the deciding variable is your workload rather than the benchmark table.
Third, write down what happens if the effort setting stays welded at max. Moonshot's documentation says currently, which is a word with a roadmap behind it and no date attached. If a lower effort tier ships, K3 becomes a two-speed model and the cost case changes completely. If it does not, then you are running a model that cannot be told to hurry, and the mitigation is architectural rather than commercial: route the cheap questions somewhere else and reserve K3 for the work that deserves half an hour. Decide that now, while it is a design choice, rather than in the first month, when it is an invoice.
Read next: OpenAI Just Halved the Price of Everyday AI | Grok 4.5 Loses the Benchmarks and Wins the Bill



