Kimi Code With K3: Setup, Plans and Cache Discipline

Kimi Code with K3 is the first hands-on question most developers asked when Moonshot shipped its new flagship on July 17, 2026: how do I actually run this thing, what does it cost, and which plan do I need? The answers live on two separate vendor pages that never cross-reference each other — the Kimi Code model-configuration docs and the membership pricing table. This post joins them.

The short version: K3 is selected with the /model command inside a Kimi Code session, gated by plan tier rather than by any per-request setting. Moderato ($19/mo listed) is the minimum tier that gets K3 at all, capped at 256K context. Allegretto ($39/mo listed) unlocks the full 1M window. Sampling is fixed, reasoning effort is max-only at launch — which means the levers you’d normally reach for don’t exist here.

What does exist is a cache-discipline rule with real money attached. Moonshot’s own docs state that switching models invalidates the existing context cache, and its launch blog states the Kimi API rides a 90%+ cache-hit rate in coding workloads. Put those together and an avoidable mid-session model switch is a quantifiable mistake. This guide covers the model lineup, setup, the full spend-to-capability matrix, the cache math, and where Moonshot itself says K3 still falls short.

Kimi Code’s model picker exposes three IDs, and understanding what each one is prevents most of the confusion downstream. The headline entry is k3 — the new flagship covered in depth in K3’s launch-day release post. The other two are both K2.7 Code — the coding-specialist model that remains available to every Kimi Code member — in standard and HighSpeed variants.

One subtlety for anyone integrating outside the Kimi Code app: the raw Kimi API platform lists the coding models under different IDs — kimi-k2.7-code and kimi-k2.7-code-highspeed — while Kimi Code’s own CLI and VS Code surfaces use the kimi-for-coding naming. Same models, two namespaces. If you’re wiring a third-party tool, check which surface you’re actually talking to before you paste a model ID.

The Kimi Code CLI is distributed as a single binary with no Node.js dependency required. Install via curl on macOS and Linux, Homebrew (brew install kimi-code), or PowerShell on Windows; an npm package (@moonshot-ai/kimi-code) is also published for teams that prefer that channel. The repo itself is MIT-licensed TypeScript on GitHub — 3.2k stars and 444 forks as of this writing.

Once installed and signed in with a membership that includes K3 (Moderato or above — see the matrix in the next section), Moonshot’s own onboarding path is exactly one step: run the /model command from within a Kimi Code terminal session and select k3. The VS Code extension exposes the same choice as a model dropdown in the input bar.

For third-party harnesses there’s a third surface: a direct “Model ID” field. Moonshot’s docs tell third-party integrations to set the context-window field to 1,048,576 to unlock the full 1M window. And because K3 is OpenAI-SDK compatible — you point the standard OpenAI Python or Node SDK at https://api.moonshot.ai/v1 with a Moonshot key — most existing tooling connects without a bespoke client. That compatibility story is part of a broader industry pattern we cover in our guide to the OpenAI-compatible API standard.

Here’s the table Moonshot doesn’t publish. The Kimi Code models page tells you which tier unlocks which context window; the membership pricing page tells you what each tier costs and what credit multiplier it carries. No single vendor page shows “spend $X, get Y context at Z concurrency” — so we built the cross-join. All cells are from Moonshot’s own two pages, retrieved July 17, 2026.

Two readings of this table matter more than the sticker prices. First, the doubling from Moderato to Allegretto ($19 to $39 listed) buys a 5x credit multiplier, not just 4x the context — on a per-credit basis Allegretto is the better deal for anyone actually running K3 daily, since roughly double the fee buys five times the allotment. Second, K2.7 Code stays available to every member including free Adagio, and paid tiers all get a 4x-speed agent priority queue — the plan ladder gates K3 and concurrency, not basic coding capability.

Moonshot documents the cache-invalidation behavior as a UX footnote. It deserves to be a headline, because the economics around it are unusually sharp. K3’s API pricing is flat across the entire 1M context window — no context-length tiering — at $3.00 per million input tokens on a cache miss, $0.30 per million on a cache hit, and $15.00 per million output tokens.

The 10x gap between hit and miss is where session hygiene turns into money. Moonshot’s docs state plainly that switching models invalidates the existing context cache and triggers a context re-prefill, temporarily increasing token usage — and the vendor’s explicit guidance is to start a fresh session rather than switch models mid-conversation. Kimi Code CLI v0.26.0 now surfaces a cache-invalidation hint in the terminal when a model or effort switch is about to happen, which tells you how often users were tripping over this silently.

