Kimi K3 Review: The 2.8T Open Model That Beats Claude on Paper

TL;DR

Kimi K3 is the largest open-weight model anyone has shipped: 2.8 trillion parameters, a million-token context, and a price that undercuts Claude by roughly 3x. On the leaderboards it beats Claude Fable 5 at frontend coding and lands third overall on GDPval, which is genuinely impressive for weights you can download. After a week of feeding it real Go and Python work, the picture got messier. It's slow, it invents APIs that don't exist more often than any frontier model I've used this year, and most of its headline numbers are still Moonshot's own. Worth running for cost-sensitive batch work; I would not hand it an unsupervised agent loop yet.

Why I bothered testing this one

I review a lot of models and most open-weight releases don't survive contact with a real repo. DeepSeek V4 Pro and GLM-5.2 were the two that did. Both were cheap, competent, and good enough that I kept them in rotation for grunt work. When Moonshot dropped Kimi K3 on July 16 and the first benchmark screenshots showed it ahead of Claude Fable 5, I moved it to the top of my testing queue.

I ran K3 through the API (OpenRouter forwards to Moonshot's single hosted endpoint right now) for about a week: a Go service refactor, a pandas-to-Polars migration, a batch of PR reviews, and the usual pile of "explain this stack trace" prompts. I paid for the tokens myself, so the cost math below is real. What follows is what the leaderboards don't tell you: where a 2.8T open model actually helps, and where it quietly wastes your afternoon.

One caveat up front, and it's a big one: at the time of writing, the open weights aren't public yet. Moonshot says they land July 27, ten days after launch, under a modified MIT-style license. Everything in this review is based on the hosted API. If the weight release slips or the license has teeth, half the appeal evaporates.

What Kimi K3 actually is

Kimi K3 is a Mixture-of-Experts model with about 2.8 trillion total parameters. Moonshot reports 896 experts with 16 active per token, which is why a model this size can serve at Sonnet-ish prices: you only pay to run a sliver of it on each forward pass. The context window is 1,048,576 tokens, the same 1M ballpark the Gemini line reaches, and it's tuned hard for long-horizon coding and agent loops rather than chat.

At launch there are two variants: K3 Max for interactive chat and agent tasks, and K3 Swarm Max for large-scale parallel processing. Most people will only touch K3 Max. Swarm Max is aimed at the "fan out 200 requests and merge" workloads that batch pipelines and eval harnesses generate.

The "largest open-weight model ever" line is doing a lot of marketing work, but it's accurate. Nothing else with downloadable weights comes close to 2.8T. Whether you can run it locally is a separate question I'll get to.

Getting it running

The API is a plain OpenAI-compatible endpoint, so if you already have code hitting GPT or Claude, swapping in K3 is a two-line change. Here's the exact call I used to smoke-test it:

import os
from openai import OpenAI

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

resp = client.chat.completions.create(
    model="moonshotai/kimi-k3",
    messages=[
        {"role": "system", "content": "You are a senior Go engineer. Be terse."},
        {"role": "user", "content": "Write a worker pool in Go 1.26 that "
                                    "processes a channel of jobs with N workers "
                                    "and returns the first error via errgroup."},
    ],
    temperature=0.2,
)

print(resp.choices[0].message.content)
print("tokens:", resp.usage.total_tokens)

Output on my run (trimmed):

package main

import (
    "context"
    "golang.org/x/sync/errgroup"
)

func Process(ctx context.Context, jobs <-chan Job, n int) error {
    g, ctx := errgroup.WithContext(ctx)
    for i := 0; i < n; i++ {
        g.Go(func() error {
            for {
                select {
                case <-ctx.Done():
                    return ctx.Err()
                case job, ok := <-jobs:
                    if !ok {
                        return nil
                    }
                    if err := job.Do(ctx); err != nil {
                        return err
                    }
                }
            }
        })
    }
    return g.Wait()
}

tokens: 512

That's correct, idiomatic, and closes over the loop variable safely (Go 1.22+ semantics). No complaints on the code itself. The complaint is what the timer showed: that response took noticeably longer than the same prompt to Fable 5 or GPT-5.6. Which brings me to the thing the leaderboards bury.

The speed problem is real

Every hands-on account I've seen, including mine, lands on the same finding: K3 is slow. The New Stack ran a coding comparison and clocked it at roughly 4x slower than Claude Fable 5 on equivalent tasks. My informal timings weren't that clean, but "meaningfully slower" is not in dispute.

For an interactive agent loop, 4x slower is disqualifying. When I'm iterating with a coding agent, latency is the whole experience. A tool call that takes six seconds instead of two turns a ten-minute session into forty. I stopped using K3 for anything conversational within a day.

Where the slowness stops mattering is batch work. If you're running a nightly job that summarizes 5,000 support tickets or generates first-draft docstrings across a monorepo, nobody's watching the clock. There, K3's price does the talking. That split defines the whole model: great for offline, painful for interactive.

The benchmarks, with the asterisks attached

K3 earned its headlines on the benchmarks. As VentureBeat's launch coverage laid out, these are the numbers being quoted, and I'm labeling every one of them as reported, because most trace back to Moonshot's own eval runs or single-leaderboard placements rather than broad independent replication.

Two things stand out. First, beating Claude Fable 5 on the Frontend Code Arena is a real result. Arena runs are human-preference votes on built UIs, and that one leaderboard is independent of Moonshot. Second, on GDPval it lands behind the top closed models but ahead of Opus 4.8, which is the fair "third place, and that's still very good for open weights" framing.

The SWE-bench figure needs the most salt. "65–67% in scaffold-assisted settings" means with a coding harness doing retries and test feedback around it. Bare-model SWE-bench numbers are always lower, and Moonshot hasn't published a clean methodology at the time of writing. Treat it as "strong tier," not a precise ranking against a specific competitor.

Kimi K3 vs Claude vs GPT: the head-to-head

Most people searching for K3 are really asking one question: should I use this instead of Claude or GPT? Here's the head-to-head that reflects a week of use plus the public data.

K3 and Fable 5 prices are published/reported rates; GPT-5.6 figures are approximate.

On raw coding quality for a single well-scoped task, K3 is close enough to Fable 5 that you would not reliably tell them apart in a blind read. The New Stack's summary of "same results, one-third the cost, four times slower" matches my experience almost exactly: Fable 5 runs about $10 in and $50 out per million tokens, so K3's $3/$15 really is the cheaper column. If your bottleneck is API spend and not wall-clock time, that trade is a bargain.

The gap opens up in agent loops. Fable 5 and GPT-5.6 recover from their own mistakes; they read a failing test, form a theory, and fix it. K3 is more likely to double down on a wrong assumption, which is a known failure mode I dug into in the piece on multi-agent error cascades. If you want the current best-in-class agent, the Claude Fable 5 review still holds. K3 wins on price; Fable 5 wins on recovering from its own mistakes. Anyone doing head-to-heads through the Anthropic API will feel that difference within a session.

Where it falls apart: hallucination

This is the part that kept K3 out of my daily rotation. Independent testing has put its hallucination rate around 51%, up from a reported ~39% on its predecessor. I don't have a way to reproduce that exact figure, but the qualitative pattern showed up fast.

Twice in a week, K3 confidently used APIs that don't exist. In one pandas migration it wrote pd.read_parquet(path, engine="polars") as though pandas ships a Polars backend — it doesn't. In a Go task it referenced a stdlib helper that isn't in the standard library at all. Both times the surrouding code was clean and plausible, which is exactly what makes it dangerous: the wrong line reads as confidently as the right ones. A less careful reviewer merges it.

For a human-in-the-loop workflow where you read every diff, this is an annoyance you can catch. For an autonomous agent that writes, runs, and commits without a person checking each step, a coin-flip hallucination rate is a hard stop. The benchmark wins and this number live in tension, and you can't take one seriously without the other.

Pricing and how to run it

Through the API, K3 costs $3 per million input tokens on a cache miss, $0.30 per million on a cache hit, and $15 per million output tokens. That's Sonnet-class pricing for a model posting near-frontier coding scores, which is the entire pitch.

Local is the harder story. The weights drop July 27, but 2.8T parameters is not something you run on a workstation. Even at MoE's reduced active-parameter cost, you need serious multi-GPU hardware or a quantized community build to load it at all. "Kimi K3 on Ollama" is one of the top autocompletes for the model, and the real answer for now is: not on consumer hardware, and not on day one. Watch the Hugging Face repo and the quantization community; a usable GGUF will show up eventually, but it won't be quick. If you want a model you can actually run on a Mac today, Apfel is a far more realistic pick. Different weight class, but it fits in memory.

Who should use it, who should skip

Use Kimi K3 if: you run large offline batch jobs where cost dominates and latency doesn't, you want to hedge against closed-model lock-in, or you plan to self-host once the weights and a viable serving stack exist. The price-per-quality on non-interactive work is the best I've measured this quarter.

Skip it if: you want a snappy interactive coding assistant (Fable 5 or GPT-5.6, no contest), you're building an unsupervised agent where a hallucination becomes a committed bug, or you need a model you can run locally this week. For most solo developers writing code interactively, the slowness alone rules it out.

FAQ

Is Kimi K3 open source?

The weights are open; the training data and full pipeline are not. Moonshot says the weights ship July 27, 2026 under a modified MIT-style license (the same approach as Kimi K2.6), which makes K3 open-weight rather than fully open-source. You can download and run the model, but you can't fully reproduce it.

Is Kimi K3 better than Claude?

On some coding leaderboards, yes: it reportedly tops the Frontend Code Arena ahead of Claude Fable 5. In day-to-day use it's competitive on single-task code quality but slower and more prone to hallucination, so Claude remains the stronger pick for interactive and agentic work.

How much does Kimi K3 cost?

API pricing is $3 per million input tokens ($0.30 on cache hits) and $15 per million output tokens, roughly a third of what comparable closed models charge for similar coding quality.

Can you run Kimi K3 on Ollama or locally?

Not on consumer hardware. At 2.8T total parameters it needs substantial multi-GPU infrastructure even as a Mixture-of-Experts model. Quantized community builds may make smaller-scale local runs possible after the July 27 weight release, but there's nothing practical for a laptop at launch.

How many parameters does Kimi K3 have?

About 2.8 trillion total parameters in a Mixture-of-Experts design, with roughly 896 experts and 16 active per token, so only a small fraction runs on any given forward pass, which is what keeps inference costs down.

Sources

• Kimi K3 on OpenRouter — official API pricing and hosting details
• China's Moonshot AI releases Kimi K3, the largest open-source model ever — VentureBeat — launch coverage, specs, and benchmark placements
• Moonshot releases 2.8-trillion-parameter Kimi K3 — Tom's Hardware — architecture and Frontend Code Arena result
• Claude Fable 5 vs Kimi K3: same results, one-third the cost, 4x slower — The New Stack — independent coding comparison, latency, and pricing
• Kimi K3 — DataCamp — model overview, variants, and open-weights timeline
• Kimi K3 beat Claude and GPT at coding — why can't you fully trust it? — Memeburn — reported hallucination-rate testing

Bottom line

Kimi K3 is the most impressive open-weight release of the year and, for a specific job, a genuine bargain. If your workload is offline, cost-bound, and human-reviewed, download it the moment the weights land and point your batch jobs at it. But the leaderboard story and the daily-driver story are two different reviews. On the benchmarks it beats Claude; at my keyboard it was slow and it lied to me twice in a week. I'll keep it for batch grunt work and reach for Fable 5 the moment a task actually needs to be right.