Kimi K2.7 Code API: Thinking-Only Constraint Changes How You Route Coding Agents

Moonshot AI released Kimi K2.7 Code on June 12, 2026. The model improves on K2.6 on every published coding benchmark — but it ships with a constraint that changes how you price and route it: thinking mode is mandatory. Attempt to disable it and the Kimi K2.7 Code API returns an error. That single architectural decision ripples through cost modeling, fallback design, and MCP workflow orchestration for any team treating this model as a drop-in coding agent.

What happened

K2.7 Code is a Mixture-of-Experts model with 1T total parameters and 32B activated per token (384 experts, 8 selected per forward pass plus 1 shared). The architecture adds a MoonViT vision encoder (400M parameters) for image and video input. Context window is 256K tokens.

Benchmarks from Moonshot:

K2.7 Code runs at 81.1 on MCP Mark Verified, beating Claude Opus 4.8 (76.4) on that suite, which tests correct tool invocation across the Model Context Protocol. GPT-5.5 leads at 92.9 on the same benchmark.

The model is available via the OpenAI-compatible Kimi API as kimi-k2.7-code. Self-hosting requires vLLM, SGLang, or KTransformers; the Hugging Face checkpoint is roughly 595 GB on disk, making it a datacenter-class deployment.

Published pricing: cached input $0.19/1M tokens, cache-miss input $0.95/1M, output $4.00/1M.

Why it matters for AI engineering teams

Thinking-only mode is not a checkbox — it is a billing and latency floor.

Reasoning tokens bill at the output token rate. A model that cannot run without thinking means every request carries a chain-of-thought overhead you cannot shed. For short agentic steps — tool-call dispatch, file look-ups, quick linting passes — that overhead can dominate the per-step cost.

Moonshot claims roughly 30% lower reasoning-token usage compared to K2.6. Across a long-horizon coding session with hundreds of tool iterations, that compound reduction is real: lower output-token cost per task, faster step latency (less overthinking before each tool call), and more steps before hitting the 256K context ceiling. The net effect for agentic budgets is positive despite the absence of a non-thinking path.

The MCP Mark Verified benchmark score is worth noting separately. That suite tests real tool invocation through the Model Context Protocol — not abstract reasoning. An 81.1 score means K2.7 Code is a plausible drop-in for MCP-orchestrated coding workflows where you are currently routing to Claude or GPT models.

Sampling is also locked: temperature 1.0, top_p 0.95, n 1, all penalties at 0.0. Default max output is 32,768 tokens. You cannot tune these at the API level — what you get is what Moonshot ships.

The router/operator angle

Three routing changes your team should evaluate:

1. Revise cost estimates for thinking-required models. K2.7 Code does not have a cheap non-thinking fast lane. If your routing policy uses model fallback based on token budget — "use the fast cheap model for quick tasks, the capable model for hard tasks" — K2.7 Code belongs on the capable/expensive tier regardless of task complexity. Build that into your model selection logic before you swap K2.7 in as the default coding agent.

2. Fallback must not land on K2.7 by default. Because every K2.7 request carries thinking overhead, using it as a fallback from a cheaper non-thinking model would flip your cost curve upward on every error retry. If you are routing kimi-k2.6 as primary and want K2.7 as a quality fallback, ensure your fallback trigger is intentional — failing tasks that need deeper reasoning — not a catch-all for any API error or quota hit.

3. MCP workflows are a genuine fit; plan for locked sampling. For coding agent loops that call MCP tools (CI checks, code review, ticket updates), K2.7 Code's 81.1 MCP Mark Verified score makes it a strong candidate. The locked sampling parameters simplify prompt engineering — you don't need to tune temperature per call — but they also mean you cannot crank randomness up for creative refactoring passes. If variability matters in your agent loop, you need a different model or a wrapper that re-samples.

What TheRouter users should watch or try

If you are running coding agent pipelines through TheRouter, K2.7 Code is worth adding to your model pool with a clear tier assignment:

• Route to kimi-k2.7-code for deep, multi-step coding tasks where the thinking overhead is justified by task complexity.
• Keep a non-thinking model (K2.6, DeepSeek V4-Flash) on a separate route for lightweight tool dispatch where per-step latency and cost dominate.
• Use TheRouter's fallback policy to route K2.7 deliberately, not as an accidental error fallback from cheaper models.

Track your Kimi K2.7 Code API usage separately from K2.6 — the output token cost ($4.00/1M vs K2.6's equivalent) is meaningfully different, and the per-session thinking overhead will appear as elevated output token counts in billing dashboards.

See TheRouter model routing docs for guidance on building tier-based routing policies for thinking and non-thinking coding models.