Kimi Code Adds K3-256k for Lower-Cost Everyday Coding

Lead

Kimi Code’s updated model documentation introduces k3-256k as the recommended launch option for Kimi K3. The model is effectively a 256k-context variant of K3: within that context size, the company says it delivers the same results as K3 while consuming roughly half the quota of the 1M-context version. For developers who mostly work on daily coding tasks rather than extremely long repository contexts, this is a practical cost and workflow change.

Key points

• A clearer model lineup: Kimi Code now lists four model IDs: k3, k3-256k, kimi-for-coding, and kimi-for-coding-highspeed. K3 is described as the flagship coding model, with k3 supporting up to a 1M context window for eligible tiers, while k3-256k is fixed at 256k.
• Designed for common coding work: The new 256k variant is recommended for everyday Q&A, code completion, routine feature development, and single-file or small multi-file edits. It supports image input but not video input.
• 1M context remains useful: If an existing session already exceeds 256k, switching from k3 to k3-256k may trigger a compact operation in tools such as Kimi Code CLI or Claude Code. Kimi recommends manually compacting first to preserve the main task context.
• Cache behavior matters: Switching model IDs or changing reasoning effort invalidates the context cache built during the session. That means the system may need to re-prefill context, making usage appear higher immediately after switching.
• Configuration details can cause errors: Users should enter the model ID, not the model version name. Some 401 responses may come from plan limitations, such as missing K3 access, missing 1M access, or missing HighSpeed access.

Why it matters

The important shift is not simply another model label. Kimi is separating long-context capability from the everyday coding default. A 1M window can be valuable for large codebases, long-running sessions, and complex migrations, but many programming interactions do not need that scale. k3-256k gives users a way to stay on K3 while avoiding unnecessary quota burn.

For teams, the likely pattern is straightforward: use k3-256k as the default for normal development, then switch to k3 when the task truly needs a larger context. The documentation also highlights that model choice is only part of the experience. Session cache, compacting behavior, reasoning effort, multimodal input compatibility, and third-party tool context settings all influence cost and reliability.

Source: Hacker News