· 7 min read
Kimi K3 Model Available: Coding Agent Support
By B. Hosseini
- guides
Kimi K3 model available in coding agent workflows: yes—use it directly in Kimi Code CLI and Kimi Code for VS Code, or through the officially documented Kimi Code integrations for OpenCode and Claude Code. Codex can also be connected, but its K3 path uses a community-maintained local router rather than a direct native integration; use k3 as the normal model ID and k3-256k when a 256K context is enough.
As of August 6, 2026, that is the practical answer to which agent supports Kimi K3. The important distinction is between an agent that has a documented Kimi integration, an agent that can speak a compatible API, and an agent that merely can be made to work through a proxy. Those are meaningfully different levels of support when you are debugging auth, tool calls, context windows, and reasoning behavior.
Which Coding Agents Support Kimi K3?
Start with the options Kimi itself documents, because they have the least ambiguity about model names, membership requirements, and protocol compatibility.
- Kimi Code CLI: the first-party terminal agent. Run
/modeland choose K3. Moonshot’s K3 repository calls Kimi Code CLI the recommended agent framework for the model. - Kimi Code for VS Code: the first-party editor integration. Select K3 from the input-bar model dropdown; restarting or signing in again may be necessary after a new model rollout.
- OpenCode: a documented built-in “Kimi For Coding” provider. Authenticate with
opencode auth login, choose Kimi For Coding, then use/modelsto selectk3ork3-256k. - Claude Code: a documented integration that points Claude Code’s Anthropic-compatible configuration at the Kimi Code API. It is a real, supported setup, but requires environment-variable configuration.
- Codex CLI: documented by Kimi as a community third-party integration through CC Switch. It can work, but it adds a local protocol-translation component, making it the most operationally fragile option in this list.
There is also a larger compatibility category: Kimi Code exposes both OpenAI-compatible and Anthropic-compatible endpoints. Any coding agent that genuinely supports a custom endpoint, API key, model ID, and the required request semantics may be configurable. Treat that as “possible after validation,” not as the same thing as an integration the provider has documented and tested.
Is Kimi K3 Actually Available, or Just Announced?
It is available. Kimi Code lists two K3 model IDs: k3, the flagship version with up to a 1-million-token context window for eligible memberships, and k3-256k, a 256K-context variant intended to reduce quota consumption. The model release is not merely a set of weights for researchers: it is exposed through Kimi Code clients and the Kimi Code API.
Do not type Kimi K3 into an agent’s model field unless that agent’s UI explicitly presents it as a selectable label. For API-backed configuration, the model identifier is k3 or k3-256k. Kimi’s documentation specifically warns that using a model version name rather than a model ID causes the call to fail.
Access is not universal across Kimi Code memberships. K3 and K3-256K require Moderato or above; the full up-to-1M context for k3 requires Allegretto or above. A 401 after a seemingly correct setup can therefore be an entitlement issue rather than a malformed key or a broken agent configuration.
Kimi K3 vs. K3-256K: Which Model ID Should You Use?
Choose k3 when the task genuinely benefits from a large, persistent working set: a broad repository investigation, a long migration, a multi-step refactor, or an agent session expected to accumulate substantial tool output. To use its full window in a third-party agent, configure the context-window value as 1048576; many tools otherwise retain a smaller default.
Choose k3-256k for ordinary feature work, review, debugging, small-to-medium refactors, and sessions where 256K tokens is already more context than the task needs. Kimi says it produces the same results within that context limit while k3 at 1M consumes roughly twice the quota. It also lacks video input, which matters only if your coding workflow passes video directly to the model.
Do not switch model IDs mid-session casually. Switching invalidates the cache built for the prior model, so the next turn needs context to be prefilled again. Start a new session where practical. If you need to move from a long k3 session to k3-256k, compact the conversation first so the retained context fits within 256K.
How to Use Kimi K3 in OpenCode
OpenCode is one of the simplest non-first-party choices because its Kimi For Coding provider is built into its authentication flow. Run opencode auth login, select Kimi For Coding, supply a Kimi Code API key, start OpenCode, and run /models. Select Kimi K3 (k3) or Kimi K3-256K (k3-256k) from that provider’s list.
After selecting K3, use /variants to control reasoning effort. OpenCode’s low, high, and max variants map directly to K3’s effort levels; its default maps to K3’s recommended high behavior. Keep thinking enabled: Kimi’s API documentation says disabling thinking routes K3 and K2.7 Code requests to K2.6 instead, which is an easy way to unknowingly test the wrong model.
How to Use Kimi K3 in Claude Code
Claude Code support works by sending its requests to Kimi’s Anthropic-compatible endpoint. The essential ingredients are a Kimi Code API key, https://api.kimi.com/coding/ as the base URL, and a model assignment. For standard usage, set the model to k3-256k or k3 according to your entitlement and context needs.
There is one agent-specific exception worth memorizing: Kimi’s Claude Code guide uses k3[1m]—not plain k3—when configuring the full 1M context window through Claude Code environment variables. That notation is for Claude Code’s environment-variable setup only. In normal Kimi API calls and other third-party model fields, use the plain k3 model ID.
Set Claude Code’s maximum context and auto-compaction window deliberately. A model with a 1M-token maximum does not force the agent harness to retain 1M tokens. The harness decides when to compact, and poor settings can erase useful working context early or create unnecessarily expensive sessions.
Does Codex Support Kimi K3?
Codex can be used with Kimi K3, but qualify the word “support.” Kimi’s guide describes a setup using CC Switch as a local router between Codex CLI’s OpenAI Responses API and Kimi For Coding’s OpenAI-compatible Chat Completions API. Those protocols are not directly interchangeable, so the router performs request and streaming translation.
That is useful if Codex is already your preferred harness, but it adds another process that sees requests, responses, and API credentials. Kimi explicitly labels the integration as community-provided and says compatibility is not guaranteed across every Codex or router version. For a first evaluation of K3, use Kimi Code CLI or OpenCode first; introduce the routing layer only when preserving the Codex workflow is more valuable than minimizing moving parts.
What Makes an Agent Compatible With Kimi K3?
API compatibility alone is necessary but not always sufficient. K3 has a few behavioral requirements that a coding-agent harness must handle well. It always uses thinking and returns reasoning content; for multi-turn API conversations and tool calls, Kimi says the complete assistant response—including reasoning content and tool calls—must be preserved when it is sent back in the next request. A client that discards those fields may still appear to work, yet lose continuity or behave inconsistently across longer tasks.
The agent should also support tool calling, a configurable context limit, and a useful mapping for reasoning effort. K3 accepts low, high, and max; unknown effort values can produce a 400 response. Finally, remember that a 1M context window is the model’s capacity, not a promise that your editor extension, provider plan, local machine, or agent UI will expose it automatically.
Which Kimi K3 Agent Should You Pick?
- Pick Kimi Code CLI if you want the first-party harness and the shortest route to testing the model as its maker recommends.
- Pick Kimi Code for VS Code if you want the same first-party path without leaving an editor workflow.
- Pick OpenCode if you want a terminal agent with a straightforward Kimi provider login and model picker.
- Pick Claude Code if you already use its terminal workflow and are comfortable managing endpoint, model, effort, and context environment variables.
- Pick Codex only when its specific workflow is important enough to justify a third-party local translation layer.
For any option, validate the setup with a small repository before asking for a major migration. Confirm the reported base URL and selected model, ask the agent to inspect and change one file, run a test, and verify the diff. That exercise catches the common failures: an unentitled plan, a fallback to a different model, an undersized context window, or an agent whose tool loop does not preserve K3’s reasoning and tool-call state.
Using Kimi K3 With Cline
For engineers who want to try K3 without committing to one editor or terminal surface, <a href="https://cline.bot">Cline</a> describes itself as an open-source coding agent that runs in editors and the terminal, with a CLI, VS Code extension, JetBrains plugin, and SDK. Its documentation says the agent can read and write files, run commands, and use a browser with explicit approval for every action.
Cline’s current model-access options are usage billing, bring-your-own-key, and ClinePass, a flat $9.99/month subscription. Its CLI changelog lists Kimi K3 as a ClinePass model, while its OpenAI-compatible provider configuration also supports services that expose a compatible base URL, key, and model ID. That makes it relevant here: it provides another agent interface for evaluating K3, while letting developers choose whether their model access is subscription-backed or provider-key-backed.