Kimi K3 Is Live on the API: The Reasoning-Effort Parameter Change That Breaks K2.x Routing Scripts

When a new frontier model arrives, the headline is usually benchmark numbers. The operational decision is usually buried in the API changelog. Kimi K3 is no exception: Moonshot AI's 2.8-trillion-parameter open model launched on July 14, and teams integrating K3 into routing pipelines need to catch one silent breaking change before they touch any benchmarks.

What happened

Kimi K3 is now available via https://api.moonshot.ai/v1 as model name kimi-k3. It is Moonshot's largest model to date: 2.8T parameters, a Mixture-of-Experts architecture with 16 active experts out of 896, built on Kimi Delta Attention and Attention Residuals for improved long-sequence coherence.

The model ships with a 1-million-token context window, native visual understanding, and always-on thinking mode — there is no non-thinking variant. Model weights are scheduled for public release on July 27, 2026. Until then, access is API-only.

Benchmarks show K3 performing at or near the level of Claude Fable 5 on long-horizon coding tasks and beating GPT 5.6 Sol on several internal evaluations. In a 48-hour autonomous run, K3 designed a functioning chip layout using open-source EDA tooling. Impressive headline numbers, but not the thing that will break your pipeline.

The breaking change: reasoning_effort replaces thinking

Every Kimi K2.x integration that sets thinking mode uses an extra_body or thinking parameter. K3 does not accept that parameter. The correct field is now reasoning_effort, passed as a top-level key:

completion = client.chat.completions.create(
    model="kimi-k3",
    reasoning_effort="max",   # NOT extra_body={"thinking": {"type": "enabled"}}
    messages=[{"role": "user", "content": "..."}],
)

Currently max is the only accepted value. Low and high effort modes are coming in a subsequent release. This means K3 does not yet offer the cost-versus-quality tradeoff that operators typically use to tier their routing — every K3 call runs at maximum thinking cost.

A second operational change affects multi-turn conversations and tool-call chains: when the model returns a response, the full assistant message object — including the reasoning_content field — must be included in the next request's message history. Stripping reasoning_content before passing context forward causes degraded coherence on follow-up turns.

Why it matters for AI engineering teams

Three practical problems surface when upgrading from K2.x to K3 without reviewing the API diff.

Parameter mismatch silently falls back. Depending on how your SDK or gateway handles unknown fields, passing the old thinking parameter to K3 may be silently dropped rather than raising an error. The model still runs — at its default behavior — but your routing logic believes it set thinking effort when it did not.

Cost accounting changes. K3 tokens are billed separately from K2.7 Code tokens. If your per-model budget tracking uses K2.x model-name prefixes, the kimi-k3 model string will not match those rules. Verify your cost attribution logic covers the new name before scaling usage.

Coding-agent integrations need review. Moonshot's own quickstart highlights Claude Code, Codex, Cline, and RooCode as the primary K3 use cases. Each of those tools sends a model string and may pass thinking parameters based on previous configuration. Teams that set up K2.x integrations via those tools should re-read the K3 integration guides published on the platform docs before routing K3-bound traffic through existing agent setups.

The router/operator angle

Kimi K3 introduces a new cost-performance tier for long-horizon coding workloads. For operators routing coding-agent tasks across multiple providers, K3's performance profile — large MoE with always-on max thinking — is most directly comparable to Fable 5 and GPT 5.6 Sol, not to K2.7 Code. Routing K3 as a drop-in replacement for K2.7 Code will increase cost and latency for tasks that don't require frontier-level reasoning.

The lack of effort tiers also means fallback routing from K3 to K2.7 Code is currently the only in-family step-down option when you need to cut costs without switching providers. The upcoming low/high effort modes will eventually create a within-K3 tiering strategy, but that is not available today.

The open-weight release scheduled for July 27 will bring self-hosted and third-party inference options. Before that date, api.moonshot.ai is the only verified source. Track when your preferred inference provider adds the weights to avoid routing to unverified endpoints.

Key routing checklist:

• Update model strings from kimi-k2.6 or kimi-k2.7-code where K3 is the right fit
• Replace thinking parameter with reasoning_effort: "max" in K3 paths
• Include full assistant message (with reasoning_content) in multi-turn requests
• Verify cost attribution captures the new kimi-k3 model name
• Hold off on self-hosted routing until July 27 weights are confirmed

What TheRouter users should watch or try

The architectural shift in how Kimi K3 handles thinking mode — a top-level reasoning_effort field rather than an extra-body extension — is a good example of the API surface fragmentation that routing gateways exist to absorb. When multiple providers each implement their own thinking-mode conventions, a unified gateway can normalize those fields before they reach your application code. Check the TheRouter docs to see how provider-specific parameters can be mapped at the gateway layer so your application code stays provider-agnostic.

As K3's effort tiers become available, they will also be relevant for dynamic routing policies that select effort level based on task complexity or budget thresholds — a pattern worth configuring before the tiers land.