Result first: on one streamed prompt through AIHubMix, Kimi K3.1 Pro Highspeed generated 138–150 tokens per second against 85–88 for K3.1 Pro. That's 1.6–1.75×, below Moonshot's "approximately 2–3×". It costs exactly twice as much per input and output token, and it's the same model. So the engineering question isn't which one is better. It's whether a given workload is bound by model output, which Highspeed speeds up, or by tools, tests and queues, which it doesn't.
This post gives a script that times both IDs on your own prompt, the spot-check numbers, the arithmetic that turns seconds into dollars, and the failure modes that make Highspeed look slower than it should.
What you're choosing between
Moonshot's Kimi Code model docs describe Highspeed as "the high-speed version of K3.1 Pro, with the same capabilities, faster output, and about twice the quota usage of the regular version". The K3.1 Pro tech blog gives the same 2–3× figure and lists both IDs on the Kimi API.
| K3.1 Pro | K3.1 Pro Highspeed | |
|---|---|---|
| Kimi API / AIHubMix ID | kimi-k3.1-pro | kimi-k3.1-pro-highspeed |
| Kimi Code ID | k3.1-pro | k3.1-pro-highspeed |
| Speed (Moonshot) | Regular | About 2–3× |
| Moonshot input / output | $2.00 / $10.00 | $4.00 / $20.00 |
| Moonshot cached input | $0.20 | $0.20 |
| Moonshot cache write, 5m / 1h | $2.00 / $4.00 | $4.00 / $8.00 |
| Moonshot CN input / output | ¥13 / ¥68 | ¥26 / ¥136 |
| Moonshot CN cached input / cache write 5m | ¥1.30 / ¥13 | ¥1.30 / ¥26 |
| Kimi Code quota | 1× | About 2× |
Prices are per million tokens, from Moonshot's USD and CN pricing pages on 24 October. Both IDs are also listed on AIHubMix: see the K3.1 Pro and K3.1 Pro Highspeed model pages.
Same model means same rules: thinking is always on, reasoning_effort takes low, high or max with max as the default, and sampling is fixed. Cached input is the one price that doesn't double (cache writes do), which matters for agent loops (below). For reference, Moonshot lists K3 at $3.00 / $15.00, so Pro is 33% cheaper per token than K3 and Highspeed is 33% dearer.
Prerequisites
- Python 3.8+ and the OpenAI SDK (
pip install --upgrade 'openai>=1.0') - An AIHubMix key in
AIHUBMIX_API_KEY; the quick start covers keys and base URLs - Chat Completions, which the script uses. AIHubMix also serves both IDs on Messages; Responses returns 404 for the main IDs
The timing script
It streams the same prompt through both IDs and records three things: when the first token arrives (reasoning or answer), when the first answer token arrives, and the total. Output speed is completion tokens divided by the time after the first token, the same definition the spot check used.
import os, time
from openai import OpenAI
client = OpenAI(base_url="https://aihubmix.com/v1", api_key=os.environ["AIHUBMIX_API_KEY"])
PROMPT = ("Write a clear 600-word explanation of how a hash map handles collisions, "
"with one short code example in Python. Plain prose, no headings.")
for model in ["kimi-k3.1-pro", "kimi-k3.1-pro-highspeed"]:
start = time.time()
first_token = first_answer = usage = None
stream = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": PROMPT}],
reasoning_effort="low",
max_completion_tokens=16384,
stream=True,
stream_options={"include_usage": True},
)
for chunk in stream:
if chunk.usage:
usage = chunk.usage
if not chunk.choices:
continue
delta = chunk.choices[0].delta
now = time.time() - start
if first_token is None and (getattr(delta, "reasoning_content", None) or delta.content):
first_token = now
if first_answer is None and delta.content:
first_answer = now
total = time.time() - start
details = usage.completion_tokens_details
reasoning = details.reasoning_tokens if details else 0
speed = usage.completion_tokens / (total - first_token)
print(f"{model}: first answer {first_answer:.1f}s, total {total:.1f}s, "
f"{usage.completion_tokens} tokens ({reasoning} reasoning), {speed:.0f} tok/s")
if not reasoning:
print(" no reasoning tokens: this response did not come from K3.1 Pro")
Notes:
- No
temperature. Both IDs returned400 invalid temperature: only 1 is allowed for this modelon AIHubMix for 0.2. -
max_completion_tokens=16384leaves headroom. The spot check capped at 8,192 and one Pro run hit it. - The last check catches the ID trap described below. Zero reasoning tokens means another model answered or thinking got switched off: Moonshot rejects thinking-off requests for K3.1 Pro, but on 24 October AIHubMix returned 200 with no reasoning for one.
- Run each model several times. One run of a reasoning model is noise.
What the spot check returned
On 24 October, AIHubMix ran the prompt above through the main IDs, kimi-k3.1-pro and kimi-k3.1-pro-highspeed, streamed, at reasoning_effort: low, with an 8,192-token cap, three runs per model. One Pro run hit the cap. One prompt and three runs per model make this a spot check, not a benchmark. An earlier run through AIHubMix's coding channel (coding-kimi-k3.1-pro and coding-kimi-k3.1-pro-highspeed) gave a similar ratio: 153–169 against 95–97 tok/s.
| K3.1 Pro | K3.1 Pro Highspeed | |
|---|---|---|
| Output speed | 85.5–87.6 tok/s | 138.1–149.9 tok/s |
| First reasoning token | 3.6–4.5 s | 2.0–3.0 s |
| First answer token | 71–91 s | 40–58 s |
| Total time | 80–99 s | 43–60 s |
| Reasoning tokens | 5,561–7,356 | 5,135–7,229 |
| Completion tokens | 6,490–8,192 | 6,008–8,071 |
What the numbers say:
- Speed ratio 1.6–1.75×. Highspeed's slowest run (138 tok/s) was 1.6× Pro's fastest (88); its fastest (150) was 1.75× Pro's slowest (85.5). End to end: 43–60 s against 80–99 s.
-
Reasoning dominates. At
low, both still reasoned 5,100–7,400 tokens before an answer of 830–930 tokens: 85–90% of every completion. - Highspeed speeds up the reasoning too. Reasoning is model output, so the first answer token moved from 71–91 s to 40–58 s. Both started streaming reasoning in 2–5 s. If your UI hides reasoning, users see the first word about 30 s sooner on average.
Turning seconds into dollars
Estimate, with assumptions: 114 input tokens (the test prompt), 7,300 completion tokens per answer (the six runs averaged about 7,290), and the average speeds of 87 and 144 tok/s, at Moonshot's list prices.
K3.1 Pro: 114 × $2.00/M + 7,300 × $10.00/M = $0.0002 + $0.0730 ≈ $0.073 7,300 / 87 ≈ 84 s
Highspeed: 114 × $4.00/M + 7,300 × $20.00/M = $0.0005 + $0.1460 ≈ $0.146 7,300 / 144 ≈ 51 s
Difference: ≈ $0.073 per answer for ≈ 33 s → ≈ $0.13 per minute saved, ≈ $8 per hour
At Moonshot's CN list, the same answer is about ¥0.50 on Pro (114 × ¥13/M + 7,300 × ¥68/M) and about ¥1.00 on Highspeed (114 × ¥26/M + 7,300 × ¥136/M).
The rate is independent of answer length, because almost the whole bill is output. Each extra $10.00 per million output tokens buys about 76 minutes at these speeds (1M ÷ 87 ≈ 11,490 s vs 1M ÷ 144 ≈ 6,940 s). At Moonshot's full 2–3× it would buy 96–128 minutes, or $0.08–0.10 per minute. Higher effort (the default is max) raises seconds and dollars together; the per-minute rate holds as long as the speed ratio does, which wasn't measured at max.
$8 an hour is cheap if a developer is blocked on each turn, and wasted if nobody is waiting.
Failure modes
Highspeed barely helps an agent loop
Moonshot's FAQ, under "Why isn't Highspeed noticeably faster?":
Highspeed only speeds up model output. Tool calls (reading/writing files, running commands, etc.) and script execution are unaffected, so when they take up most of a turn the overall speedup feels small.
Illustration with stated assumptions: a turn writes 1,500 tokens (reasoning plus a tool call), then runs tests for 20 s; context is 60,000 tokens with 95% cache hits; Moonshot's list prices; cache writes and prompt processing left out.
Time: Pro 17 s + 20 s = 37 s Highspeed 10 s + 20 s = 30 s → 1.2× faster
Cost: Pro 3,000 × $2.00/M + 57,000 × $0.20/M + 1,500 × $10.00/M ≈ $0.006 + $0.011 + $0.015 ≈ $0.032
Highspeed ≈ $0.012 + $0.011 + $0.030 ≈ $0.053 → 1.65× the bill
Same-priced cache hits keep the premium under 2×, but the tests don't get faster.
A mistyped ID silently drops thinking
In Kimi Code, "a mistyped model ID falls back to K2.8 Preview without thinking", and for Highspeed specifically "a wrong value silently falls back to K2.8 Preview without thinking — no speedup". No error, older model, no reasoning, no speed gain. The IDs differ by surface:
- Kimi Code:
k3.1-pro-highspeed - Kimi API and AIHubMix:
kimi-k3.1-pro-highspeed - AIHubMix coding channel:
coding-kimi-k3.1-pro-highspeed
Kimi Code's docs list only k3.1-pro-highspeed and kimi-for-coding-highspeed as valid there, so check the API-style ID before pasting it into a Kimi Code config. AIHubMix fails loudly instead: on 24 October, kimi-k3.1-pro-highsped returned 400 with "This model ID is incorrect". Detection: Moonshot documents that K3.1 Pro rejects requests with thinking disabled, so a normal response always has reasoning_content (Chat Completions), a thinking block (Messages) and nonzero reasoning_tokens. On AIHubMix a thinking-off request wasn't rejected; it returned 200 with no reasoning, which the same check flags.
Toggling mid-session costs a prefill
Kimi Code: switching models or effort "invalidates the existing context cache, requiring a new prefill and increasing token usage". Pick Pro or Highspeed per session.
Kimi Code quota runs out twice as fast
| Kimi Code | K3.1 Pro | K3.1 Pro Highspeed |
|---|---|---|
| New plans | Plus and above | Pro and above |
| Legacy plans | Moderato and above | Allegretto and above |
| Quota use | 1× | About 2× |
The 1M context window for K3.1 Pro needs Pro and above (Allegretto and above on legacy plans). For comparison, the older K2.7 Code Highspeed (kimi-for-coding-highspeed) is about 6× speed for 3× quota.
The precedent: labels vs rolling measurements
Moonshot's parameter reference says "kimi-k2.7-code-highspeed is the same model as kimi-k2.7-code with identical parameter constraints; only the output speed differs". AIHubMix prices it at 2× the base model, cache reads included. Its model page advertises "approximately 180 Tokens/s and up to 260 Tokens/s in short context scenarios", while AIHubMix's rolling throughput on the same page read about 29 tok/s on 24 October, level with the base model's routes (about 13–30 tok/s). The page doesn't say how throughput is averaged, so this isn't proof the variant is slow. It's a reason to time your own traffic before paying double.
Decision rule
- Highspeed when a person waits on model output: interactive coding, user-facing chat on K3.1 Pro, demos and fast prototyping loops.
- Pro when tools, tests, CI or a queue set the pace, for batch jobs and evals, and on Kimi Code plans near their quota.
-
Plain Pro first, if you're leaving K3 because it's slow. In the same main-ID run, Kimi K3 at
lowreasoned about as much (3,013–7,051 tokens) but streamed at 22–26 tok/s and took 154–309 s, against 80–99 s for K3.1 Pro. Pro already cut the wait to less than half on average, at a lower per-token price; Highspeed's extra 1.6–1.75× costs double. One prompt on one day, and answer quality wasn't compared.
Both IDs are side by side on the AIHubMix compare page, which includes a cost calculator.
What this doesn't show
- One prompt, three runs per model,
loweffort only.maxeffort wasn't timed. - No answer-quality comparison. Moonshot says capabilities are identical; nothing here tests that.
- The agent-turn and per-minute figures are estimates from stated assumptions, not measurements.
Keep reading: the Kimi K3.1 Pro series
- If you haven't settled whether K3.1 Pro itself is worth the move from K3, this covers what changed and what a real task costs: Kimi K3 to K3.1 Pro: What Carries Over, What Breaks, and How to Measure the Bill
- The ID trap is one of several ways a switch goes wrong; this one covers the 400 errors and the max-effort default that drives both the wait and the bill: Kimi K3.1 Pro Migration Guide: the 400s, the Quiet Failures, and a Claude Code / Codex Config
- If you're paying for speed, check how K3.1 Pro compares with its rivals on the same front-end task and on cost per task: Kimi K3.1 Pro vs Qwen 4 vs Claude Fable 5.5 for Front-End Work: Benchmarks, Cost per Build, and a Three-Model Test Script
Top comments (0)