Kimi K3 on CloudCode.ONE: The First Open 3T-Class Model, and What It Actually Takes to Run It
Kimi K3 on CloudCode.ONE
Moonshot has released Kimi K3, and it is the largest open-weight model anyone has shipped: 2.8 trillion parameters, a 1-million-token context window, and native vision built into the model rather than bolted on afterwards.
The headline number is fun. The interesting part, if you actually run coding agents for a living, is further down the announcement — in the architecture notes and the limitations section. That's where this post spends most of its time.
The specs that matter
|
Kimi K3 |
| Parameters |
2.8T total, 16 of 896 experts active |
| Context |
1M tokens |
| Vision |
Native, in-model |
| Attention |
Kimi Delta Attention + Attention Residuals |
| Quantization |
MXFP4 weights / MXFP8 activations, QAT from SFT onward |
| Weights |
Open |
Moonshot claims roughly 2.5× better scaling efficiency than K2 from the architectural changes — Kimi Delta Attention for how information moves across sequence length, Attention Residuals for how it moves across depth, and a Stable LatentMoE framework holding the extreme sparsity together at training time.
They're also candid about where it lands: K3 trails Claude Fable 5 and GPT-5.6 Sol overall, and they say so in the first three paragraphs. What it does deliver is frontier-adjacent performance on long-horizon agentic coding, with open weights and a price that isn't frontier-proprietary.
The demos are worth taking seriously
Benchmark tables are benchmark tables. The case studies in the announcement are harder to wave away:
- A GPU compiler from scratch. K3 built "MiniTriton" — a Triton-like compiler with its own tile-level IR over MLIR, optimization passes, and a PTX codegen pipeline. It holds its own against Triton and
torch.compile on roofline benchmarks and sustains end-to-end nanoGPT training with stable convergence. Not isolated kernels. A working pipeline.
- A chip, in 48 hours. An autonomous run producing a 4 mm² accelerator on the Nangate 45nm library, closing timing at 100 MHz, 1.46M standard cells, an INT4 MAC array with fused dequantization.
- Kernel optimization in production. Moonshot says an early K3 build did most of their own kernel optimization work during late development.
That last one is the tell. A team dogfooding a model on the work that gates their own release is a stronger signal than any leaderboard.
Why this lands differently on CloudCode.ONE
Two things about K3 intersect directly with what the gateway already does.
1. It's native multimodal — no vision routing needed
CloudCode.ONE's automatic vision routing exists because the strong open coding models have been text-only. DeepSeek V4 doesn't take images. GLM-5.2 doesn't take images. So when your agent hands a screenshot to the model, we transparently route the image to a vision-capable model, fold the description back in, and keep going.
K3 doesn't need that path. It ingests text, images, and video in one model, and Moonshot leans on this hard — what they call "vision in the loop," where the agent writes code, screenshots the result, looks at it, and iterates. Frontend work, game dev, CAD.
If you've been using vision routing as a workaround, K3 is the first open model on the platform where the screenshot goes straight into the same forward pass as the code. Expect tighter iteration on anything visual.
2. Preserved thinking is not optional here
This is the part to read twice.
K3 was trained in preserved thinking history mode. If your harness doesn't pass the full historical reasoning content back on every turn, generation quality degrades — Moonshot's word is "unstable." This isn't a nice-to-have that buys you a few points on a benchmark. It's a correctness requirement.
We shipped preserved thinking support on CloudCode.ONE earlier this year, so K3 works correctly through the gateway out of the box. But it's worth understanding why it matters, because the failure mode is subtle: the model doesn't error out, it just gets worse, and you won't necessarily know which turn it started.
The corollary is equally important: don't switch to K3 mid-session. If you've been running GLM-5.2 or DeepSeek for twenty turns and then flip to K3 to "bring in the big model" for a hard problem, you're handing it a history with no reasoning trace it recognizes. Start a fresh session instead. This is a genuine behavioural change from how most of us use multi-model routing, and it's the single most likely way to get a bad first impression of K3.
3. It will make decisions for you
Moonshot's second listed limitation: K3 was trained heavily on long-horizon, ambiguous tasks, and as a result it improvises. Hit a minor blocker or an underspecified requirement and it may decide on your behalf rather than stopping to ask.
For a 24-hour autonomous kernel optimization run, that's the whole point. For "fix this failing test in my repo," it's how you end up with a refactor you didn't order.
Constrain it explicitly. Put the boundaries in your system prompt or AGENTS.md:
## Boundaries
- Do not refactor code outside the files named in the task.
- Do not add dependencies without asking.
- If requirements are ambiguous, stop and ask rather than choosing.
- Do not modify CI config, migrations, or infra files.
Blunt instructions work better than polite ones with this model.
Using it through the gateway
Point your existing Anthropic-compatible setup at CloudCode.ONE and select the K3 model:
export ANTHROPIC_BASE_URL=https://cloudcode.one/api
export ANTHROPIC_AUTH_TOKEN=your_key_here
export ANTHROPIC_MODEL=kimi-k3[1m]
Same base URL you're already using. Preserved thinking is handled at the gateway, so any harness that speaks the Anthropic Messages API — Claude Code, Cline, Roo Code, OpenCode, or our own Harness desktop app — gets correct K3 behaviour without extra configuration.
If you're running tiered routing with subagents, K3 belongs in the planner or orchestrator slot, not on the sub-tasks. Let a cheaper model do the mechanical edits.
Worth your time?
If you build agents, yes — but with a specific shape of usage in mind.
K3 is not the model that makes your loop cheaper. It's the model you hand a genuinely hard, genuinely long task to and come back an hour later. Native vision closes a real gap in the open-model lineup, the 1M context removes a class of context-management pain, and the open weights mean it doesn't disappear when a licensing decision changes upstream.
Just start it in a fresh session, tell it where the fences are, and don't leave it as your default.
Kimi K3 is available now on CloudCode.ONE. Pay-as-you-go, no subscription, no minimum. Get an API key →