Kimi K2.6 Guide: Specs, Pricing and Where It Still Wins

When a lab ships a successor, the previous model is usually written off within a week. That reflex is wrong more often than it is right, and Kimi K2.6 is a good example of why.

K2.6 landed on 20 April 2026. Kimi K3 followed in July. K3 is the stronger model on almost every aggregate measure, and if you only ever look at an intelligence index you would never run K2.6 again. But the two models have different shapes, and the shape is what determines whether you can actually deploy something.

What K2.6 actually is

It is a mixture-of-experts vision-language model: roughly one trillion total parameters with about 32B active per token, routed across 384 experts — eight routed plus one shared — using MLA attention. The context window is 256K.

Two of those numbers matter more than the rest. 32B active is what you pay compute for on every token, and it is small. 256K context is the one place K2.6 is unambiguously behind the current field, where 1M windows have become normal.

If the total-versus-active distinction is unfamiliar, mixture-of-experts explained covers why a trillion-parameter model can be cheaper to run than a much smaller dense one, and what is a parameter count covers why the headline figure is nearly meaningless on its own.

The active-parameter gap is the whole story

Kimi K3 activates roughly 104B parameters per token. K2.6 activates about 32B. That is more than a three-fold difference in compute per token, and it propagates into everything downstream: serving cost, tokens per second, how many concurrent requests one node handles, and whether self-hosting is a conversation at all.

It shows in the API price too. K2.6 lists around $0.95 per million input tokens and $4.00 per million output. Moonshot lists K3 at $3 and $15. On output that is close to a four-times gap.

For a single-shot question, four times nothing is still nothing. For an agent loop making eighty tool calls against a large repository, it is the difference between a line item you ignore and one you have to defend. Why agent costs are unpredictable goes into why that multiplier lands harder than people expect.

Where 256K stops being enough

This is the honest limitation, and it is not subtle.

Kimi K3, GLM-5.2, both DeepSeek V4 variants and MiniMax M3 all ship 1M-token windows. K2.6 gives you a quarter of that. For most single-file work this is irrelevant — very few useful prompts approach 256K. For whole-repository reasoning, long agent transcripts, or feeding in a day of logs, it is a wall you will hit.

The mitigation is the same as it has always been: retrieve rather than stuff. RAG vs long context covers the trade, and agent memory and context management covers compaction inside a running loop. Both techniques work, and both are work you would not have to do on a 1M model.

Worth knowing: a large window is not the same as usable attention across that window. Models degrade toward the middle of very long contexts regardless of the advertised maximum, so a 1M window is not four times as useful as a 256K one. It is better, but not proportionally.

Vision is the underrated part

K2.6 is natively vision-language, not a text model with an adapter bolted on. If your workload involves screenshots, design mocks, diagrams, or PDF pages, that changes the calculus — you are comparing against multimodal alternatives, a much shorter list than the general open-weight field.

The common real use is a UI-fix loop: screenshot the broken state, hand it to the model with the component source, get a diff. That works, and it works at a materially lower price than routing the same task through a frontier text model plus a separate vision call.

When to pick K2.6 over K3

A short decision rule.

• Pick K2.6 when volume is high, tasks are bounded, prompts fit comfortably inside 256K, and the work is multimodal. The cost gap compounds over a fleet.
• Pick K3 when tasks are long-horizon and unattended, when you need the full 1M window, or when a failed run costs more than the tokens saved.
• Pick neither if you need a permissive licence. Both ship under Moonshot's custom terms, not MIT. Open weights vs open source covers why that distinction bites exactly when you succeed.

How to decide for your own work

Do not take the above on faith. Both models sit behind OpenAI-compatible endpoints, so switching is a configuration change rather than a migration.

Take fifteen real tasks from your git history. Run each through both models on the same harness and the same starting commit. Record three things: turns to completion, total output tokens, and whether you would merge the diff unmodified.

Then compute cost per completed task, not price per token. A cheaper model that needs three attempts is not cheaper. How to benchmark LLMs on your own work has the harness setup, and model routing and fallbacks covers running both — cheap model first, escalate on failure — which is usually the answer when the result is close.