Kimi K4: What I’d Verify Before Planning an Upgrade

There is no K4 API to integrate yet

I’m treating Kimi K4 as a model to watch, not a dependency to plan around. Moonshot AI has not published its final specifications, benchmark results, API pricing, or release date. There is no official K4 model card, technical report, API identifier, or license.

The strongest public signal is reporting from The Information. Citing two people familiar with the matter, it says Moonshot is seeking additional Nvidia Blackwell capacity for a successor significantly larger than Kimi K3.

That is evidence of development planning, not a product announcement. It does not establish a five-trillion, six-trillion, or any other exact parameter count. It also does not tell us whether K4 will ship as open weights, a hosted model, multiple variants, or a broader agent system.

My working distinction is:

• Documented baseline: what Moonshot publishes about K3.
• Reporting: what outside sources say about K4 development.
• Inference: what a successor might improve.

Mixing those categories produces a convincing-looking specification sheet that nobody can actually rely on.

Start with the model that exists

K3 is the useful reference point because it already combines extreme sparse-model scale, native vision, long context, and long-running agent workflows.

Moonshot’s K3 model summary lists:

K3 component	Published specification
Total parameters	2.8 trillion
Activated parameters	104 billion
Layers	93
Routed experts	896
Selected experts per token	16
Shared experts	2
Context length	1,048,576 tokens
Vision encoder	401-million-parameter MoonViT-V2
Attention	Kimi Delta Attention plus Gated MLA
API model ID	kimi-k3
Weight availability	Open weights under the Kimi K3 License

The distinction between total and activated parameters matters. Sparse Mixture-of-Experts models do not activate their entire parameter pool for every token. That does not make a 2.8T model cheap to operate: storing and distributing the weights still requires substantial infrastructure.

The architecture gives us clues, not K4 specifications

Moonshot’s K3 technical blog describes Kimi Delta Attention and Attention Residuals as foundations for scaling beyond the trillion-parameter regime.

Kimi Delta Attention provides an efficient attention foundation. Attention Residuals selectively retrieves representations across model depth rather than accumulating them uniformly.

K3 also uses Stable LatentMoE, activating 16 of 896 routed experts. Quantile Balancing derives expert allocation from router-score quantiles, while Per-Head Muon optimizes attention heads independently.

Those choices point to real scaling problems: routing stability, expert utilization, long-context efficiency, and predictable training. They do not prove which mechanisms K4 will retain or replace.

The reported Blackwell procurement is relevant for the same reason. Training needs accelerators, networking, storage, and a stable distributed run. Serving needs a separate strategy for latency and cost. More training hardware does not automatically solve production inference.

The K4 specification sheet should mostly say “unknown”

Here is the boundary I would keep in any technical discussion:

Dimension	What we can say about K4	Status
Development	Reporting describes a larger K3 successor	Reported
Total parameters	Significantly larger than K3, according to reporting	Exact count unknown
Architecture	A sparse MoE continuation is plausible	Inference
Activated parameters	Not disclosed	Unknown
Expert count and routing	Not disclosed	Unknown
Context window	Retaining at least K3’s roughly 1M-token capability is plausible	Not confirmed
Attention	A further evolution of Kimi Delta Attention is possible	Inference
Native multimodality	Continuation of K3’s direction is plausible	Not confirmed
Open weights and license	Not announced	Unknown
API identifier and pricing	Not announced	Unknown
Release date	Not announced	Unknown

I would not copy K3’s context limit, license, or vision support into a K4 requirements document. A predecessor establishes expectations, not commitments.

The same applies to distribution. Moonshot’s releases span model weights, APIs, end-user products, and specialized agents. A K4 announcement could describe a single model or a system involving routing, tools, memory, and multimodal components.

What would make an upgrade worthwhile?

A larger parameter count would get my attention. It would not get my production traffic.

I would evaluate K4 on four outcomes:

1. Task completion rate.
2. Long-horizon agent reliability.
3. Coding success rate.
4. Cost per successfully completed task.

