Claude Code running Moonshot AI's Kimi K3.

Kimi K3 is Moonshot’s new 2.8-trillion-parameter mixture-of-experts model. I tested Kimi K3 in Claude Code to see whether those specifications mattered in a familiar workflow. Its parameters are values learned during training. Because K3 uses several specialised components, only part of the model handles each token. It also accepts images and up to one million tokens of context in a request.

Together, those learned parameters form the model weights. Open weights are available for others to download and run. This is narrower than open source, which usually also provides training code and data.

Moonshot described K3 as the first model at this scale announced for an open-weight release. On July 19, 2026, those weights were not yet available. Moonshot said it would release them by July 27. Its launch post was unusually candid about the remaining gap. K3 still trailed Fable 5 and GPT-5.6 Sol overall, and its user experience was weaker.

As I wrote this article, Alibaba announced Qwen 3.8, another large model intended for open-weight release. Thinking Machines Lab had also released Inkling, a US model with full weights available. Inkling has 975 billion total parameters and activates 41 billion for each token. Kimi is not a one-off anymore. There is now a queue.

I have burned millions of tokens through Claude Code by now. It is the agent harness that connects a model to files, tools, and coding tasks. My configuration works, the tools are where I expect them, and I know the rhythm of the harness.

I kept Claude Code and changed only the model behind it. OpenRouter, a request-routing service, sent the requests to Kimi K3.

Claude Code configured to use Moonshot AI's Kimi K3 through OpenRouter.

First impression in Claude Code: slow

It felt slow. Very slow, at first. That was odd because third-party measurements pointed the other way. Artificial Analysis reported speed in output tokens, the small units of a model’s response. Around July 19, 2026, it measured about 62 per second for Kimi K3 and 57 for Claude Opus 4.8. K3 also began its responses sooner.

Maybe the difference was time spent reasoning before useful text appeared. Maybe it was the cadence of the stream. Maybe I have used Claude Code long enough that any different rhythm feels wrong. (Or maybe routing through OpenRouter was the cause.)

Then, somewhere during the first hour, I stopped noticing. K3 had not suddenly become faster. It handled files, edits, and tool calls well enough that I forgot where the traffic was going.

A quick Kimi K3 frontend test

K3 was getting attention for frontend work when I tested it. It ranked first on Code Arena around July 19, 2026. Code Arena is a public leaderboard for generated web interfaces. I wanted a visual test rather than another coding benchmark. A benchmark is a standard task used to compare models.

I reused the detailed prompt and original assets from this Lafys build. I assume the reference used Fable 5, although I cannot verify that.

Reference design on the left and Kimi K3 reconstruction of the Productivity section on the right.
Reference design on the left and Kimi K3 reconstruction of the Flexibility section on the right.
Reference design on the left and Kimi K3 reconstruction of the Unify Teams section on the right.
Reference design on the left and Kimi K3 reconstruction of the Team Created section on the right.

I know this is one run, with very specific instructions and the original assets. Give the model a vaguer prompt and the result may fall apart. I did not run a control trial or calculate an objective similarity score.

Kimi K3 cost in Claude Code

The OpenRouter export covered 115 requests. It logged 13.64 million prompt tokens carrying instructions and context, plus 82,307 output tokens carrying model responses. Of those prompt tokens, 12.95 million were cache hits, which reuse earlier input at a lower price. Nearly 95% of the prompt tokens were cached. Total cost: $7.18.

I then applied Anthropic’s published list prices to that recorded traffic mix. The calculation gives about $11.96 for Claude Opus 4.8 and $23.92 for Claude Fable 5. These are estimates, not bills from separate Claude runs. The other models might generate different token volumes or cache patterns.

Under this fixed-mix assumption, Kimi was roughly 40% cheaper than Opus and 70% cheaper than Fable.

Is Kimi K3 a Claude Opus replacement?

No. Not for me.

Opus still feels more dependable when the work gets difficult. It is better at knowing when to stop and at handling ambiguity. It is also less likely to make an energetic decision I did not ask for.

Moonshot listed excessive proactiveness and sensitivity to the surrounding software among K3’s limitations. That matches parts of my experience.

I would not call K3 a Fable 5-class model either.

But below Fable and Opus the air gets thin very quickly. K3 is close enough that many users may not care about the remaining difference. Others may care less about that gap than the price.

So where do we go from here?

In the days before July 19, 2026, the takes went in every direction.

Kimi K3 is the end of the American model moat. Kimi K3 is benchmark theatre. Open weights make closed models obsolete. Open weights are irrelevant if running the thing costs a small data centre. China is deliberately commoditising the layer on which a large part of the US market is now betting. Or there is no master plan and Chinese labs are releasing good models because good models bring developers, usage and prestige.

