跪拜 Guibai
← Back to the summary

Kimi K3.1 Leaves a Paper Trail: Kibitz on LMArena, SGLang Hardening PRs, and an Engineering Release in the Making

Kimi K3.1 Suspected on LMArena: Anonymous Codename Kibitz, Six SGLang Hardening PRs in One Day, Possible Announcement by Month-End

Author: Behaviour

A Codename, Four Pieces of Circumstantial Evidence in One Day

In the early morning of 2026-10-22, two anonymous models appeared on LMArena: Kibitz and Kalmia. The names carried no vendor prefix, and screenshots of battle records spread quickly. The general consensus in the community is that Kibitz is the anonymous codename Moonshot AI gave to its new Kimi model, and that K3.1 is being warmed up.

image

Caption: Arena official WebDev Arena leaderboard (2026-10-22 snapshot, 921,000 votes, 150 models): GPT-6 Astra (Max) ranks 2nd with 1775 points, Kimi K3 (Max) ranks 16th with 1655 points, showing the comparison baseline discussed here on the same board.

Same-day evidence was also dense. Some say two K3.1 deployment adaptation commits appeared in the SGLang repo; one write-up says a third-party hosting platform has already run a K3.1 deployment; others claim to have seen K3.1 response records at the Kimi Coding API endpoint. All three point in the same direction: this version does not just exist, it has already gone through the serving chain.

Seen historically it is more interesting. Kimi K2 debuted exactly this way. The LMArena official blog remembers it clearly: K2 competed anonymously under the name Kibitz, took first place on Hard Prompts (1412 points), and was fourth overall, behind Grok 4, Gemini 2.5 Pro, and ChatGPT o3. It was the first open-weight model to make the overall top 5. Later K2 Thinking (K2-Thinking-0711) took the same path and entered the top 5 in its first week.

Yes, Kibitz is not a new name. K2 used it, and it appeared again in 2026. Whether that is corroboration or coincidence is discussed at the end.

The foundation is solid, so let me make the foundation clear.

The Base, Kimi K3: Full Parameter Table

K3 has already been officially released and fully rolled out. The Kimi open platform (platform.kimi.ai, redirected from platform.moonshot.ai via 301) carries a site-wide banner saying "Kimi K3 has launched", and the documentation says it is "Kimi's most capable model to date, with a 1M-token context window and native visual understanding", positioned for long-horizon coding and end-to-end knowledge work. Four models are on sale: Kimi K3, Kimi K2.7 Code, Kimi K2.6, plus a model list page.

2.8 trillion total parameters, 104B activated, 1M context - these three numbers are its identity. Let me copy out the full architecture table, because it is genuinely useful when writing code:

Item Value
Total parameters / activated 2.8T / 104B
Layers 93 (including 1 Dense layer)
Attention 69 layers KDA + 24 layers Gated MLA
Hidden Dim 7168, 96 heads
MoE 896 experts, 16 selected, plus 2 shared experts
Latent MoE dimension 3584 (per-expert MoE Hidden 3072)
Vocabulary / context 160K / 1,048,576
Activation function SiTU-GLU
Vision encoder MoonViT-V2, 401M parameters
Quantization MXFP4 weights + MXFP8 activations (quantization-aware training)

The model card calls it the "world's first open 3T-class model", and claims the new architecture (KDA, Attention Residuals, Stable LatentMoE) gives roughly 2.5x scaling-efficiency improvement over K2. In practice: 1M context with 104B activated parameters means you can fit an entire medium-sized code repository, and the cost is that only 16 experts are awakened per layer - a very aggressive tradeoff between memory and speed.

image

Fig: Kimi K3 official Coding benchmark chart (DeepSWE / FrontierSWE / Terminal Bench 2.1 / Program Bench / SWE Marathon), K3 compared directly with OpenAI and Anthropic flagships.

