I’ve been running Kimi K3 on a real project for the past week. It’s now one of my go-to models alongside Claude, but it’s not a drop-in replacement.
Kimi K3, released by Moonshot AI last week, is the first open-source model I’ve used that can hold a serious engineering conversation at the architecture level. Not code completion. Not boilerplate. Actual system design with trade-off analysis and implementation rationale.
After running it for several days on a real project, here’s my honest builder take.
Instruction Following
Instruction following is on par with Opus. When you set boundaries in your prompt, it respects them strictly. No slipping, no “creative reinterpretation.” Combined with its reasoning capability, that’s what makes K3 stand out.
I’ve been running it on a fresh project specifically to avoid context pollution from my other work. The model follows complex, multi-layered instructions with precision. If I specify architectural constraints, naming conventions, or design patterns to follow, it adheres to them consistently across long sessions.
Data Analysis
General data investigation and statistical analysis has reached the same level as Fable. Whether it’s strictly better I can’t say, but it’s on the same line now. That was unthinkable six months ago.
I’ve thrown real datasets at it, asked it to identify patterns, run comparisons, and synthesize findings. The quality of analysis is genuinely surprising for an open-source model. It’s not just regurgitating statistics, it’s making meaningful observations that inform actual decisions.
Long Coding Sessions
For long coding sessions, it surpasses Opus and feels on par with Fable. Three caveats worth noting: overload errors can interrupt long-running tasks, so you need proper retry logic with backoff. K3 inherits a quirk from the 2.x series where it occasionally outputs only thinking tokens with no actual content, then stops. And in certain scenarios, K3’s tool calling can enter logic loops, burning through tokens without making progress. These are post-training problems that could be further optimized, not just harness issues. For now, your harness needs to handle them: detect empty outputs, break loops, and manage retries. Kimi Code itself handles these scenarios well, so there are good reference implementations to learn from. Not perfect, but solvable, though token consumption adds up fast.
This is where K3 genuinely surprised me. Sustained, multi-file implementation work, where the model needs to maintain consistency across dozens of files and remember architectural decisions from earlier in the session. It handles this remarkably well.
Cache and Cost
One thing to be aware of: K3’s cache mechanism needs to be properly matched in your harness, or cache hit rates will be poor. Without careful cache key management, you lose the cost advantage. And subscription credit consumption is noticeably faster than Claude and Codex. If you’re running long sessions with heavy tool use, budget accordingly.
On the positive side, I was initially worried about performance degradation as context grows. So far it holds up reasonably well. There is some decline, but nothing dramatic. Better than I expected for a model at this stage.
The Bigger Picture
The bigger picture is what interests me. People are now openly discussing how to restrict Chinese open-source models. A year ago the conversation was “are they any good.” Now it’s “how do we contain them.” When the policy discussion shifts that fast, you know the technology has crossed a threshold.
For builders, this changes the math. K3’s API pricing is competitive, and the model capability is already at the frontier level. Once these post-training issues get optimized, it should become a serious competitor to Claude and Codex. Not a replacement yet, but the gap is closing fast.