The fourth is the one I care about most operationally. A cheaper request is not a cheaper repository fix if the agent needs more attempts, wastes tool calls, or repeatedly produces patches that fail verification.

Repository repair, not just code generation

K3’s published demonstrations already cover compiler development, GPU kernel optimization, scientific coding, interactive research, game development, and chip-design workflows. Those examples appear on the official model page.

For a successor, I would look for more consistent execution across ordinary engineering work:

• Map an unfamiliar repository and its dependencies.
• Operate the terminal without losing the task.
• Change multiple files coherently.
• Run tests and diagnose failures.
• Revise a patch rather than restarting blindly.
• Verify that the requested behavior actually changed.

K3’s reported results are already strong on ProgramBench, SWE-Marathon, FrontierSWE, and terminal tasks. The interesting opportunity is deeper repository repair without sacrificing sustained multi-step performance.

Long context that survives an agent run

A million-token window is a capacity figure, not proof that a model can use every relevant detail.

A Kimi Delta Attention successor could potentially improve distant-evidence retrieval, reduce attention-state memory, and preserve important information across long workflows. None of that is announced for K4.

My test would be whether the model can find, combine, and act on evidence spread across a large input without excessive chunking or repeated retrieval. During an agent run, I would also watch goal retention, recovery from failed actions, verification behavior, and variance between attempts.

An impressive successful trajectory is less useful than a repeatably successful one.

Vision inside the feedback loop

K3 combines text and vision at the model level. Moonshot’s product examples extend that into video editing and vision-in-the-loop development.

Potential K4 improvements include screenshot-to-code work, chart and document reasoning, video temporal understanding, interface testing, and visual verification. These remain expectations.

The meaningful distinction is not “accepts an image.” It is whether an agent can inspect a rendered result, identify a mismatch, edit its work, and check the revision. That closed loop is considerably more demanding than answering one question about a screenshot.

More capacity without worse serving economics

A larger expert pool can create underused specialists, overloaded experts, communication bottlenecks, and training instability.

Better load balancing, expert specialization, lower activation ratios, or cross-expert coordination would be useful engineering advances. They are not disclosed K4 features.

Likewise, quantization-aware training, efficient expert parallelism, speculative decoding, optimized KV-state management, and smaller companion variants could improve deployability. Until documentation appears, I would treat all of them as things to investigate—not things to promise.

The benchmark bar K4 would inherit

There are no published K4 benchmark results. There is, however, a K3 baseline against which a successor can eventually be evaluated.

The following values are reported in the official K3 model card:

Benchmark	Kimi K3	GPT-5.6 Sol	Claude Fable 5	Claude Opus 4.8
GPQA Diamond	93.5	94.1	92.6	91.0
DeepSWE	67.5	73.0	70.0	59.0
ProgramBench	77.8	77.6	76.8	71.9
Terminal-Bench 2.1	88.3	88.8	88.0	84.6
FrontierSWE	81.2	71.3	86.6	66.7
SWE-Marathon	42.0	39.0	35.0	40.0
Kimi Code Bench 2.0	72.9	64.8	76.9	71.7
BrowseComp	91.2	90.4	88.0	84.3
DeepSearchQA (F1)	95.0	Not reported	94.2	93.1
ResearchRubrics	76.2	73.8	Not reported	73.5
GDPval-AA v2 (Elo)	1686	1736	1747	1593
SpreadsheetBench 2	34.8	32.4	34.7	31.6

These are Moonshot-reported comparisons, not results from one controlled independent leaderboard. Some models used different agent harnesses. The official footnotes describe fallbacks, cyberguards, hardware substitutions, reasoning settings, and benchmark-specific procedures.

GDPval-AA v2 is an Elo rating; it is not numerically comparable with percentage-based rows. Small differences elsewhere should not be read as universal superiority.

How I read the results

