Kimi K3 API: Why 1M Context Changes Model Routing

Kimi K3 arrives with two numbers built for headlines: 2.8 trillion parameters and a 1-million-token context window.

For a production team, the more useful number is 10.

On Moonshot's official Kimi K3 API, cache-miss input tokens cost ten times as much as cache-hit input tokens. The more consequential requirement is not a number at all: multi-turn and tool-calling applications must preserve the complete assistant message, including reasoning and tool state.

That makes Kimi K3 more than a new model ID. It turns context layout, cache stability, session persistence, and task-boundary routing into production architecture.

TL;DR

• Moonshot describes Kimi K3 as a 2.8T-parameter, open 3T-class model with native vision and a 1,048,576-token context window.
• K3 was already available through Kimi products and Moonshot's API when checked, but full weights were scheduled for release by July 27, 2026.
• The model activates 16 of 896 experts, so its total parameter count is not the same as active compute per token.
• Official API pricing is $0.30 per 1M cache-hit input tokens, $3.00 per 1M cache-miss input tokens, and $15.00 per 1M output tokens.
• K3 always reasons at max today and requires complete assistant messages to be preserved in multi-turn and tool-call loops.
• Moonshot warns that missing thinking history or switching an existing session into K3 can make quality unstable.
• K3 was not listed in Velokey's live catalog when this article was checked. Do not guess a model ID; verify live availability first.

Kimi K3 Status: Confirmed, Pending, and Unavailable

The source material around a major model launch tends to collapse several different states into one word: released.

For Kimi K3, those states need to stay separate.

Moonshot's Kimi K3 release page calls it the first open model in the 3T class. That is the provider's characterization. The current practical distinction is that developers can already call K3 through Moonshot's API, while teams planning local deployment still need the actual weights, license, model card, and technical report.

If this article is updated after July 27, the weight-release status should be checked again. A planned release and a downloadable, licensed artifact are not the same thing.

What 2.8T Parameters Mean in Practice

Kimi K3 combines Kimi Delta Attention, Attention Residuals, and a Stable LatentMoE architecture. Moonshot says the model activates 16 of 896 experts for a request.

That changes how the parameter headline should be read.

*Moonshot reports 2.8T total parameters, 16 of 896 experts effectively activated, a 1,048,576-token context window, and native vision.*

A 2.8T total parameter count describes the model's overall capacity. It does not mean every parameter is active for every token. Sparse expert activation is the mechanism that allows a very large model to expose more capacity without paying the full dense-model compute cost on every step.

Moonshot also reports roughly 2.5 times the overall scaling efficiency of Kimi K2. That is a provider-reported architecture result, not an independent production measurement, but it points to the real engineering goal: making a very large model usable for long-horizon work rather than merely making it large.

K3 also includes native visual understanding and is positioned for coding, knowledge work, reasoning, images, and video. Those capabilities widen the set of possible API workloads, but they do not tell a team which workloads will be economical.

That answer comes from context, output, latency, and tool behavior.

Why a 1M-Token Window Does Not Remove Context Engineering

Kimi's official pricing page lists a context window of 1,048,576 tokens.

That is a large capacity. It is not an instruction to fill every request.

A long-running coding or research agent can accumulate:

• system instructions
• permission and safety rules
• tool definitions
• repository files and documents
• retrieved evidence
• user messages
• assistant reasoning
• tool calls and tool results
• retries, corrections, and abandoned branches

The context may fit while the task still becomes slower, more expensive, and harder to control.

Long context changes the main question from "Will this fit?" to "What deserves to remain live?"

A production session should separate four layers:

1. Stable prefix: durable instructions, fixed knowledge, and frequently reused tool definitions.
2. Task working set: the files, evidence, images, and tools needed for the current goal.
3. Complete session state: the messages required to preserve reasoning and tool continuity.
4. Restartable checkpoints: verified summaries that let a task recover without carrying every failed branch forever.

*Long context is operationally useful when stable instructions, the active working set, full session state, and restart checkpoints are managed separately.*

The million-token window gives teams more room. It does not replace retrieval, compaction, checkpointing, or token budgets.

How Kimi K3 Pricing Changes Prompt Architecture

Moonshot's official K3 pricing is:

• Cache-hit input: $0.30 per 1M tokens
• Cache-miss input: $3.00 per 1M tokens
• Output: $15.00 per 1M tokens

