Moonshot AI's Kimi K3 is the largest open-weight model yet shipped: a 2.8-trillion-parameter Mixture-of-Experts with a 1M-token context, native vision, and reasoning switched on by default. It stops being the cheap alternative and starts being a model you route to on capability. The catch: the sticker price jumped to $3 in and $15 out, so the whole cost case now rides on a caching architecture that keeps the effective rate far lower. This is our engineering read on the spec, the evals, the uses, and where K3 does and does not belong.
K3 is a 2.8-trillion-parameter Mixture-of-Experts with 896 experts and 16 active per token. Moonshot ships the weights open (release dated 27 Jul 2026), which makes this the largest openly-published model to date by a wide margin. It is a statement about how far open weights have come, not a niche curiosity.
K3 introduces Kimi Delta Attention (a hybrid linear attention mechanism) and Attention Residuals, plus a Stable LatentMoE routing framework. Moonshot reports roughly a 2.5x improvement in overall scaling efficiency over K2. This is the architecture story, and it is why a 1M-token context stays affordable to serve.
K3 replaces the K2.x thinking toggle with a reasoning_effort parameter, and it launches at max effort only (low and high are promised later). Native vision means it reads screenshots, diagrams, and UI, so vision-in-the-loop agent work is a first-class path rather than a bolt-on.
Headline pricing is $3.00 input and $15.00 output per million tokens, cache-miss. That is roughly the closed-frontier tier, not the tenth-of-the-price story K2.7 told. The lever is prompt caching: cache-hit input drops to $0.30, and Moonshot reports above 90% cache-hit rates on coding workloads, which pulls the effective bill 60 to 80 percent below the headline.
On long-horizon coding (SWE Marathon) K3 runs competitive with Claude Fable 5 and ahead of GPT-5.6 Sol. Across the wider suite it trails the very top closed models and has a visible UX gap: Moonshot itself flags over-proactiveness on ambiguous tasks and sensitivity to thinking-history preservation. We treat those as eval line items, not marketing.
The testing side. Reported and illustrative numbers, framed the way we frame every model: a starting point, not a verdict. The pattern is consistent, K3 clears K2.7 by a wide margin, leads the open-weight field, runs level with the closed leaders on long-horizon coding, and trails them on the hardest terminal, reasoning, and knowledge-work tasks. Read the deltas, not the decimal places.
| Capability | Kimi K3 | Kimi K2.7 | Claude Fable 5 | GPT-5.6 Sol |
|---|---|---|---|---|
Agentic coding SWE-Bench Verified | 76.8% +5.5 pts vs K2.7 | 71.3% | 79.5% | 78.9% |
Long-horizon coding DeepSWE mini-SWE-agent harness | 67.3% +7.7 pts vs K2.7 | 59.6% | 70.1% | 69.4% |
Multi-hour maintenance SWE Marathon K3 level with Fable 5, ahead of GPT-5.6 Sol | 62.4% +11.2 pts vs K2.7 | 51.2% | 63.0% | 59.8% |
Agentic terminal coding Terminal-Bench 2.1 | 71.0% +7.6 pts vs K2.7 | 63.4% | 77.2% | 78.4% |
Tool use MCP Atlas multi-step MCP orchestration | 74.6% +7.8 pts vs K2.7 | 66.8% | 77.0% | 75.9% |
Reasoning GPQA Diamond | 84.1% +5.5 pts vs K2.7 | 78.6% | 86.4% | 87.1% |
Math AIME 2026 | 93.2% +3.8 pts vs K2.7 | 89.4% | 94.0% | 94.6% |
Knowledge work SpreadsheetBench 2.0 office and data tasks | 68.9% +10.8 pts vs K2.7 | 58.1% | 71.2% | 70.0% |
Open-weight field Best open model on coding vs DeepSeek, Llama, Qwen | Leads | Prev. leader | Closed | Closed |
Figures are reported or illustrative and used for orientation only. Moonshot's own K3 report is candid that the model trails Claude Fable 5 and GPT-5.6 Sol on overall polish. We re-run our own evals on customer tasks before recommending any model, open or closed, and for K3 the cost advantage only holds once the caching hit rate is verified on your real traffic, not assumed from the coding benchmark average.
The impact side. What actually changes for an engineering team. Two comparisons that matter: K3 against the K2.7 it succeeds, and against a closed flagship (Claude Fable 5) on the dimensions a buyer weighs, capability, cost, control, and risk. The headline shift is that Kimi has moved out of the pure-value slot and into the frontier conversation, which changes when you reach for it.
| Dimension | vs Kimi K2.7 | vs Claude Fable 5 |
|---|---|---|
Coding workflows | +5.5 pts on SWE-Bench Verified, +7.6 on Terminal-Bench 2.1, and +11.2 on the multi-hour SWE Marathon vs K2.7. K3 holds context and recovers from failed steps across far longer agent runs, which is where the extra capacity earns its keep. | Fable 5 still leads on the hardest terminal and reasoning tasks, but K3 runs level with it on long-horizon maintenance and ahead of GPT-5.6 Sol there. For deep, multi-file refactors it is now a genuine alternative, not a fallback. |
Reasoning and long horizon | Reasoning is always on and thinking is preserved across turns, so complex tool chains derail less. The 1M-token context lets a single agent run hold a large codebase and a long transcript at once. | K3 trails Fable 5 by roughly 2 points on GPQA and by a similar margin on AIME. Close enough that on well-scoped tasks the difference rarely decides the outcome, wide enough that we keep a closed-model fallback for the genuinely hard reasoning steps. |
Cost structure | This is the trade-off, not a free win. K3 headline pricing ($3 / $15) is 5x to 6x K2.7's. The capability went up and so did the sticker. Whether K3 is cheaper end to end depends entirely on your cache-hit rate. | At the cache-miss headline K3 sits near Fable 5's tier. But cache-hit input at $0.30 with 90%+ hit rates on coding pulls the effective input cost an order of magnitude below the sticker. On a caching-friendly agent loop, K3 can undercut the closed frontier; on a cache-hostile one, it will not. |
Multimodal and knowledge work | Native vision is new to the line. K3 reads screenshots, diagrams, dashboards, and UI, so vision-in-the-loop agents (game dev, design review, chart reading) work without a separate model. K2.7 could not do this. | K3 opens the door to office and data workflows (spreadsheets, reports, browsing) via Kimi Work-style surfaces. It trails Fable 5 on polish here, but the open weights plus multimodal combination is a capability Fable 5 does not offer at all. |
Control and residency | Open weights, same as K2.7, but the operational reality is heavier: self-hosting a 2.8T MoE is a real GPU-fleet commitment, softened by MXFP4 weight quantization. Residency is possible; it is not a weekend project. | Fable 5 is API-only. K3's open weights let you run inference in your own environment for data residency, air-gapped work, or fixed-cost economics at scale, a capability a closed frontier model structurally cannot offer. |
Risk and provenance | Same China-origin diligence as the K2 line, now at larger stakes given the model's reach. Moonshot's own report flags over-proactiveness on ambiguous prompts and thinking-history sensitivity, which we probe directly. | A frontier-scale open model from a China-based lab carries different governance than a US closed API: licence terms, content-policy behaviour, and supply-chain review of weights you self-host. We treat those as eval and governance line items, not blockers. |
Inside a Kensink build, K3 is a routing option behind the same abstraction as Claude and GPT. The agent picks the model by task difficulty, cache economics, and modality at runtime, not by a vendor commitment frozen at design time. K3 raises the ceiling of what the open, self-hostable option can do; it does not remove the need to route.
The engineering headline. K3 is a Mixture-of-Experts with 896 total experts and 16 active per token, routed through a Stable LatentMoE framework. You get 3T-class capacity while paying to activate only a sliver of the network on each call, which is what keeps a model this large servable at all. The weights are published open (dated 27 Jul 2026), making this the largest openly-released model to date.
The AI-architecture side. KDA is a hybrid linear attention mechanism that improves information flow across a very long sequence; Attention Residuals selectively retrieve representations across model depth. Together with Gated MLA, Per-Head Muon, and a Sigmoid Tanh Unit activation, they deliver a reported 2.5x scaling-efficiency gain over K2, which is how the 1M-token context stays economical.
K3 reads up to 1,048,576 tokens and understands images natively. That suits codebase-scale tasks, long agent transcripts, and vision-in-the-loop work where the model looks at a screenshot, a diagram, or a rendered UI and acts on it. As always, retrieval and context hygiene beat stuffing the whole window, and we build for that.
The implementation side. K3 retires the K2.x thinking flag and exposes a reasoning_effort parameter instead. At launch it supports max only, with low and high promised later, so budget for the token cost of deep reasoning on every call until the lighter tiers ship. Thinking history is preserved across turns, which stabilises long tool chains but makes the model sensitive to how you manage that transcript.
The development side. Moonshot showcases K3 optimising GPU kernels, building a Triton-class compiler (MiniTriton) from scratch, running a 48-hour autonomous chip-design cycle, and driving game development through a vision feedback loop. Whether or not every demo generalises, the signal is that K3 targets long, deep, tool-heavy engineering work rather than single-shot completions.
Hosted input is $3.00 and output $15.00 per million, cache-miss, with cache-hit input at $0.30 and reported 90%+ cache-hit rates on coding. The economics only work if your workload reuses context, so the implementation job is to design the agent loop, shared preambles, and tool schemas to maximise cache hits. We instrument the hit rate and treat it as a first-class cost metric.
K3 ships across Kimi.com, the Kimi API, a Kimi Code coding surface, and Kimi Work, a desktop knowledge-work agent with local file access, a cron engine, browser automation, and agent-swarm coordination. For our builds the API is the integration point; the product surfaces are useful references for what Moonshot considers the model's home turf.
The self-host story. Weights ship in MXFP4 with MXFP8 activations, which cuts the memory footprint of a 2.8T model enough to make on-prem serving tractable for teams with real GPU capacity. It is still a serious infrastructure commitment, not a drop-in, but the openness is genuine and the quantization is what makes it usable.
K3 speaks an OpenAI-compatible chat-completions surface with function calling, tool_choice, and streaming, so adding it next to Claude and GPT in our provider layer is a config change plus an eval pass, not a rewrite. The one migration note: swap the old thinking toggle for reasoning_effort in the adapter.
The headline is the economics. Frontier-class agentic coding at a fraction of the closed-leader per-token price, plus open weights you can run yourself.
The K2 line's entire pitch was frontier-adjacent coding at a tenth of the closed price. K3 breaks that framing: at $3 input and $15 output cache-miss, the sticker sits in the same neighbourhood as the closed leaders. The cost advantage is real but conditional, it lives entirely in the caching architecture and only materialises on context-reusing workloads with high cache-hit rates. Anyone quoting the old tenth-of-the-price line for K3 is quoting a stale model. We size the real number against your actual cache behaviour.
The K3 report is unusually candid: the model is sensitive to whether thinking history is preserved, it can be excessively proactive on ambiguous tasks (doing more than asked), and there is a noticeable user-experience gap versus Claude Fable 5 and GPT-5.6 Sol. These are not fatal, but they are exactly the failure modes that a coding-benchmark average hides. We probe proactiveness and instruction-adherence directly in the eval suite rather than trusting the headline scores.
Publishing 2.8T parameters openly is a genuine statement, and MXFP4 quantization makes on-prem serving tractable rather than theoretical. But the number of teams that can stand up a fleet to serve a model this size is small, so for most buyers the openness matters as optionality (residency, exit rights, auditability) more than as day-one self-hosting. That is still valuable, it is just a different value than the K2 line's easy self-host story.
K3's origin and reach raise fair questions: licence terms, content-policy and refusal behaviour, and supply-chain review of weights you self-host. We handle these as concrete eval and governance items, content-policy probes in the eval suite, licence sign-off, and provenance checks, rather than as a blanket yes or no. For many product workloads it clears the bar; for some regulated ones it will not, and we say so plainly.
For the K2 line we asked whether the cheap open model was good enough. For K3 the question is different: it is a frontier contender, so we route to it on capability and modality (long-horizon coding, vision-in-the-loop, self-host residency) and prove the cost with caching, rather than assuming Kimi means savings.
K3's economics are made or broken by cache-hit rate. The engineering work is designing the agent loop, stable system preambles, and tool schemas so context is reused, then instrumenting the hit rate as a first-class metric. Ship that discipline and K3 can undercut the closed frontier; skip it and you pay closed-frontier prices for an open model.
Moonshot's own honesty about over-proactiveness and thinking-history sensitivity is a gift: it tells you exactly where to point the eval suite. We measure instruction adherence and interruption behaviour on real customer tasks before K3 touches a production path, because those are the traits a benchmark average will not surface.
K3 is one more option in our vendor-neutral provider layer. The agent picks K3, K2.7, Claude, or GPT by task difficulty, cache economics, and modality at runtime. That keeps the frontier capability and the self-host optionality on the table without a lock-in, and keeps a closed-model fallback for the steps that still need it.
Every model we integrate runs through the same operating system. Three pillars, sixteen layers, one Compound Growth Loop. The methodology that keeps AI work from rotting after the first ship.
Read the K-FrameworkDirect API integration with the model. No LangChain, no orchestration vendor, no agent framework built on quicksand. Typed contracts, the same way we wire up Postgres.
An eval suite built from your real tasks gates every prompt and model change. Quality is measured before it ships, not vibed in a demo.
Governance, audit, and oversight wired in from day one. Who called what, with which prompt version, at what cost. Your auditors get answers, not screenshots.
A model in production without observability is roulette. We instrument every integration so engineering and finance can see the same numbers, and so a regression at 3am surfaces before a customer opens a ticket.
Tokens in, tokens out, dollars spent. Sliced by feature, tenant, and route. Budgets enforced where it matters.
Real distributions, not averages. We know which routes are slow, and why.
The same eval suite that gates a release runs continuously in production. A regression on real traffic surfaces fast.
PII scrubbed at the proxy, shipped to your SIEM. Retention controls match your compliance window.
Dashboards your team owns, not ours. At handoff you get the queries, the alerts, and the runbook. We are not in the path to read your metrics.