Here’s an illustrative calculation — our arithmetic from Moonshot’s published rates, not a vendor-provided table. Say your agentic session is carrying 400K tokens of cached context. The next turn on a warm cache bills that input at the hit rate: 400,000 × $0.30/M ≈ $0.12. Switch models mid-session and the cache is invalidated, so the same context re-prefills at the miss rate: 400,000 × $3.00/M = $1.20 — about $1.08 of avoidable spend from a single switch, before the session even does new work. Hop between models a few times a day across a team and the footnote becomes a line item.

The discipline that follows is simple. Pick the model before the session starts, not during it. If you genuinely need a different model, end the session and open a fresh one — you’ll pay a normal cache warm-up either way, but you avoid conditioning K3 on another model’s conversation history, which Moonshot separately warns degrades output quality (more on that in Section 07). And use /compact to keep long sessions from ballooning the context you’d have to re-prefill if anything does reset.

If your cost-control playbook comes from other harnesses, K3 will feel locked down. The API’s sampling parameters are fixed and cannot be modified: temperature 1.0, top_p 0.95, n=1, presence and frequency penalties 0. The quickstart instructs developers to omit these fields from requests entirely rather than attempt to override them. Output defaults to 131,072 tokens per response with a maximum of 1,048,576.

Reasoning effort is similarly constrained: reasoning_effort currently supports only max. K3 always has thinking mode enabled, and there is no way to run it at lower effort yet — Moonshot describes lower tiers as coming later. That makes the effort-label mapping inside Kimi Code worth knowing, because the CLI accepts a much wider vocabulary than K3 currently honors:

The practical catch: since K3 itself only supports max at launch, any label below max is effectively normalized until Moonshot ships the lower tiers. If you’re migrating scripts or configs from another harness — say, Claude Code’s xhigh — the label will be accepted, mapped, and then quietly run at the only level K3 has. Budget for max-effort token consumption on every K3 call today, whatever your config says.

The developer-surface features that do exist are solid: structured output via json_schema with strict: true (parse the content field, not reasoning_content), tool_choice set to required to force a tool call on the first turn, dynamic tool loading via system messages, and streaming that emits separate reasoning and final-answer deltas. Control lives in structure and tooling, not sampling.

K3 landed into a much more capable Kimi Code than the one that launched the product. CLI v0.26.0, shipped July 16, 2026 — one day before K3 — gave the coder subagent background-task support, todo lists, plan mode, skill invocation, and nested agents. That sits on top of the built-in coder, explore, and plan subagents, each running in an isolated context for focused, parallel work — a pattern Moonshot has been developing since the K2.5 agent-swarm era.

The trend worth reading here: Moonshot is converging on the same harness grammar as its Western competitors — subagents, plan modes, skills, background tasks — while differentiating on plan economics and an open-weights posture. For a team already fluent in one agentic CLI, the switching cost is now mostly muscle memory, not concepts. Where the harnesses genuinely diverge is in conventions and defaults, which is exactly the territory we mapped in our comparison of agentic coding harness conventions.

Moonshot’s launch blog includes a limitations section that is unusually direct for a flagship release, and two of its disclosures bear directly on how you should run K3 in Kimi Code.

The first is thinking-history sensitivity — and it’s the quality twin of the cache-cost rule from Section 04:

So a mid-session model switch into K3 doesn’t just cost you a cache re-prefill — by the vendor’s own account it can destabilize generation quality. One habit, two failure modes avoided: start K3 in a fresh session.

The second disclosure is excessive proactiveness: Moonshot says K3 “may make unexpected decisions on the user’s behalf” on minor issues or ambiguous intent. In an agentic harness with background tasks and a goal queue, that argues for tighter plan-mode review before letting long runs go unattended. And third, Moonshot concedes ground on polish outright — its blog states that “K3 nonetheless exhibits a noticeable gap in user experience compared with Claude Fable 5 and GPT 5.6 Sol.” Vendor candor of that order is rare, and it sets the right expectation: K3 in Kimi Code is a frontier-class engine with rough edges, priced and gated accordingly. Keep the comparison qualitative for now — the harnesses differ more in conventions than in any single benchmark — and run your own evals on your own repos.

Pulling the plan matrix, the cache math, and the vendor caveats together, the decision tree looks like this:

Whichever tier you land on, the operating rules stay the same: pick the model per session and don’t switch mid-stream, keep sessions compact, budget for max-effort output on every K3 call, and treat the current plan table as perishable given the announced restructure. If your team is weighing K3 against closed-frontier options across real workloads — routing, evals, cost modeling — that comparative discipline is exactly what our AI transformation engagements are built around.