A bit more on KDA. K3's text backbone is KimiLinear, and all 69 attention layers use KDA (the implementation file header marks full-rank KDA gate and attn_res_block_size). The linear route grows more slowly in overhead on long sequences than standard attention, which is why a 1M window is feasible; the remaining 24 layers keep Gated MLA. My reading is that KDA handles long-range throughput, while the MLA part handles accuracy, with each doing its own job. The "quantization-aware training" entry is also valuable: MXFP4 is aligned to this precision during training, so the accuracy drop is much smaller than compressing after training. This is also the precondition that allows DeepInfra to go straight to mxfp4 deployment.

image

Fig: MoonshotAI/Kimi-K3 official GitHub repo card (9k stars / 761 forks), the open-source base repo for K3.1, which can also serve as evidence of repo popularity.

The weight repo was created on 2026-07-27, has more than 8,900 stars, and its license is marked Other (corresponding to the Kimi K3 License). Along the way, let me correct a widely circulated claim: the so-called "7-16 topped Frontend Code Arena with 1679 points" happened 11 days before the repo was created. 7-16 is more likely the scoring date of anonymous Arena testing; open source came at the end of July. Do not conflate the two.

Three Paths You Can Run Right Now

1. Direct call via DeepInfra

moonshotai/Kimi-K3 is already online on DeepInfra, with mxfp4 quantization, a 1,048,576 context, and modality marked Text + Image. Pricing is $2.85 input / $14.25 output / $0.285 cache hit, all per 1M tokens. The API is OpenAI-compatible, and curl works directly:

curl https://api.deepinfra.com/v1/openai/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DEEPINFRA_TOKEN" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [
      {"role": "user", "content": "Here is a build log. Classify the errors, list the three most frequent causes and suggested fixes:\n<log content>"}
    ],
    "max_tokens": 2048
  }'

K3 uses full reasoning effort by default. It thinks for a long stretch before producing an answer, so do not assume it is hanging when the first token takes ten to twenty seconds. Watch two things in the response: whether the cache-related fields in usage are non-zero (the standard structure of OpenAI-compatible interfaces), and the actual consumption of completion tokens. The latter directly determines the bill, and K3's output price is not cheap. I will calculate it for you below.

2. Official platform

The platform.kimi.ai documentation is very explicit: the examples default to the latest model kimi-k3, and reasoning strength goes through the top-level request field reasoning_effort, supporting low / high / max, with max as the default.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["KIMI_API_KEY"],
    base_url="https://api.moonshot.ai/v1",  # Use the endpoint shown in the console
)

resp = client.chat.completions.create(
    model="kimi-k3",
    reasoning_effort="high",   # If omitted, the default is max, which is slow and expensive
    messages=[{"role": "user", "content": "Review this diff, focusing on concurrency issues"}],
)

reasoning_effort is a top-level field. It does not go in messages and it is not a nested structure inside extra_body. This is the easiest place to trip up when migrating scripts from other OpenAI-compatible endpoints. Use low during exploration, and switch to max for acceptance.

Tool calling follows the same flow as OpenAI: include a tools array in the request, receive tool_calls in the response, execute locally, put the result back with role=tool, and get the final answer on the second round. A request body looks like this:

{
  "model": "kimi-k3",
  "reasoning_effort": "high",
  "messages": [{"role": "user", "content": "Look at the latest open issue in the MoonshotAI/Kimi-K3 repo"}],
  "tools": [{
    "type": "function",
    "function": {
      "name": "list_issues",
      "description": "List issues of a specified GitHub repository",
      "parameters": {
        "type": "object",
        "properties": {
          "repo": {"type": "string"},
          "state": {"type": "string", "enum": ["open", "closed"]}
        },
        "required": ["repo"]
      }
    }
  }]
}

Once you get the parameters the model filled in inside tool_calls, run the GitHub API locally, put the result back into the conversation, and send it again. Only then do you get the final answer. K3's reliability in this step is backed by numbers: MCPMark-Verified 94.5, one of the items where it beats Fable by the largest margin in the official benchmark table. The documentation also has a dedicated page, K3 API Tool Calling Best Practices, and it pushes K3 for agent scenarios. This aligns with the leaked direction that K3.1 focuses on improving deployment and tool-call stability.

