Kimi K3.1 Pro Ships Before Its Weights: 1M Context, $2 Input, and a Deliberate Cyber Cut

What is actually available today, and what is a promise

Three things ship now: the model on Kimi.ai, Kimi Work and the API; a Highspeed variant that runs 2 to 3 times faster at double the price; and the documentation covering a 1,048,576-token context, always-on thinking with a reasoning_effort knob of low, high or max, dynamic tool loading, and automatic context caching with 5-minute or 1-hour TTL. Access requires a top-up of at least $1, and your cumulative top-up sets your tier and rate limits.

One thing does not ship now: the weights. They are promised by November 4. That distinction changes procurement rather than engineering. If the reason you want an open-weight model is self-hosting, air-gapped inference, or escaping a vendor's rate limits, none of those benefits exist until the files are on a disk you control, and a checkpoint that lands after your evaluation window is a different candidate than one that exists today.

The API path is genuinely easy to test: the endpoint is OpenAI-compatible, so the first request is a base_url change. The trap is that everything else has defaults, and the defaults were chosen for someone else. reasoning_effort defaults to max, which is the right setting for a hard refactor and the wrong one for classifying a support ticket ten thousand times an hour.

# The API is OpenAI-compatible, which makes the first hour easy and the first
# week dangerous: you can swap a model name and never look at the defaults.
# Three defaults are worth pinning explicitly.

import os
from openai import OpenAI

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

resp = client.chat.completions.create(
    model="kimi-k3.1-pro",          # not kimi-k3; K3.1 is a different model
    reasoning_effort="high",        # low | high | max (default is max)
    max_tokens=4096,
    messages=[{"role": "user", "content": "Refactor this function and explain the diff."}],
)

print(resp.choices[0].message.content)
print("usage:", resp.usage)

# Thinking mode is always on for K3.1 Pro; reasoning_effort is the knob, and the
# default being max means an unbudgeted call spends more reasoning than you planned.
# Highspeed is a separate model id, kimi-k3.1-pro-highspeed, priced at 2x.

The price list has a line most teams forget

Input is $2.00 per million tokens, output $10.00, cached input $0.20. Those numbers make the model look like half the price of frontier proprietary models, and on a cold call it is. The line that gets skipped is the cache write: $2.00 per million for the 5-minute tier and $4.00 per million for the 1-hour tier. Since caching is automatic and the default TTL is 5 minutes, a workload with 20-minute gaps pays a write every single time.

The 1-hour tier is not a premium for nothing. It is the difference between paying once per document and paying once per turn, and at $4.00 per million write tokens against $0.20 per million cached reads, the break-even is close: two reads at the 1-hour rate beat one write plus one read at the 5-minute rate. Model it with your own gap distribution instead of a hunch.

There is a second caching detail that bites quietly. The cache is stored in blocks, and a partial block cannot be written — it bills as a miss. If your shared prefix is a prose paragraph that happens to end mid-sentence, you are paying full price on a fraction of it forever and never seeing an error.

# Pricing per million tokens (official, K3 series, all with a 1,048,576 context):
#   kimi-k3.1-pro            input 2.00  output 10.00  cached-in 0.20
#                            5m cache write 2.00   1h cache write 4.00
#   kimi-k3.1-pro-highspeed  input 4.00  output 20.00  cached-in 0.20
#
# The cache write line is the part teams miss. Caching is automatic, TTL defaults
# to 5 minutes, and a 1h write costs double. Model both before you pick a TTL.

def cost(in_tok, out_tok, cached_in=0, cache_write=0, ttl="5m", highspeed=False):
    if highspeed:
        pin, pout, pwrite = 4.00, 20.00, 4.00 if ttl == "1h" else 4.00
    else:
        pin, pout, pwrite = 2.00, 10.00, 4.00 if ttl == "1h" else 2.00
    per = (in_tok * pin + out_tok * pout + cached_in * 0.20 + cache_write * pwrite) / 1_000_000
    return round(per, 4)

# An agent that re-sends a 120k-token repo slice each turn:
#   no cache:     120k in + 2k out  -> ~0.26 per turn
#   cached reads: 120k cached + 2k out -> ~0.044 per turn
print("cold", cost(120_000, 2_000))
print("warm", cost(0, 2_000, cached_in=120_000))
print("cold with 1h write", cost(120_000, 2_000, cache_write=120_000, ttl="1h"))

# Cache is stored in blocks: a partial block cannot be written and bills as a miss.
# Keep your prefix a round number of tokens rather than a prose paragraph that
# happens to end mid-sentence.

The benchmark numbers, in context

On Terminal-Bench 4.0, which evaluates coding agents on realistic terminal tasks with strict task-specific tests, Moonshot reports 65.7% for K3.1 Pro, ahead of GPT-6 Astra at 58.2% and narrowly behind Claude Opus 5.5 at 66.4%. On Kimi Code Bench 3.0 Long-horizon, an internal benchmark, it reports 61.2% against K3's 55.95%. Those are the two numbers worth quoting, and both come from the vendor.

What that supports is a claim about parity, not leadership: a model you can call for $2 sits at the same table as models you cannot download. That is the interesting part of the release and it is also the easiest part to over-read. Terminal-Bench numbers depend on the harness, the retry policy, and the time budget, and 65.7% on someone's harness can be 55% on yours.

The practical implication is not "switch". It is that the cost of a marginal evaluation has dropped enough that running your own set is now the cheap option. Build the harness once, keep the tasks versioned, and report cost per solved task rather than a percentage — because a two-point gain at five times the price is not a gain.

# Vendor benchmarks rank models. Your eval set decides whether you can ship one.
# Run the same tasks through both models and report cost per solved task, because
# a model that scores 2 points higher at 5x the price is a different decision.

import json, subprocess, time

