Kimi K3 Open Weights Landed: Specs, Caveats, and What to Do Next
July 28, 2026 · AI Models
In mid-July, Moonshot AI said full Kimi K3 weights would ship by July 27, 2026.
The repo is live at moonshotai/Kimi-K3 under the Kimi K3 License. The calendar held. Open-weight promises are common. Timed delivery is less common.
After the feed cooled down, builders still need answers with units attached: which model-card numbers drive cost, how to read the official benchmarks without harness noise, whether the license covers your commercial shape, and whether self-hosting belongs on this quarter's plan.

What shipped
From the Hugging Face model card and Moonshot materials, K3 is:
- open-weight, native multimodal, agentic
- 2.8T total parameters, about 104B activated
- described as open 3T-class
- up to about 1M context tokens
- aimed at long-horizon coding, knowledge work, and tool use
- released under the Kimi K3 License
This is a downloadable path for a model that sits on the same comparison tables as closed frontier systems. Tom's Hardware puts it more bluntly: teams with serious GPU racks get closer to selling their own inference.
One line still belongs near the top: a download does not put this model on a laptop.
How to read the card
| Dimension | Official model card | | --- | --- | | Architecture | MoE | | Total parameters | 2.8T | | Activated parameters | 104B | | Layers | 93 | | Experts | 896 | | Experts selected per token | 16 | | Shared experts | 2 | | Attention | KDA + Gated MLA (69 + 24) | | Context length | 1,048,576 tokens | | Vision encoder | MoonViT-V2 (~401M) | | Quantization | MXFP4 weights / MXFP8 activations | | Modalities listed | Text, Image |
In MoE systems, total parameters look like warehouse capacity. Runtime cost tracks activated parameters, context, KV cache, parallelism, and quantization. K3 lights about 104B parameters per token and routes to 16 of 896 experts. Moonshot claims about 2.5× better scaling efficiency than K2.
Two facts hold together. K3 is more deployable than a dense 2.8T model. 104B activated plus long context and multimodality still looks like a rack or cluster problem.
Capacity planning should start with activated params and quantization, the context length you will serve, agent concurrency from multi-turn tool use, and MoE communication cost. Put the poster number second.
Why the noise is high
Moonshot gave a date and hit it. API and product access arrived around July 16. Weights arrived by the July 27 window. That sequence rebuilds trust faster than another polished score table.
The open-weight conversation also moved up a weight class. Earlier debates often stayed at mid-size models or hundred-billion near-frontier systems. K3 forces a peer-table question: can open weights sit next to closed frontier options in the same review.
The product pitch centers on long work sessions: large-repo navigation, terminal tool use, kernels, compilers, CAD-class tasks. In 2026, many teams care more about multi-hour completion rates than chat polish.
Buyers will notice. If Terminal-Bench, BrowseComp, and MCP-related scores stay close to closed models, procurement will ask what the closed-model premium is buying: capability, reliability, compliance, or habit. That will not empty every enterprise API contract. It will put open weights back on the formal scorecard.
Benchmarks and footnotes
The card compares K3 with Claude Fable 5, GPT-5.6 Sol, Claude Opus 4.8, GPT-5.5, GLM-5.2, and others. Official numbers that stand out:
- GPQA Diamond: 93.5
- Terminal-Bench 2.1: 88.3
- BrowseComp: 91.2
- SWE-Marathon: 42.0
- MCPMark-Verified: 94.5
Swap Kimi Code for Claude Code or Codex and the same model can move a lot. K3 often runs at max reasoning effort with temperature 1.0. Peers use fallbacks, refusals, or other effort modes. Independent checks are still catching up. Vendor tables help. Open weights matter because the community can reproduce, attack, and distill.
A narrow product takeaway holds: on coding, agent, and tool-use axes, open weights now make closed-model shortlists. Full replacement is a different claim.
Who pays for what
Indie builders and small teams should not celebrate a 2.8T home download first. Hosting vendors will race to offer K3 routes. Long jobs with heavy tool use may get cheaper open-weight options. Private adaptation becomes more realistic if the license allows it.
A boring path works: run your own regressions on managed APIs; keep the agent harness fixed across Claude, GPT, Gemini, and K3; only price self-hosting when residency, unit cost, or control become hard constraints.
Product and platform teams will push multi-model routing harder. Harness quality rises in value: context control, tool permissions, stop conditions, audit logs. Eval work should leave leaderboards and return to your repos, tickets, knowledge bases, and known failure cases.
Stronger planners raise a different risk: a well-formed request can still trigger a side effect nobody authorized. We covered that gap here: Validation Is Not Authorization.
Infra and procurement can add rows for license fit, runtime maturity, MoE networking and failover cost, red-team and tool authority, plus tracing and cost attribution. Without those rows, teams buy a strong model and inherit an unoperable service.
Misreads to drop early
Downloadable weights leave training data, training code, and alignment process off the table. K3 uses the Kimi K3 License. Read the LICENSE before production.
Local inference still bills storage, bandwidth, GPUs, ops, eval, and security. The release changes cost structure and control.
Enterprise workflows fail on tool reliability, long-context consistency, auditability, tail latency, and recovery. No single scoreboard settles those.
Better planning and tool use also raise unauthorized side effects. More teams will put strong models inside private networks. Agent stacks that treat valid request shape as permission will scale risk with capability.
A one-week decision loop
You do not need a finished ecosystem. You need a memo.
- Freeze about 20 real tasks: code fixes, repo QA, research, sheets and docs, internal tools.
- Test K3 managed API under your current agent harness.
- Log loops, permission slips, context loss, and mid-task drift.
- Measure cost per successful task, not token sticker price.
- Read the license for commercial use, hosted service rules, and derivative models.
- Try a small router: cheap path for low-risk work, high-constraint path for high-risk work.
- Write the decision: self-host this quarter or not, K3 as a second route or not, which workflows stay human-approved.
That beats an all-hands slide that says the team is monitoring K3.
Near-term map
Hosting platforms will fight for day-0 support. Community threads will cover quantization, reproduction, and whether anyone can run it cleanly. Closed labs will answer with reliability, safety, and ecosystem lock-in.
Over the next couple of quarters, multi-model stacks with stronger harnesses will look like the default. Open weights will take execution volume. Closed models will keep high-risk decisions. Agent products will compete less on logos and more on completion rate and governance.
If open-weight systems keep shipping on schedule and stay competitive on agentic work, scarcity moves from owning a model to running models with control, stability, and unit economics that hold. Eval harnesses, permission systems, and inference ops become the scarce layer.
FAQ
What is Kimi K3, and are the weights public?
Kimi K3 is Moonshot AI's 2.8T-class open-weight multimodal agentic model. Moonshot committed to full weights by July 27, 2026. The weights are on Hugging Face as moonshotai/Kimi-K3 under the Kimi K3 License.
How big is Kimi K3, and can I run it locally?
About 2.8T total parameters, about 104B activated, 16-of-896 expert routing, and up to about 1M context tokens. Runtime cost depends on quantization, context, concurrency, and MoE networking. Consumer single-GPU setups are a weak fit. Managed hosting or rack/cluster inference is the realistic path.
Can Kimi K3 replace Claude or GPT for my product?
On some coding, browsing, and tool benchmarks, official numbers put K3 near closed frontier systems. Replacement depends on harness quality, latency, compliance, safety policy, and failure cost. Multi-model routing is safer than a hard cutover.
Should I self-host as soon as weights land?
Most teams should not. Start with managed APIs and workflow regressions. Self-host when residency, unit economics, customization, or control become hard constraints. Open weights expand the option set first.
Is the Kimi K3 License the same as Apache or MIT?
No. Use the official LICENSE text. Confirm commercial use, redistribution, hosted-service rules, and derivative-model terms before launch.
Close
K3 is loud because three facts stacked: open weights entered a 3T-class story, an open-weight promise became a checkable delivery, and agentic workloads became the main arena.
Most teams need a decision, not a slogan. Put K3 into your eval suite, cost model, and permission boundary. Take one week. Write the memo.
Models will keep getting stronger. The gap stays here: can you put a strong model inside a system that is observable, authorized, and reversible.
Related reading
- Validation Is Not Authorization: The Real Security Gap in AI Agent Frameworks
- Agentic Engineering vs Vibe Coding
- WindFlash AI Daily Report
Primary sources