Two more sentences worth remembering: for pure code generation and editing scenarios where you want faster output, switch to kimi-k2.7-code-highspeed; to use K2.6, write kimi-k2.6. Vision input has limits: images should be no more than 4K resolution, and video no more than 1080p.

3. Self-host with SGLang

The main branch already fully supports K3, with the implementation in python/sglang/srt/models/kimi_k3.py, 3867 lines. The file header comment lists everything K3-specific: Attention Residual (attn_res_block_size), Latent MoE (routed_expert_hidden_size), SiTU activation, MLA output gate, full-rank KDA gate; text backbone KimiLinear, vision tower MoonViT3d.

pip install "sglang[all]"

python -m sglang.launch_server \
  --model moonshotai/Kimi-K3 \
  --tp 8 \
  --trust-remote-code

This is a generic starting command; set tp according to your GPUs. MXFP4 weights, even at 4 bits, take more than 1.4TB. Eight 141GB cards add up to a bit over 1.1TB, so they cannot fit the full weights. For most people, self-hosting stops at reading the code.

image

The real focus is on the 10-22 PRs: #45817 moves shared-expert output to the production stream, #45757 does native output validation and terminal failure propagation, #45721 and #45716 change tool-call parameters from whole-buffer buffering to incremental streaming, #45713 enables the KDA fused decode kernel by default on AMD gfx950, and #45856 plus #45828 do FP8 decode and SiTU quantization.

The PRs concentrated in one day, all fixing streaming, failure propagation, and quantization - the kind of thing that only gets patched up before exposing an external API. This is the hardest evidence in the community's judgment that K3.1 is near: the inference stack is being polished for a new version, not patching the old one.

Pitfalls and Tips

Output price. $14.25/M tokens is 4x the price of K2.6 (DeepInfra: $0.75 in / $3.5 out, 262K context). For a 1M-context model, prompts can easily reach hundreds of thousands of tokens. On the input side, cache hits can bring the cost down to $0.285, but cache writes are billed separately: retaining for 5 minutes costs 1.25x ($3.5625/M), and retaining for 1 hour doubles the price to $5.70/M. For long conversations with high-frequency calls, do this math before going in.

Default max. If you do not write reasoning_effort, the model thinks at full strength, and latency and cost both go up. Write it explicitly in scripts; do not rely on defaults.

Do not treat rumors as launched. In DeepInfra's full model list (/v1/openai/models, 176 models), the Kimi family only has K2.6 and K3, with no K3.1; official documentation has no K3.1; SGLang's main branch has no kimi_k3_1.py (404); and a full-text search of the sglang repo for "K3.1", "Kalmia", and "Kibitz" all return 0 results. The claim that "DeepInfra is already running a K3.1 deployment" has no counterpart in the public model list, at least, and can only be treated as a rumor.

Comparison: No GPT-6 Astra in the Official Statement

The official benchmark table compares six columns: Kimi K3 (max), Claude Fable 5 (max, w/ fallback), GPT-5.6 Sol (max), Claude Opus 4.8 (max), GPT-5.5 (xhigh), and GLM-5.2 (max), with a footnote stating that all scores use reasoning_effort=max and temperature=1.0.

Hard numbers where K3 wins: GPQA Diamond 93.5 (Fable 92.6), Terminal-Bench 2.1 88.3, FrontierSWE 81.2, SWE-Marathon 42.0 vs Fable's 35.0, BrowseComp 91.2, and MCPMark-Verified 94.5 vs 87.4. These numbers look increasingly extraordinary, but they all come from the official model card.