A less dramatic list from my notes looks like this:

  • $/token is a poor comparison when models use very different numbers of tokens.
  • Public benchmarks are easier to optimise for and may not separate the best models well.
  • Open weights put a ceiling on API prices even if most users never self-host.
  • The model is becoming replaceable; the harness, data and workflow may not be.
  • Value may move up into applications and down into chips, power and the systems that serve model responses.
  • Open weights help with control and privacy, but “open” does not mean cheap to run.
  • Export controls can slow Chinese labs and, at the same time, give them a reason to build around the US stack.
  • The biggest threat is not necessarily that Kimi becomes number one. It is that nobody stays number one for long.

As of July 19, 2026, Epoch AI estimated that the best open-weight models trailed the most capable closed models by only a few months. The exact gap depends on the benchmark, so public evaluations require care. Still, a short lag lets buyers wait, switch, or split workloads across providers. Personally, I think this can be distilled, yes, I know, into a threat and an opportunity.

The threat

The threat is not that Kimi K3 is better than every American model. It is not.

The threat is that K3 may be good enough to make the premium harder to defend.

The large US labs are valued on more than technical competence. Their financial case assumes that frontier intelligence remains scarce and that the lead lasts. It also assumes that customers keep paying high margins for access.

A model can damage that story without taking first place. It only needs to remain close enough to the frontier at a lower price. Existing software must also accept it easily.

That is a bad combination for pricing power: a seller’s ability to maintain high prices. It also weakens the model moat, the durable advantage that protects those prices.

Most enterprise software is sticky because switching is awful. Databases, operating systems, and core banking platforms accumulate years of dependencies. A language model behind an application programming interface (API) is different. The API already lets software exchange requests and responses with another system. The model may be important while remaining surprisingly easy to replace. My Claude Code test is the small version of that.

Closed labs still have ways to earn the premium. Reliability, tool use, and enterprise controls matter. Being six months ahead can be worth a lot when the task is valuable enough.

The timing is awkward because the infrastructure bill is enormous. I examined it in AI Capex Arms Race: Who Blinks First?. Capital expenditure (capex) buys long-lived assets such as data centres and graphics processing units (GPUs). Depreciation spreads an asset’s cost across its useful life. The unresolved issue is how much revenue must arrive, and how quickly, to support these assets and their debt.

If model capability commoditises faster than revenue grows, the damage does not stop at the labs. It reaches large cloud providers, chipmakers, data-centre developers, utilities, and their lenders. A cheaper Kimi is good for users and potentially bad for whoever underwrote scarcity.

The same substitutability also weakens export-control leverage.

The US controls much of the closed-model frontier and the hardware underneath it. That creates leverage while other countries depend on the same stack. Restricting chips and APIs may preserve the lead, but it can also make a parallel stack more valuable.

I examined the other side in Krugman, Fable 5, and Europe in Decline?. A provider or its government can cut off a closed model. Once operators have distributed open weights, nobody can switch them off in the same way. K3’s promised weights were not yet available on July 19, 2026.

There is another, more mundane risk: we may be overrating the model.

Every launch now comes with a dense page of benchmark wins. Some use different harnesses, budgets, or settings chosen for one model. Others are saturated, so top scores cluster too closely to distinguish models. A model that looks brilliant on a leaderboard can still be unpleasant over a long session.

The opportunity

At lower prices, more tasks become worth attempting. Agents combine models and tools to complete those tasks. They can take more passes, read more context, and handle work that does not justify Fable pricing. Lower unit costs may not shrink the market at all.

What interests me more is separation. The interface, agent, and model do not have to come from the same company.

A routine refactor can go to a cheaper model. A difficult architecture decision can go to Opus. Sensitive material can stay on a private deployment. Frontend work can go to whichever model happens to be best at it that month.

The durable product may be the surrounding workflow rather than any single model. Its router selects a model, while its context layer supplies the right information. A validation loop checks the result and sends corrections when needed.

Open weights also matter beyond price. An organisation can fine-tune them for a specific task or quantise them to reduce hardware needs. It can then run the model on premises, under its own controls.

Private deployment changes who answers the hard operational questions. Data residency covers where processing and storage occur; retention covers how long data remain stored. Continuity asks whether the service survives supplier or network failures. Local control does not automatically make a deployment secure or compliant.

So what?!

I do not think Kimi K3 kills Anthropic. I do not think one frontend reconstruction proves parity. On July 19, 2026, I would still choose Opus for the hardest coding work.

But K3 was good enough that I forgot I was using it. It cost materially less. It ran inside the harness I already liked. Moonshot said the weights would be available by July 27 to anyone willing to provide the hardware.

Closed labs now need a lead that is large enough to matter and durable enough to defend. They also need customers who will keep paying for each extra gain as switching becomes routine.

For the operational version of this argument, read Put the Model in the Basement. It tests a Swiss business case built around data residency, control and continuity.