Kimi K2.7 Code Model Available for Coding Agents

Yes: the Kimi K2.7 Code model is available for coding-agent use through Kimi Code, Kimi’s hosted API, downloadable model weights, and selected third-party surfaces. The important implementation detail is that “Kimi K2.7 Code” is the product name, while the model ID you enter depends on the access path: the pay-as-you-go API uses kimi-k2.7-code, whereas Kimi Code’s subscription API uses kimi-for-coding.

Is Kimi K2.7 Code available for coding agents?

It is. Moonshot positions Kimi K2.7 Code as a coding-focused, agentic model for long-running software-engineering work: repository exploration, multi-file changes, debugging, tool use, and iterative execution. It has a 256K-token context window, uses a mixture-of-experts architecture with 1 trillion total parameters and 32 billion activated parameters per token, and accepts text, image, and video inputs. The large total parameter count matters less to an API user than the practical consequence: this is not a laptop-class local model, even though the weights are downloadable.

There are four realistic ways to use it. First, use Kimi Code’s own CLI or VS Code integration. Second, call the Kimi API from an agent or application. Third, run the downloadable weights on serious GPU infrastructure. Fourth, select it where a hosted coding product has added it—for example, GitHub announced general availability in Copilot on July 1, 2026, with rollout and plan eligibility varying by surface and organization.

That availability distinction is worth emphasizing. A model can be “available” while still not appearing in your preferred agent’s model picker, not being enabled by your organization, or requiring a particular provider endpoint. Check the provider, endpoint, model ID, and plan before treating a missing menu entry as a model outage.

How do you access Kimi K2.7 Code?

The lowest-friction option is Kimi Code, Moonshot’s coding environment for terminal and IDE workflows. Its CLI can read and write files, run commands, search code and web content, and use subagents. In that environment, K2.7 Code has been the default coding model, and you can switch among the available models with /model in the CLI or the model picker in the VS Code extension.

For an existing coding agent, use the Kimi API. Kimi Code documents both OpenAI-compatible and Anthropic-compatible interfaces, which is useful because many agent frameworks already know one or both protocols. Create an API key, configure the appropriate base URL, and enter the model ID rather than the human-readable model name. For the Kimi Code subscription endpoint, the documented configuration looks like this:

# Kimi Code subscription API
# OpenAI-compatible base URL
https://api.kimi.com/coding/v1

# Anthropic-compatible base URL
https://api.kimi.com/coding/

# K2.7 Code subscription model ID
kimi-for-coding

For the usage-billed Kimi platform API, use kimi-k2.7-code. Do not casually substitute IDs between the two systems. Kimi’s own configuration guide specifically warns that entering a version label such as “K2.7 Code” instead of an accepted model ID will fail. This is a common integration mistake because the model’s marketing name and its route-specific identifiers are intentionally different.

Does Kimi K2.7 Code require thinking mode?

Yes. Kimi K2.7 Code is a thinking-only model: it does not offer a non-thinking mode. In Kimi Code, a request with thinking disabled is automatically served by K2.6 instead. That means a successful response is not by itself proof that your agent used K2.7 Code; inspect the selected model and configuration when comparing behavior, cost, or tool-call reliability.

For software engineers, this has two operational effects. First, plan for visible latency and reasoning-token spend that can be greater than with a lightweight completion model. Second, test the full harness—not merely a one-shot prompt. An agent’s prompt construction, context compaction, tool schema, retry rules, and parser can matter as much as the model selection. Start with contained work such as a test failure investigation or a scoped multi-file refactor, then inspect diffs and command output before allowing broader permissions.

What does Kimi K2.7 Code cost?

There are two main billing paths. The Kimi API lists K2.7 Code at $0.95 per million input tokens on a cache miss, $0.19 per million cached input tokens, and $4.00 per million output tokens, before applicable taxes. Kimi’s automatic context caching makes repeated repository context materially cheaper, so long-lived sessions can cost less than repeatedly rebuilding an agent’s prompt from scratch.