GPT-5.6 Sol leads K3 on DeepSWE, suggesting a stronger result on difficult repository-level repair in this evaluation. Claude Fable 5 leads FrontierSWE, where K3 still outperforms GPT-5.6 Sol and Claude Opus 4.8.

K3’s profile is more distinctive on sustained work. It narrowly leads ProgramBench and has the highest SWE-Marathon result among these models. It also leads BrowseComp and is effectively tied with Claude Fable 5 on SpreadsheetBench 2.

That gives K4 a more useful target than “raise every score by a fixed percentage”: improve deep codebase repair and computer-use reliability while preserving long-horizon coding, browsing, and knowledge-work strengths.

I would still run workload-specific evaluations. A benchmark lead does not establish how a model behaves with a particular repository, tool interface, or verification loop.

Open weights would matter—but so would the deployment bill

K3’s combination of open weights, roughly one-million-token context, and strong long-horizon results differentiates it from proprietary models such as GPT-5.6 Sol and Claude Fable 5.

Those closed models remain important references for reasoning, software engineering, and computer-use agents. They are available through hosted APIs rather than self-hosted weights. K3 can be self-hosted, but doing so requires substantial infrastructure.

K4’s position is unresolved. If it remains open or broadly accessible while closing reliability gaps, that would be more significant than another parameter milestone. If it becomes closed and extremely expensive to serve, the practical distinction narrows.

I separate several things that are often bundled together as “openness”:

• Downloadable weights.
• Usable code.
• A workable license.
• Reproducible inference.
• Affordable hardware requirements.
• Accessible hosted APIs.

A model can satisfy the first item and still be economically inaccessible to most teams. Sparse activation and quantization do not eliminate the infrastructure implications of K3’s 2.8T scale. A larger successor could widen the gap between inspecting weights and operating them efficiently.

The release I would find most useful combines transparent weights, inference recipes, reliable tool use, and hosted access. Researchers, API consumers, and teams adapting models for private or regulated workloads need different parts of that package.

Build a K3 baseline instead of guessing a K4 route

K4 is not currently callable through a confirmed public route. I would use K3 to establish today’s baseline and keep any future model switch explicit.

If a unified multi-model API fits your evaluation setup, CometAPI offers a K3 route using kimi-k3 with POST /v1/chat/completions.

With an issued API key stored in COMETAPI_KEY, the Python request is:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["COMETAPI_KEY"],
    base_url="https://api.cometapi.com/v1",
)

response = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {
            "role": "user",
            "content": "Analyze the architecture of this software project.",
        }
    ],
)

print(response.choices[0].message.content)

That is a minimal request example, not a repository ingestion pipeline. An actual architecture evaluation needs the relevant project material supplied to the model.

I would not send production requests to a guessed kimi-k4 identifier. When an integration is published, verify the real model ID, endpoint compatibility, supported modalities, and pricing before changing routing.

My release checklist

There is no announced K4 launch month or quarter. The public reporting concerns compute procurement and development planning, so a countdown would be speculation.

It is also unknown whether a release would reach the Kimi web product, Kimi Code, Kimi Work, the Moonshot API, and a weight repository simultaneously. K3’s availability across several surfaces does not guarantee the same rollout for K4.

Before treating K4 as an upgrade candidate, I would want primary documentation covering:

Area	What needs confirmation
Architecture	Total and activated parameters, expert configuration, routing
Limits	Context window and maximum output length
Modalities	Supported inputs and outputs
Distribution	Weight repository, license, product availability
API	Model ID, endpoints, reasoning modes, pricing
Evaluation	Official results, harnesses, reproducible methodology
Deployment	Quantization formats and self-hosting hardware requirements
Schedule	Official release date

The sources worth watching are Moonshot’s technical blog, verified model repositories, Kimi Platform documentation, and a published license and model card. Parameter rumors and social posts belong below those.

For now, my position is straightforward: K4 appears to be in development, but its specifications remain largely unknown. K3 is the baseline we can inspect and test. The eventual upgrade decision should come down to more reliable completed work at an acceptable cost—not the largest number in an announcement.