The model nobody can retire on you

Nine days from now, on August 5, Claude Opus 4.1 stops answering requests. Three weeks after that, on August 26, OpenAI's Assistants API stops answering too. If you are the ops manager who spent three Fridays last spring building a call-summarizer or a lead-scorer on top of one of those, you are about to spend another three Fridays rebuilding something that already worked, and nobody is going to count that as a project. Overnight, Moonshot AI published the full weights for Kimi K3, a 2.8 trillion parameter model sitting near the top of the capability charts. The interesting thing about it is not the benchmark. It is that this one has no retirement date, because there is nobody in a position to set one.

What actually shipped

The model card is specific. Kimi K3 is a mixture-of-experts model: 2.8 trillion parameters total, but only about 104 billion of them active on any given token, drawn from 896 experts with 16 selected per token across 93 layers. It takes a 1,048,576 token context window, roughly a million tokens, and it handles images and video natively through a 401 million parameter vision encoder. The weights ship quantized to four bits using MXFP4, with the quantization applied during training rather than bolted on afterward, which is why the download is about 1.4 terabytes instead of the 5.6 terabytes the same model would need at full precision.

It is the largest open-weight model anybody has published. Nathan Lambert's read on it, in a piece on the open-weights escalation, is that the gap between what you can rent from a frontier lab and what you can download has compressed from a debated six to nine months down to something closer to three to five. That number is the whole story for anyone who has been waiting for open models to get good enough to matter.

The license matters more than the license usually does. It is not Apache or MIT, it is a custom Kimi K3 License, and the restrictions in it are aimed at a company you are not. You owe Moonshot a separate agreement only if you run a model-as-a-service business clearing twenty million dollars, and you owe them a logo on your interface only if you cross a hundred million monthly active users. Internal use is exempt outright. For a forty person distributor or a two hundred person agency, it reads as unrestricted.

Permanence is the feature

Here is the part the coverage keeps skipping. Every tool you have built or bought that calls a hosted model has a clock on it, and the vendors publish the clock. Anthropic's deprecation page commits to at least sixty days of notice before a public model retires, and it lists the graveyard: Claude Opus 4 and Sonnet 4 retired in June, Haiku 3 in April, Sonnet 3.7 in February. OpenAI's deprecations page is gentler on paper, six months minimum for a generally available model, but as little as two weeks for a preview. Six GPT-5 and o3 snapshots leave the first party API on December 11. The Assistants API, an entire product surface that plenty of people built on because it was the easy path, is gone on August 26.

None of that is bad behavior. Capacity is finite and new models have to go somewhere. But notice what it does to your side of the ledger. You are not renting a capability, you are renting a specific model, and the thing you built is calibrated to that specific model's quirks. The prompt you tuned over a weekend until the output stopped hallucinating account owners is tuned to that model. The examples you pasted in, the temperature you settled on, the parsing you wrote around its formatting habits, all of it is fitted to a thing with an expiration date printed on the box.

The migration is never a config change. It is a re-tune, a re-test, and a re-validation against real records, and it costs whatever your time is worth times however long it takes to trust the output again. Call it two days for a simple tool and two weeks for one that touches revenue. Multiply that by the number of small tools you have shipped, and multiply that by however many times a year the vendors clean house. That is the real number, and nobody puts it in the business case when they approve the first project.

An open-weight model changes the shape of that liability. The weights are a file. Somebody has a copy. If the provider you are using today stops serving Kimi K3, another one can start, and the thing you built keeps working with the same quirks and the same prompt, because it is literally the same model. That is not a small difference in kind. It is the difference between building on rented land and building on land where at least the deed exists somewhere.

What you would actually do with this

You are not going to run this yourself, and you should stop reading anyone who implies otherwise. Loading 1.4 terabytes of weights takes roughly eighteen eighty-gigabyte accelerators before you reserve a single byte for context or serve a second concurrent request. A dense modern node, eight cards at 192 gigabytes each, barely fits the weights with nothing left over. This is not a thing that lives in your server closet, and it is not a thing your cloud budget absorbs quietly.

What you do instead is rent it, the same way you rent everything else, but from a market rather than a monopoly. Moonshot's own API prices K3 at three dollars per million input tokens and fifteen per million output, with cached input dropping to thirty cents. Together AI and Modal both shipped hosted access on day zero. OpenRouter already routes across multiple providers with modes for cheapest, fastest, and most accurate tool calling. When one model has five hosts competing, the price goes one direction, and it is not the direction a single vendor's pricing page goes.

The practical move for a practitioner reader is smaller and more boring than "switch everything." It is this: whatever you build next, put one thin layer between your tool and the model. A single function that takes your prompt and returns text, with the model name in one place instead of scattered across nine scripts. That is a Friday afternoon of work, once, and it converts every future retirement notice from a rebuild into an afternoon of testing. Then keep an open-weight model configured as your second option in that layer, not because you plan to use it, but because having a tested fallback is what turns a vendor email into a shrug.

For an owner-operator evaluating software rather than building it, the question this release lets you ask a vendor is a good one and you should ask it out loud: which model is this built on, and what happens to my workflows when it retires? A vendor who has thought about it has an answer. A vendor who has not will tell you it is handled, and you will find out in eighteen months whether that was true.

The honest take

The price is not the win here, and the coverage is quietly implying that it is. Three dollars in and fifteen out is not a discount. That is premium-tier pricing, roughly what you pay for the strong hosted models you are already using. Worse, K3 always reasons at maximum effort and there is no cheaper non-thinking mode to fall back to, and every reasoning token bills at the output rate. For a chatty agentic workload, your bill will run above what the sticker suggests, and if you are used to routing simple tasks to a cheap small model, that option does not exist here. The thirty cent cached input rate is real and it matters for anything that resends the same system prompt, but it does not rescue an output-heavy job.

The permanence argument also has a hole in it, and it is worth being straight about. Open weights guarantee the model can exist. They do not guarantee anybody will host it for you. If interest moves on in fourteen months and the providers quietly drop K3 from their catalogs, your escape hatch is a 1.4 terabyte file you cannot run. Permanence is real but it is conditional on somebody finding it worth serving, and the only version of this that is genuinely bulletproof is the one where you have the hardware, which brings us back to the eighteen accelerators. What you actually get is a much longer runway and a much better negotiating position, not immortality. That is still worth a lot. It is just not what the word "open" makes people feel.

Then there is the part nobody enjoys discussing in a procurement meeting. Moonshot is a Chinese lab, and for some of your customers or your compliance review that is a conversation whether or not it is a technical problem. The open-weight release genuinely defuses it in a way the API never could, because self-hosted weights send nothing anywhere, but that only helps if you are self-hosting, and you are not. Renting K3 from a US provider is a reasonable middle ground and it is the one most people will land on, but be honest with yourself that you are trusting the provider's infrastructure, not the model's nationality, and know which of those your reviewer actually cares about.

Last, the thing that breaks in month three. Benchmarks near the top of a chart tell you almost nothing about whether a model handles your specific mess: your field names, your abbreviations, the way your techs write up a service call. The only test that counts is fifty of your own records run through both models with the output compared side by side by somebody who knows what right looks like. That test costs an afternoon and it is the one step people skip, then six weeks later they are debugging a pipeline when what they actually had was a model that was never good at their particular thing. Run the fifty records. Every time.

There is a version of the last three years where the interesting question was which lab was ahead. That question got a lot less interesting last night, and the one that replaced it is whether the thing you built on Friday will still be running next spring.