Prices exclude applicable taxes and may change. Verify the live official page before procurement.

The basic cost model is:

input cost = cache-hit MTok x $0.30 + cache-miss MTok x $3.00
output cost = output MTok x $15.00

*Pricing checked on July 17, 2026 shows a 10× gap between cache-hit and cache-miss input rates, making prefix stability a cost-control mechanism. These are official Kimi API rates, not Velokey pricing; prices may change.*

The tenfold input-price gap makes prompt structure part of the cost architecture.

Kimi's context caching is automatic. There is no manual cache ID or TTL to manage. The API tries to reuse repeated initial context such as system prompts, knowledge documents, and tool definitions.

Automatic does not mean guaranteed.

If an application changes the beginning of the prompt on every call, reorders tools, injects timestamps into the prefix, or serializes the same knowledge in a different order, it may turn reusable context into cache misses.

Moonshot says the official API has achieved cache-hit rates above 90% in coding workloads. Treat that as a provider-reported result, not a promise for a different application. The number a production team should trust is the one measured on its own traffic.

Track at least:

• cache-hit input tokens
• cache-miss input tokens
• reasoning and final-answer output tokens
• time to first token
• total response latency
• tool-call count
• retry rate
• cost per completed task

Per-request pricing is not enough for an agent. One user goal may trigger dozens of model calls, tool calls, retries, and verification steps.

Why Preserved Thinking Changes Model Routing

Kimi K3 always reasons. The API currently supports only reasoning_effort="max", and a response may contain reasoning_content in addition to its final content.

For multi-turn conversations and tool calls, Kimi's documentation says the complete assistant message must be added to the next request. Developers should not keep only the visible answer. The returned message may also contain reasoning and tool-call fields required for continuity.

This affects both cost and routing.

Historical reasoning continues to occupy the context window and contributes to token consumption. A long agent session therefore grows through more than user messages and documents.

It also means model selection is not safely stateless.

Moonshot warns that K3 quality may become highly unstable when a harness fails to return complete thinking history or when an ongoing session with another model is switched over to K3.

The safer production rule is simple:

> Route at the task or session boundary, then pin the selected model until a deliberate checkpoint.

If a model or provider fails midway through a task, create a restart package containing verified facts, completed actions, current files, open decisions, and remaining goals. Start the replacement model from that explicit state instead of silently changing the model ID inside the same tool loop.

*Select the model at a task boundary, pin it through the tool loop, and change models only after a deliberate checkpoint or in a new session. This is a production recommendation, not an official Kimi routing architecture.*

This is the difference between request routing and session routing.

Where Kimi K3 Fits in a Multi-Model Stack

K3's maximum reasoning mode makes workload separation important from day one.

Moonshot lists excessive proactiveness as a current limitation. K3 may make unexpected decisions when a long task encounters ambiguity or a minor obstacle.

That makes permission design as important as prompt design:

• separate read access from write access
• keep API keys and production credentials server-side
• require approval for destructive or external actions
• define explicit stop conditions
• log every requested tool action and result
• evaluate recovery behavior, not only successful runs

The most capable model should not automatically receive the widest permissions.

Kimi K3 API vs Self-Hosting

The planned open-weight release makes local deployment part of the conversation. It does not make local deployment the automatic winner.

Moonshot says K3 uses quantization-aware training with MXFP4 weights and MXFP8 activations. The company recommends supernode configurations with 64 or more accelerators for deployment.

That is a recommendation, not a published hard minimum, but it is enough to show that full-scale K3 serving is a cluster-level infrastructure project.

Managed API access is the practical first path when:

• traffic is early or variable
• the team wants to validate quality before buying infrastructure
• deployment speed matters
• the team cannot operate a large distributed inference stack
• the product needs to compare K3 with several other models

Self-hosting becomes more plausible when:

• the final license permits the intended use
• data-sovereignty requirements require local control
• load is sustained enough to justify dedicated capacity
• the organization already operates large-model infrastructure
• the team can manage utilization, batching, caching, upgrades, and failure recovery

Open weights do not make hardware, networking, idle capacity, observability, or engineering time free.

The safest order is API evaluation first, infrastructure commitment second.

A Production Checklist for Kimi K3 Agents

Before sending production traffic to K3, answer these questions.

Workload fit

