Moonshot shipped Kimi K3 on July 16, 2026 — a 2.8T-parameter MoE model with a 1M-token context window and two variants at launch: K3 Max for chat and agent work, and K3 Swarm Max for large-scale parallel processing. For mobile, automation, and orchestration teams, the interesting piece is not the parameter count. It is that a single call can now hold the entire history of a long-running agent run and decode across it up to 6.3x faster, which quietly retires a full layer of glue most stacks have been writing by hand.
The July 2026 smol.ai AINews newsletter led with the K3 launch, noting a leaked promo page on Moonshot's own Kimi Open Platform that tipped the release a day early and pushed K3 to the top of the Frontend Code Arena at a 76% pairwise win rate — above Claude Fable 5 and GPT-5.6 Sol. At Halmob, every 2026 engagement is a mobile app, an n8n automation layer, and a routing layer that keeps the two in sync. K3 changes what belongs inside that middle layer, and what still lives outside it.
The 30-Second Version
What Kimi K3 Actually Ships
Kimi K3 is not a single model artifact. It is a model, a runtime, and a pricing shape that together nudge automation teams toward longer, more parallel runs. The pieces that matter for a mobile-and-automation stack:
- 2.8T-parameter Stable LatentMoE backbone — 896 experts total, 16 active per token (~50B active), so each forward pass stays cheap relative to total capacity.
- 1M-token context window — wide enough to hold a full repo snapshot, a tool log, a screenshot stream, and a multi-day conversation in the same prompt.
- Kimi Delta Attention (KDA) plus Attention Residuals — Moonshot reports up to 6.3x faster decoding in million-token contexts, which is where agentic runs actually live.
- MXFP4/MXFP8 quantization out of the box — lower memory footprint without retraining, which makes self-hosting practical outside a hyperscaler.
- Two shipping variants — K3 Max for chat and single-agent tasks, K3 Swarm Max for large-scale parallel processing.
- Open weights under Modified-MIT — full weights slated to publish by July 27, 2026, with pricing set at $3 input and $15 output per million tokens.
The pricing is a roughly 5x jump over K2.6, and that shape matters. K3 is not the model you route every request to. It is the model you route the long, branching, parallel work to — the runs where paying for one wide context beats paying for a thousand short ones that each re-load the same repo.
Why the 1M Window Retires a Layer of Glue
Long-running agent stacks today lean on three tricks to survive short context windows: aggressive compaction, memory sidecars, and a supervisor loop that stitches short subagent calls back together. Once a single call can hold a million tokens and decode across them 6.3x faster, two of those three tricks stop pulling their weight.
Compaction becomes optional, not mandatory
Most compaction pipelines exist because the model would otherwise drop the plan halfway through a long run. With a 1M window, the plan, the tool log, and the last thousand file reads can all sit in the prompt. Compaction turns into a cost lever — something a team uses when the run is genuinely enormous — not a correctness lever it has to run on every call.
Memory sidecars move to the edges
The atomic memory patterns we covered in AtomMem atomic memory for LLM agents still matter for cross-session state and for the moments when a run does need to span more than a million tokens. But for the middle of a run, the sidecar stops being the primary carrier of context. The prompt is.
Supervisor loops shrink
A run that used to be one supervisor plus dozens of short subagents can now be one wide K3 Max call with a small number of tools. The supervisor still lives on for cross-run coordination and for approvals, but the inner loop gets shorter, cheaper to debug, and easier to instrument.
The interesting question is no longer "can the model hold the plan?" It is "which part of your existing glue exists only because the model used to forget?"
K3 Max vs. K3 Swarm Max: Two Different Jobs
The two variants map onto two different lanes in a real automation stack. Mixing them up is the fastest way to over-pay or under-scale.
| Variant | Best fit | What it costs you |
|---|---|---|
| K3 Max | Single long-running agent, deep research, multi-day chat, code review over a whole repo | One wide context, one plan, no fan-out |
| K3 Swarm Max | Parallel workloads: overnight refactors, multi-vendor backfills, batched enrichment, large evaluation runs | Higher throughput, but coordination is on your side of the boundary |
The clean rule of thumb: if the task is one plan that has to stay coherent for hours, that is a K3 Max job. If it is hundreds of independent slices that only need to agree on their inputs and outputs, that is K3 Swarm Max. Most Halmob-style stacks have both hiding in different corners of the same n8n flow.
Where K3 Fits Next to Your Existing Stack
K3 does not replace your workflow tool, your phone-side approval surface, or your durable runtime. It slots in as the long-context and long-horizon engine inside a stack you already have.
| Layer | Tool | What it owns |
|---|---|---|
| Visual workflow | n8n | Triggers, integrations, human-readable flow steps |
| Mobile orchestration | Hermes Workspace | Phone-side approvals and an agent control plane |
| Routing | Sakana Conductor | Picks which model handles which subtask |
| Durable runtime | Cloudflare Project Think | Crash-safe execution, persistent sessions, sub-agents |
| Wide-context engine | Kimi K3 Max | One plan across up to a million tokens |
| Parallel engine | Kimi K3 Swarm Max | Fan-out across hundreds of independent slices |
The boundaries are real. n8n still owns the flow that a human can read. Hermes still owns the approval on the phone. Project Think still owns crash-safe execution. K3 plugs in as the model your router picks when the run is either very long or very wide — and stays unpicked for everything else, because the price is not right for a two-turn chat.
Why This Matters for Mobile Automation
Five Practical Use Cases for Halmob-Style Stacks
Overnight refactors as a Swarm Max fan-out
A K3 Swarm Max run assigns one slice of a legacy codebase per subagent: one upgrades dependencies, one rewrites tests, one fixes broken imports. A K3 Max supervisor holds the architecture plan and merges the work in the morning, with a full log of what each slice touched.
Multi-day mobile assistants
A user starts a research task on the phone, locks the device, and checks back the next day. The run stays inside a single K3 Max context, Hermes handles the approval prompts, and the result and open questions land in the same thread — no external memory system needed for the middle of the run.
Long n8n branches without brittle compaction
Vendor onboarding, invoice review across many subsidiaries, and scheduled migrations often live in n8n branches that time out or lose state. Route those branches to K3 Max and let the 1M window carry the state. The visual n8n flow stays as the human-readable map; the model owns the part that used to fall over.
Multi-vendor backfills as isolated slices
Backfills that touch CRM, billing, and analytics usually fail because one vendor rate-limits or one schema drifts. A K3 Swarm Max run assigns one subagent per vendor, isolates failures to a single slice, and lets the supervisor retry only the broken part instead of the whole job.
Full-repo code review before merge
Team review that used to be split across many small prompts collapses into one K3 Max call with the diff plus the full surrounding code, the tests, the ADRs, and the last month of PR discussion. The output is a single coherent review, not five stitched-together fragments.
How to Get Started with K3
- 1Read the K3 release notes on the Moonshot Kimi Open Platform, and pay particular attention to the K3 Max vs. K3 Swarm Max pricing and rate-limit tables. The 5x jump over K2.6 is real, and it changes which of your existing calls are worth routing here.
- 2Pick one automation that today fails because the model forgets: a long chat, a multi-hour research task, or an n8n branch that has to re-load state on every step. That is the cheapest place to feel the value of a 1M window.
- 3Wrap that run in a single K3 Max call before you reach for Swarm Max. Wide context first, fan-out second. It is much easier to see whether parallelism buys you anything after the sequential run is already coherent.
- 4Instrument tokens per turn. K3's price only pays back when you use the window; a two-turn chat routed to K3 is a waste. The log you build here is what your Sakana Conductor routing layer will use later to decide which requests genuinely belong on K3.
If you are still mapping out the agent layer that sits above all of this, our OpenClaw 101 guide walks through the building blocks (tools, skills, permissions, memory), and the earlier Kimi K2.6 long-horizon agent swarms post covers the swarm pattern K3 Swarm Max inherits and widens.
The Bottom Line
Kimi K3 is the first open model where the harness, the window, and the parallel runtime all arrive in the same release. The 1M context plus KDA quietly retires a layer of compaction and memory glue that most agent stacks still ship by default. The two variants — K3 Max for one long coherent run, K3 Swarm Max for hundreds of parallel slices — map cleanly onto the two shapes of work that already live inside a real mobile-and-automation stack.
The question to take into your next sprint is not "should we adopt K3?" It is "which parts of our current pipeline exist only because the previous model forgot — and would disappear the moment the model didn't?" The answer, more often than not, is where K3 pays for itself. If you want help drawing that line in your own stack, that is exactly the kind of work our OpenClaw consultancy engagement is built for.