Alternatively, Kimi Code sells usage-limited membership plans with weekly refreshed quotas. Moonshot’s published annual-billing monthly prices are $15 for Moderato, $31 for Allegretto, $79 for Allegro, and $159 for Vivace. Those are not interchangeable with API credits: a subscription is attractive when its quota and concurrency limits fit a developer’s interactive workflow, while token billing is often easier to measure and govern in a custom agent or automated pipeline.

There is also a HighSpeed variant in Kimi Code, exposed as kimi-for-coding-highspeed. The documentation describes it as having the same coding capability with roughly five to six times faster output, but it consumes three times the quota and requires Allegretto or a higher plan. Speed can be valuable for an interactive agent loop, but it is not free performance—evaluate it against the actual task completion time and quota burn of your workload.

Can you run Kimi K2.7 Code locally?

You can download the weights, but “locally” needs qualification. This is a 1T-parameter MoE model, not something to run comfortably on a consumer GPU or a typical developer workstation. The vLLM project’s deployment recipe lists a roughly 714 GB minimum VRAM requirement for its INT4 configuration and verifies an eight-H200 setup. The model activates 32B parameters per token, but its full expert weights and serving overhead still impose major memory and systems requirements.

Self-hosting therefore makes sense mostly for organizations with the infrastructure, utilization, and data-control requirements to justify it. You must also configure the serving stack correctly for Kimi’s reasoning and tool-call formats. A broken tool-call parser can make an otherwise capable model look like a poor coding agent because calls arrive as text or are not executed. For most individuals and small teams, the hosted API is the practical place to begin; it lets you validate agent behavior before committing to deployment engineering.

Is Kimi K2.7 Code better than K2.6 for software engineering?

Use K2.7 Code when the job is primarily coding and agent execution. Moonshot says it is optimized for long-horizon coding and reports higher results than K2.6 on its own coding and agentic evaluations while using about 30% fewer thinking tokens on average. Those are vendor-reported comparisons, including in-house benchmarks, so treat them as evidence of the intended optimization rather than a universal guarantee for your stack.

Use K2.6 when you need a more general-purpose model or explicitly need non-thinking operation. For a coding agent, the better question is not “which model tops a table?” but “which model completes our constrained task reliably at an acceptable cost?” Build a small evaluation set from your actual work: one bug fix, one unfamiliar-codebase question, one multi-file feature, one test-and-repair loop, and one task requiring tools. Record completion rate, human review time, wall-clock time, input and output tokens, and any unsafe or irrelevant actions.

What should you configure before using Kimi K2.7 Code in an agent?

1. Choose the access route first: Kimi Code membership, Kimi’s usage-billed API, a third-party hosted surface, or self-hosting.
2. Use the correct model ID for that route: kimi-k2.7-code for the platform API or kimi-for-coding for the Kimi Code subscription API.
3. Leave thinking enabled. Disabling it in Kimi Code routes work to K2.6 instead.
4. Start a fresh session when switching model IDs. Kimi notes that a model switch invalidates the existing context cache.
5. Verify tool calling with simple file-listing, file-reading, patching, and test-running tasks before granting an agent broad autonomy.
6. Set budgets, approval gates, and repository permissions at the agent layer; model capability does not replace operational controls.

Use Cline to test model availability without locking in your workflow

If this availability matrix feels more complicated than choosing a single model picker entry, Cline is relevant because it is an open-source coding agent offered as a VS Code extension and CLI. Its site describes a model-flexible setup: individual developers can bring their own API keys or use Cline’s provider, while Cline itself is free for individuals and inference is usage-based rather than a required seat subscription.

That makes Cline useful for the practical question behind Kimi K2.7 Code availability: testing a coding model in a real repository while retaining control over the inference provider and spend. Its paid Enterprise offering is for organizations that need capabilities such as centralized billing, team management, role-based access control, and SSO; otherwise, the open-source product is positioned for developers who want to select the models they run rather than commit their workflow to one model vendor.