There are plenty of losses: HLE-Full 43.5/56.0, where Fable is 53.3/63.0; CritPt 23.4 vs 28.6; GDPval-AA v2 Elo 1686, with Fable at 1747 and GPT-5.6 Sol at 1736; even Kimi's own Code Bench 2.0 is 72.9 vs Fable's 76.9.

image

Fig: Kimi K3 official General Agents / Visual Agents benchmark chart (GDPval-AA v2 Elo, JobBench, Automation Bench, BrowseComp, etc.), showing K3's overall position against GPT and Claude.

These numbers pour cold water on the claim that K3 is "chasing GPT-6 Astra directly." The official statement has no Astra as a comparison target, and the closest model, GPT-5.6 Sol, still beats K3 in GDPval Elo. SWE-Marathon and MCPMark are genuinely ahead, and long-horizon tasks plus tool calling are exactly the direction K3.1 is claimed to be polishing. That is self-consistent.

Astra's public information is also messy. One claim says it was released on 2026-06-22, with an announcement titled "Welcome to the AGI era", claiming to be the first model to reach the Preparedness Framework Critical cybersecurity threshold; another claim puts the date on 09-03. The two dates do not match, and OpenAI's official site has anti-scraping measures, so this can only be treated as a rumor. Using a model whose date cannot even be pinned down as a benchmark baseline discounts the comparison itself.

Prices placed side by side: K3 is $2.85 in / $14.25 out / 1M context, while K2.6 is $0.75 / $3.5 / 262K context. When to use which, my rule is simple: contexts over 200K, or when you need to feed images or video, you have no choice but K3; for everyday short-context coding work, K2.6 is 4x cheaper, so there is no need to force it.

Controversy and Boundaries

The reuse of the name Kibitz deserves more discussion.

The convention that "new K-series models are anonymously tested on Arena first" is real, backed by the LMArena official blog. The logic behind vendors staying anonymous is not hard to guess: blind testing keeps brand bias out, and the scores are clean; if a model really enters the top 5, the reveal day brings free publicity. K2's label as "the first open-weight model in the overall top 5" was earned that way. For developers there is also a practical benefit: during the anonymous period, you can use a model that has not been announced yet for free. That is the only part of the rumor chain that can be verified by hand.

But the fact that Kibitz appeared again in 2026 opens two interpretations: Moonshot deliberately reused the old codename for continuity, or the anonymous name pool collided. The former has stronger supporting evidence; the latter is essentially zero. There is currently no evidence to distinguish between the two.

The two K3.1 adaptation commits in SGLang and the API endpoint response records are each single-sourced and cannot be reproduced in public repos or model lists. GitHub search's full-text index has latency. That does not mean the rumor is false, and it does not mean it can be written as fact. The safe formulation is: there is a complete rumor chain, and every link in the chain has not yet been independently verified.

The version number itself is also a hint. K3 already had a small upgrade in September (K3-0903). If K3.1's improvements are concentrated on deployment and tool-call stability, then there is a considerable distance between it and "performance chasing Astra." A minor version bump plus inference-stack hardening PRs points more to an engineering iteration.

My rough ordering of the credibility of the four kinds of public traces: third-party hosting platform's model list (hard evidence; once it is listed, it is real) > inference-stack PRs (strong circumstantial evidence, but possibly just hardening for K3 itself) > Arena anonymous codename (medium, with naming-collision risk) > API endpoint sniffing records (weak; the cost of a screenshot is too low). Next time you see similar leaks, check them in this order and you will save a lot of effort.

Will There Be an Announcement at the End of the Month

If there is, the earliest signal will most likely not be at an event, but in DeepInfra's model list and SGLang's repo. When K3.1 appears in the list and kimi_k3_1.py lands in the repo, those two timings will essentially be right next to the official announcement.

My judgment: K3.1 is most likely an engineering release, focused on deployment stability and tool-call streaming, the same places SGLang is fixing. If you want a real capability leap, wait for K4.

Leave one question nobody can answer right now: how small is Arena's anonymous name pool, that K2 and K3.1 would collide on the same Kibitz.

Reference Links