• Does the task need long-horizon reasoning, large context, vision, or complex tools?
• Is the result valuable enough to justify maximum reasoning and output-token cost?
• Could a cheaper model handle the first-pass classification, extraction, or rewrite?

Session design

• Is the model pinned for the life of the task?
• Is the complete assistant message stored and replayed?
• Can the workflow restart from a checkpoint after failure?
• Are tool definitions loaded only when needed?

Cost and latency

• What percentage of input tokens are cache hits?
• How quickly does reasoning history grow?
• What are time to first token and total task duration?
• How much spend comes from retries and failed tool calls?
• What is the cost per accepted result, not only per request?

Safety and operations

• Which actions require human approval?
• Are credentials stored only on the server?
• Are destructive actions blocked by default?
• Are tool calls, errors, token usage, latency, and spend observable?

Evaluation

• Does K3 outperform a strong baseline on the actual workload?
• Does it outperform a cheaper baseline enough to justify the cost?
• What happens when the task is restarted on another model?
• How often does the model need human correction?

The evaluation result should be a quality-cost-latency frontier, not a single benchmark score.

How to Prepare an OpenAI-Compatible Client Without Inventing a Model ID

Kimi K3 was not in Velokey's live catalog when this article was checked. Availability can change, so check the live model catalog and query the models endpoint before writing integration code.

Do not guess a model ID from a blog post.

The following example lists the model IDs currently available to a Velokey account. It does not assume K3 is present.

import os

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["VELOKEY_API_KEY"],
    base_url="https://api.velokey.ai/v1",
)

for model in client.models.list().data:
    print(model.id)

Keep the API key in a server-side environment variable. If a Kimi K3 model ID does not appear in GET /v1/models, it is not available to that account through Velokey yet. Continue using a verified available model or the official Kimi API rather than hardcoding an unlisted ID.

Once a new model becomes available, an OpenAI-compatible client reduces migration work. The application still needs model-specific evaluation, session rules, and telemetry. Interface compatibility does not erase behavioral differences.

When Kimi K3 Is Worth the Spend

Kimi K3 is most compelling when a task is expensive for a human, difficult to split, and valuable enough to justify a long reasoning trace: a large refactor, a multi-tool research job, a multimodal engineering workflow, or a complex document set that needs sustained synthesis.

It is less compelling as a universal default. Classification, extraction, tagging, simple rewriting, and routine support are where a multi-model stack should protect the budget.

The production decision should not come from 2.8T alone. It should come from cache-hit rate, cost per completed task, session stability, tool success, latency, recovery behavior, and human correction.

That is the real Kimi K3 API story. The model is large, but the surrounding session architecture decides whether it is useful.

Kimi K3 API FAQ

Is Kimi K3 fully open source now?

As of July 17, 2026, Moonshot said the full model weights would be released by July 27. K3 was already available through Kimi products and the official API. Verify the repository, license, model card, and technical report before describing it as downloadable in a later article.

What is the Kimi K3 context window?

Moonshot lists 1,048,576 tokens. The large window increases capacity but does not remove the need for retrieval, caching, history control, and checkpoints.

What is the official Kimi K3 API price?

Moonshot lists $0.30 per 1M cache-hit input tokens, $3.00 per 1M cache-miss input tokens, and $15.00 per 1M output tokens, excluding applicable taxes.

Does Kimi K3 use all 2.8T parameters on every token?

No. Moonshot says the Stable LatentMoE architecture activates 16 of 896 experts. The total parameter count describes capacity, while sparse activation limits active compute.

Can I switch models in the middle of a Kimi K3 session?

Do so cautiously. Moonshot warns that incomplete thinking history or switching an ongoing session from another model to K3 can make generation unstable. Route at a session boundary or restart from a verified checkpoint.

Is Kimi K3 available through Velokey?

It was not listed when this article was checked on July 17, 2026. Use the live model catalog and GET /v1/models for current account-level availability. Do not rely on a static blog claim.

Sources

• Kimi K3 release and limitations
• Kimi K3 API quickstart
• Kimi K3 official pricing
• Kimi API context caching
• Kimi K3 thinking effort

Disclosure: Velokey publishes this article and provides an OpenAI-compatible API access layer for models from multiple providers. Kimi K3 was not listed in Velokey's live catalog at the time of review.

Want to prepare one client for current and future model options without inventing IDs? Follow the [Velokey quickstart](https://docs.velokey.ai/quickstart), then select only a model returned by GET /v1/models.