# Kimi K2 vs Kimi K3 (July 2026) > Kimi K3 is Moonshot AI's 2.8T-parameter flagship with a 1M-token window, native video, and frontier agentic coding; K2 is the 2025 open-weight original, now best for lightweight self-hosting. But the model is only half the decision - the context you feed it is the other half. - Date: 2026-07-20 - Tags: ai-models, comparisons, documentation --- Kimi K3 is the model to use today. It is Moonshot AI's current flagship: 2.8 trillion parameters, a 1-million-token context window, native image and video understanding, and long-horizon agentic coding that trades blows with GPT-5.6 and Claude Opus 4.8 on coding benchmarks. Kimi K2, the July 2025 original, is a smaller 1-trillion-parameter open-weight model that made its name on coding and is now retired from Moonshot's hosted API. Reach for K3 for anything new. K2 still matters if you want a lighter, well-understood open-weight model to run yourself. But the model is only half the decision. A million-token window is worth exactly as much as the context you fill it with, and a coding agent that reads stale docs gives a confident, wrong answer no matter how capable the model is. That is the problem [Falconer](https://falconer.com/) solves: it keeps engineering documentation current as the code changes, so whatever model your agent runs on retrieves accurate, cited context instead of last quarter's. ## TLDR - Kimi K3 is Moonshot AI's 2.8-trillion-parameter flagship, released July 16, 2026, with open weights following on July 27, 2026. - Kimi K2 is the original July 2025 model: 1 trillion total parameters, 32 billion active, open-sourced under a modified MIT license. - The biggest single difference is context: K3 handles 1 million tokens versus K2's 128K (later 256K). - K3 adds native visual understanding, including video, which the original K2 did not have. - On Terminal-Bench 2.1, K3 scores 88.3, close to GPT-5.6 Sol at 88.8 and ahead of Claude Opus 4.8. - Pick K3 for frontier agentic coding and multimodal work; pick K2 if you want a smaller open-weight model to self-host cheaply. ![](https://falconer.com/api/file/s3/images/1784569122279-uf82.png) ## What is Kimi K2? Kimi K2 is a mixture-of-experts language model that Moonshot AI released in July 2025, built for coding and general reasoning. It has 1 trillion total parameters with 32 billion active per forward pass, and it shipped with a 128K-token context window that a September 2025 update ([Kimi-K2-Instruct-0905](https://en.wikipedia.org/wiki/Kimi_\(chatbot\))) expanded to 256K. Moonshot open-sourced it under a modified MIT license, and at launch it posted state-of-the-art numbers on several coding benchmarks while holding its own elsewhere. K2 was the start of a fast-moving line. Moonshot shipped K2.5, K2.6, and K2.7-Code over the following year, adding vision and agentic features along the way. The original K2 series was [discontinued on Moonshot's hosted API on May 25, 2026](https://platform.kimi.ai/docs/models), though the open weights remain available for anyone who wants to run the model themselves. ## What is Kimi K3? Kimi K3 is Moonshot AI's flagship model, released July 16, 2026, and described by the company as [the world's first open-source model in the 3-trillion-parameter class](https://platform.kimi.ai/docs/guide/kimi-k3-quickstart) at 2.8 trillion total parameters, which [VentureBeat called the largest open-source model released to date](https://venturebeat.com/technology/chinas-moonshot-ai-releases-kimi-k3-the-largest-open-source-model-ever-rivaling-top-u-s-systems). It uses a Stable LatentMoE framework that activates 16 of 896 experts per forward pass, and a new attention design called Kimi Delta Attention (KDA), a hybrid linear-attention mechanism paired with Attention Residuals to keep information flowing across long sequences. K3 was built for agentic coding and knowledge work. It carries a 1-million-token context window, native visual understanding of images and video, and what Moonshot calls strong long-horizon coding: the ability to sustain long-running engineering tasks, work across large codebases, and coordinate terminal tools. The [Kimi homepage](https://www.kimi.com/) leads with building playable 3D and multiplayer games, generating consulting-grade slides, and running parallel tasks through its Swarm and Goal features. Open weights are scheduled for July 27, 2026. ## Feature comparison | Dimension | Kimi K2 | Kimi K3 | | --- | --- | --- | | Released | July 2025 | July 16, 2026 | | Total parameters | 1 trillion | 2.8 trillion | | Active parameters | 32 billion | 16 of 896 experts (Stable LatentMoE) | | Context window | 128K, later 256K | 1 million tokens | | Attention | Standard MoE | Kimi Delta Attention (KDA) + Attention Residuals | | Multimodal | Text-first (vision added in later K2.x) | Native image and video understanding | | Coding benchmark | SOTA on coding at launch | 88.3 on Terminal-Bench 2.1 | | Open weights | Yes, modified MIT license | Yes, scheduled July 27, 2026 | | Hosted API status | Discontinued May 25, 2026 | Live | | Listed price | Superseded | $3.00 / $0.30 / $15.00 per M tokens (in miss / in hit / out) | ## How much bigger is K3, and does size matter here? K3 is roughly 2.8 times the parameter count of the original K2, but the more useful number is efficiency. Moonshot reports that K3 delivers [about 2.5 times the scaling efficiency of K2](https://www.datacamp.com/blog/kimi-k3), meaning it converts compute into capability more effectively rather than just adding raw size. The Stable LatentMoE design keeps only 16 experts active at a time out of 896, so the active compute per token stays manageable despite the headline parameter count. For most teams, the practical read is that K3's architecture, not its size alone, is what moved the model forward. The KDA attention mechanism is aimed squarely at the long-context problem that limited earlier models. ## Context window: 256K vs 1 million tokens This is the difference most people will feel first. Kimi K2 started at 128K tokens and grew to 256K. Kimi K3 handles 1 million tokens in a single context. For agentic coding across a large repository, that is the gap between fitting part of a service and fitting the whole thing plus its tests, tickets, and recent changes. A larger window changes what you can ask for in one pass: a full codebase review, a migration that touches dozens of files, or a task that has to remember decisions made thousands of lines earlier. K3's KDA attention exists to make that window usable rather than nominal. ## Multimodal: what K3 can see that K2 could not The original K2 was a text-first model. K3 ships with native visual understanding of both images and video, which Moonshot positions for work that mixes code and visuals: [game development, frontend engineering, and CAD](https://platform.kimi.ai/docs/guide/kimi-k3-quickstart). If your workflow involves screenshots, design files, or reviewing a rendered UI against its source, K3 handles it directly where K2 cannot. ## Coding and agentic performance Both models were built with coding as a priority, and both were strong for their moment. K2 set coding-benchmark records when it launched in 2025. K3 is now competitive at the frontier: on Terminal-Bench 2.1 it scores 88.3 with its KimiCode harness at max reasoning, close behind [GPT-5.6 Sol at 88.8](https://www.datacamp.com/blog/kimi-k3) (a single-agent result) and ahead of Claude Opus 4.8. DataCamp notes that Claude Fable 5 still leads K3 on broader intelligence measures, so K3 is not a clean sweep, but for agentic coding it belongs in the top tier. [Tom's Hardware reported](https://www.tomshardware.com/tech-industry/artificial-intelligence/moonshot-releases-2-8-trillion-parameter-kimi-k3) that K3 tops the Frontend Code Arena benchmark, which fits its focus on visual and frontend engineering work. The bigger shift is long-horizon work. K3 is designed to hold a task across many steps, coordinate terminal tools, and keep context over an extended session, which is what agentic coding actually demands. ## Pricing and availability Kimi K3 lists at [$3.00 per million input tokens on a cache miss, $0.30 on a cache hit, and $15.00 per million output tokens](https://www.datacamp.com/blog/kimi-k3), with no surcharge for the full 1M context. Moonshot reports cache hit rates above 90% for typical coding workloads, which pulls the effective input cost well below the headline rate. Both K2 and K3 are open weight, so self-hosting is an option for either. K2's advantage there is that it is smaller and cheaper to run. ## When Kimi K2 is the right choice K2 makes sense when you want a proven, smaller open-weight model you can host yourself without frontier-scale infrastructure. It is well documented, its behavior is understood, and the modified MIT license is permissive. If you are already running K2 in production and your tasks fit inside 256K tokens of context, there is no urgent reason to move. Self-hosted, cost-sensitive deployments are where K2 still earns its place. ## When Kimi K3 is the right choice K3 is the right choice for almost anything new: agentic coding across large repositories, tasks that need a million tokens of context, and any workflow that mixes code with images or video. It is the model Moonshot actively supports on its API, and it sits in the same performance tier as the leading US frontier models on coding. If you are choosing today and infrastructure is not the constraint, start with K3. ## How to choose between Kimi K2 and Kimi K3 The decision comes down to three questions. Do your tasks exceed 256K tokens of context, or involve images and video? If yes, K3 is the only real answer. Are you self-hosting on limited hardware and already happy with K2's output? Then K2 is a reasonable place to stay. Do you want the current frontier for agentic coding with active vendor support? That is K3. For most teams building new agent workflows in 2026, K3 is the default and K2 is the fallback for lightweight, self-hosted cases. ## The part the benchmark scores don't measure The model choice is not the whole story. A coding agent running on K3 can hold a million tokens and reason across an entire repository. That capacity is only worth as much as what you feed into it. A model that can read your whole codebase will still give a confident, wrong answer if the codebase it reads is documented against last quarter's architecture. This is the quiet failure mode of the agent era. Static documentation drifts from the code the moment someone ships a change. Search layers sitting on top of those docs inherit the stale content. The agent retrieves it, trusts it, and passes the error downstream. Bigger context windows raise the ceiling on how much an agent can consider; they do nothing about whether the material is current. The stale-docs tax that used to slow down human onboarding is now an AI-reliability tax, paid every time an agent retrieves outdated context. ## Why context quality decides agent quality An engineering team's most valuable knowledge is also its hardest to reach. It lives in the codebase and in engineers' heads: why a service was built this way, which ticket forced the workaround, what the Slack thread concluded before the PR merged. None of that sits in a tidy doc waiting to be retrieved. When a senior engineer becomes the only reliable source, they become a DM bottleneck, and the coding agent inherits whatever stale doc it can find instead. Falconer treats this as the actual problem to solve. [Falconer](https://falconer.com/) is a knowledge agent for engineering teams: it writes and updates documentation as the codebase changes, then delivers grounded, cited answers in the editor, in Slack, or through AI tools without pulling an engineer off their work. The idea is to close the gap between what the code does now and what the docs say it does, so that whatever model an agent runs on is retrieving current context rather than last quarter's. Falconer's guides frame this as building a company brain, a living knowledge layer that stays current and answers questions for both people and AI agents. If you want the background, their guide on [what a company brain is and why you need one](https://falconer.com/guides/what-is-company-brain/) is the starting point, and [how to build a company brain](https://falconer.com/guides/how-to-build-company-brain/) walks through the mechanics. For teams worried about knowledge walking out the door, [how to capture critical knowledge](https://falconer.com/guides/preserve-institutional-knowledge) covers the institutional-memory side. ## What this means for a Kimi-powered workflow Say you standardize on K3 for agentic coding. The window is huge, the model is capable, and it can coordinate terminal tools across a long task. The bottleneck moves. It is no longer the model's reasoning; it is the accuracy and freshness of the context the model pulls in. An agent that reads a current, cited description of how your auth service actually works will produce a usable change. An agent that reads a doc written three refactors ago will produce a plausible mess. Two habits matter here. First, keep documentation tied to the code so it updates as the code does, rather than rotting between quarterly cleanups. Second, make the answers verifiable: cited context lets a reviewer check where a claim came from instead of trusting the model's confidence. Citations are the trust artifact, the thing that turns a fast answer into a checkable one. Falconer's [comparison of knowledge management tools with Slack integration for engineers](https://falconer.com/guides/slack-knowledge-management/) is a practical look at what that plumbing involves if you are evaluating options. ![](https://falconer.com/api/file/s3/images/1784569139546-xshdkm.png) Choosing between Kimi K2 and K3 is a real decision, and K3 wins most of the time. The model is one input. The context you give it is the other, and that second input is the one you control. If you want to go deeper on the context side, start with Falconer's guide on [building a company brain](https://falconer.com/guides/how-to-build-company-brain/) and map your current docs against how fast your code actually changes. ## FAQ ### What is the main difference between Kimi K2 and Kimi K3? Scale and context. Kimi K2 is a 1-trillion-parameter model with up to a 256K-token context window. Kimi K3 is a 2.8-trillion-parameter model with a 1-million-token window, native image and video understanding, and a newer attention design. K3 is the current flagship; K2 is the 2025 original. ### Is Kimi K3 better than K2 for coding? Yes, for most cases. K3 scores 88.3 on Terminal-Bench 2.1 and is built for long-horizon agentic coding across large codebases. K2 was strong at launch in 2025 but has been superseded. K2 still holds value as a smaller model to self-host. Either way, coding quality depends as much on the context you feed the model as on the model itself. Falconer's guide on [context engineering vs prompt engineering](https://falconer.com/guides/context-engineering-prompt-engineering/) covers why agents need current company knowledge to produce usable code. ### Is Kimi K3 open source? Kimi K3's open weights are scheduled for release on July 27, 2026, following the July 16 API launch. Kimi K2 was already open-sourced under a modified MIT license. ### How much does Kimi K3 cost? Moonshot lists K3 at $3.00 per million input tokens on a cache miss, $0.30 on a cache hit, and $15.00 per million output tokens, with no premium for using the full 1M-token context. ### What is Kimi K3's context window? 1 million tokens, up from K2's 128K (later expanded to 256K). K3 uses Kimi Delta Attention to keep that long context usable in practice. A bigger window only helps if what fills it is accurate; Falconer's guide on [how to keep documentation in sync with code](https://falconer.com/guides/ai-keep-documentation-sync-code/) covers how to make sure the context an agent pulls in is current. ### Can Kimi K3 process images and video? Yes. K3 has native visual understanding of both images and video, aimed at work that mixes code with visuals like game development, frontend engineering, and CAD. The original K2 was text-first. ### Does a bigger model or context window fix stale documentation? No. A larger context window lets an agent consider more material, but it does not make that material accurate. If the docs an agent retrieves are outdated, a bigger model gives a more confident wrong answer. Keeping documentation current and cited is a separate problem from model choice, and it is the one Falconer solves: it updates docs as the code changes so agents retrieve current context. See [how to build living documentation that stays updated](https://falconer.com/guides/living-documentation/) and [what a company brain is and why you need one](https://falconer.com/guides/what-is-company-brain/) for the mechanics.