TASKS = json.load(open("tasks.json"))     # id -> {"prompt", "check_cmd"}

def run(model, task):
    t0 = time.perf_counter()
    out = subprocess.run(
        ["python", "agent.py", "--model", model, "--task", task["id"]],
        capture_output=True, text=True, timeout=1800,
    )
    elapsed = time.perf_counter() - t0
    solved = subprocess.run(task["check_cmd"], shell=True,
                            capture_output=True).returncode == 0
    return solved, elapsed, out.stdout.strip()

report = {}
for model in ["kimi-k3.1-pro", "your-incumbent-model"]:
    rows = [run(model, t) for t in TASKS]
    solved = sum(1 for s, _, _ in rows if s)
    report[model] = {
        "solved": solved,
        "total": len(TASKS),
        "mean_seconds": round(sum(e for _, e, _ in rows) / len(rows), 1),
        "cost_per_solved": "fill from usage logs, not from guesses",
    }
print(json.dumps(report, indent=2))

# Keep failed runs in the report. A benchmark that silently drops timeouts
# flatters whichever model gives up fastest.

Cache writes are the line item that separates a $0.04 turn from a $0.26 turn.

The cyber cut is a design choice, not a guarantee

Moonshot did something most labs describe vaguely and reports precisely. It found that cyber-related content in the mid-training corpus and cyber tasks in the RL environment mix both raised vulnerability-research performance, removed cyber-related data from both stages, and measured the result on an internal benchmark called xdev-bench-hard, where agents must develop an exploit, achieve code execution in a separate sandbox, and retrieve a secret string. The unfiltered checkpoint solves 90.5% at pass@3. The shipped K3.1 Pro solves 81.0%.

That is a real 9.5-point reduction, and the company states the principle behind it plainly: it aims not to release open weights that would extend the absolute frontier of cyber capability. Two things are simultaneously true. The reduction is measurable and it is meaningful. And it is not a guarantee, because weights that anyone can download can be fine-tuned, and 81.0% is still a capable exploit-writing agent by any historical standard.

For teams, the correct response is neither panic nor dismissal. It is to treat any capable local model as untrusted code execution with a good vocabulary: constrain filesystem paths, constrain egress, log every denied call with a reason, and keep the model out of anything that holds credentials. That posture costs an afternoon and it survives a model swap, which is more than you can say for a policy written around one checkpoint's benchmark score.

# The cyber question, as an engineering control rather than an opinion.
# Moonshot reports that removing cyber data took its internal xdev-bench-hard
# pass@3 score from 90.5% (an unfiltered checkpoint) to 81.0% for the shipped
# model. That is a real reduction and it is not the same as a guarantee, because
# anyone who downloads weights on November 4 can fine-tune them.
#
# So: assume the model is capable, and constrain what it is allowed to touch.

FORBIDDEN_PATHS = ("/etc/shadow", "/root", "~/.ssh", "~/.aws")
ALLOWED_EGRESS = {"api.moonshot.ai", "pypi.org", "files.pythonhosted.org"}

def screen_tool_call(name, args):
    if name == "shell":
        cmd = args.get("command", "")
        if any(p in cmd for p in FORBIDDEN_PATHS):
            return "deny", "credential path"
        if "curl " in cmd or "wget " in cmd:
            return "deny", "unexpected egress in shell"
    if name == "http_request":
        host = args.get("host", "")
        if host not in ALLOWED_EGRESS:
            return "deny", f"egress to {host}"
    return "allow", ""

# Log the decision and the reason for every denied call. The audit trail is the
# deliverable; the block itself is just the mechanism.

Planning around two dates

The first date is November 4, when the weights are promised. The second is a range: the K2 series stops being available to new registrations after October 31, 2026, and Moonshot plans to retire all K2 models by the end of December. If you are on K2.7 Code or K2.6, your migration window is this quarter, and the migration target is the model in this article.

Pin the model identifier in configuration, not in code, and record the pin in the same commit as the eval results. Record the reasoning_effort setting too — a regression that turns out to be a default change is the most annoying kind to debug, because nothing in the diff looks suspicious.

Then write down what would make you switch back. A fallback model id, a cost ceiling, and one quality threshold that, if it moves, ends the experiment. That sentence is the difference between an evaluation and a commitment, and it is much easier to write before the numbers arrive than after.

#!/usr/bin/env bash
# Pre-flight before you put a model with promised-but-unshipped weights in a
# production path.
set -euo pipefail

echo "== model id and variant =="
grep -R "kimi-k3" .env* config/ 2>/dev/null || echo "no pinned model id found"

echo "== reachable + reasoning default =="
python - <<'PY'
import os
from openai import OpenAI
c = OpenAI(api_key=os.environ["MOONSHOT_API_KEY"], base_url="https://api.moonshot.ai/v1")
r = c.chat.completions.create(model="kimi-k3.1-pro", reasoning_effort="low",
    max_tokens=64, messages=[{"role": "user", "content": "say ok"}])
print("ok:", r.choices[0].message.content[:40], "| usage:", r.usage.total_tokens)
PY

echo "== cache behaviour (5m vs 1h) =="
python - <<'PY'
print("reminder: TTL 5m is default; 1h writes cost 4.00/MTok, and partial blocks miss")
PY

echo "== weights date on the calendar =="
python - <<'PY'
from datetime import date
w = date(2026, 11, 4)
today = date.today()
print("weights promised by", w, "| days left", (w - today).days)
PY

echo "== K2 sunset =="
echo "no new K2 registrations after 2026-10-31; full K2 retirement by end of December 2026"

echo "== rollback =="
test -n "${FALLBACK_MODEL_ID:-}" || echo "no fallback pinned -> do not ship"

Assume capability, constrain blast radius: paths, egress, and an audit trail for every denied call.