Kimi K3.1 Pro Highspeed vs Pro: we measured the real speedup
Same model, twice the price. Highspeed generated text 2 to 3 times faster, but it did not start answering any sooner. A coding agent finished tasks 2.5 times faster for 1.5 times the cost.
Kimi K3.1 Pro Highspeed is the same model as Kimi K3.1 Pro, served on Moonshot's high-speed endpoint. On QuickSilver Pro it costs $4.00 / $20.00 per million tokens, twice the $2.00 / $10.00 of the standard version. The usual pitch is "about three times faster". We wanted to know how much faster it is end to end, and when the extra money buys anything.
We tested both on 2026-11-02 through the QuickSilver Pro API, in two ways: single API requests of three shapes, and a coding agent working on six tasks with hidden tests. Short answer:
- Generation speed: Highspeed generated text 2 to 3 times faster.
- Time to first token: about the same for both models. Highspeed does not start answering any sooner.
- End to end: a short answer arrived 1.7 times faster and a long code answer 2 times faster. A question about a 52,000-token log came back only 1.25 times faster.
- Coding agent: every task finished 2.5 times faster on average, for 1.5 times the cost. Both versions passed every hidden test.
Test 1: single API requests
How we tested
- Requests: streamed
/v1/chat/completionscalls with default settings, sent by a small Python script. Each model got three request types:- Short answer: "In three sentences, explain what a database index is and when it hurts write performance." About 110 input tokens.
- Long code answer: an LRU cache module with per-entry TTL, thread safety and size-based eviction, plus a pytest file. About 150 input tokens; both models wrote about 11,700 output tokens, of which about 9,400 were reasoning.
- Long input: a 52,614-token service log with one line naming the root cause of an incident. The question asked the model to quote that line and explain it.
- Runs: 8 per model and request type, 48 requests in total. The two models alternated going first, so both saw the same network and server conditions.
- No cache: every request started with a unique tag, so no request was served from the prompt cache.
- Measured: time to the first token (reasoning or answer), total time, output tokens per second after the first token, and the cost QuickSilver Pro returned in each response's usage block.
Results
Medians of 8 runs per model and request type.
| Request | Model | First token | Total time | Output tokens/s | Cost per request |
|---|---|---|---|---|---|
| Short answer | Kimi K3.1 Pro | 2.1 s | 9.8 s | 37 | $0.0028 |
| Short answer | Highspeed | 2.8 s | 5.7 s | 102 | $0.0059 |
| Long code answer | Kimi K3.1 Pro | 2.2 s | 5 min 42 s | 34 | $0.117 |
| Long code answer | Highspeed | 2.7 s | 2 min 51 s | 71 | $0.235 |
| 52K-token log | Kimi K3.1 Pro | 7.3 s | 12.4 s | 51 | $0.108 |
| 52K-token log | Highspeed | 7.4 s | 9.9 s | 148 | $0.216 |
Both models found the root-cause line in all 16 long-input runs and quoted it exactly.
What the numbers say
The speedup is in generation, not in getting started. Once text started flowing, Highspeed produced 2 to 3 times as many tokens per second. Time to first token was the same, or slightly longer on Highspeed: 2.8 seconds against 2.1 for the short answer. On the long log both models spent about 7 seconds reading the input before the first token.
So the end-to-end gain depends on the shape of the request. Total time is the wait for the first token plus the generation time. The more of a request is generation, the closer it gets to the full speedup:
- Short answer: 1.7 times faster. Waiting for the first token is a big share of a 10-second request.
- Long code answer: 2 times faster, or 2 minutes 51 seconds saved per answer.
- 52K-token log: 1.25 times faster. Most of the time goes to reading the input, so Highspeed saved about 2.5 seconds for twice the cost.
Twice the price meant twice the cost per request. Both models wrote about the same number of tokens for the same request, so each Highspeed request cost almost exactly double.
Kimi reasons a lot by default. Between 60% and 80% of the output tokens were reasoning, depending on the request type. The long code answer varied from 6,200 to 15,300 output tokens across runs of the same prompt, so the cost of a single request can swing by a factor of two either way.
Test 2: a coding agent on six tasks
How we tested
- Agent: OpenCode 1.19.4, non-interactive (
opencode run --auto), with QuickSilver Pro added as an OpenAI-compatible provider. The only thing that changed between runs was-m quicksilverpro/kimi-k3.1-proor-m quicksilverpro/kimi-k3.1-pro-highspeed. - Agent settings: a clean OpenCode config with no MCP servers, plugins or extra skills, and OpenCode's defaults otherwise. Both models got the same system prompt and tools.
- Tasks: the six tasks from our Gemini 4 Argon vs Claude Opus 5.5 test. Each is a throwaway Python repository with a one-paragraph prompt, a spec or bug report, one visible test, and a separate hidden test suite that we ran after the agent finished:
- Two-file bug fix in a shop module. 18 hidden tests.
- A duration parser implemented from a page of rules. 84 hidden tests.
- A refactor that must not change behaviour. 317 hidden tests.
- Sign-up validation with interacting rules. 84 hidden tests.
- A config-format parser with references and cycle detection. 57 hidden tests.
- A Mustache template renderer, graded against the official Mustache spec suite. 136 hidden tests.
- Runs: each task twice per model, 24 runs in total. The two models ran side by side.
- Cost: the per-request cost that QuickSilver Pro returned, summed over every request in a run.
Results
Both models passed every hidden test in every run. Averages over two runs per model and task:
| Task | Kimi K3.1 Pro: time | Kimi K3.1 Pro: cost | Highspeed: time | Highspeed: cost | Speedup |
|---|---|---|---|---|---|
| 1. Two-file bug fix | 226 s | $0.143 | 115 s | $0.251 | 2.0x |
| 2. Duration parser | 284 s | $0.149 | 135 s | $0.259 | 2.1x |
| 3. Refactor | 365 s | $0.194 | 129 s | $0.310 | 2.8x |
| 4. Sign-up validation | 263 s | $0.134 | 105 s | $0.206 | 2.5x |
| 5. Config parser | 559 s | $0.268 | 272 s | $0.477 | 2.1x |
| 6. Mustache renderer | 754 s | $0.440 | 239 s | $0.463 | 3.2x |
| Average | 409 s | $0.221 | 166 s | $0.328 | 2.5x |
All twelve runs per model together took 82 minutes on Kimi K3.1 Pro and 33 minutes on Highspeed.
What the numbers say
In an agent, Highspeed cost 1.5 times as much, not 2. About 90% of each run's input tokens were cache reads. An agent sends the whole conversation again on every request, and the repeated part comes from the prompt cache. Cache reads cost $0.20 per million tokens on both versions, so only the new input and the output pay the doubled price.
Saving four minutes cost about eleven cents. On average a task took 4 minutes less on Highspeed and cost $0.107 more.
The Mustache gap is partly luck. In one of its two Mustache runs, Kimi K3.1 Pro started a sub-agent and made 41 requests, against 11 to 18 in the other Mustache runs. That run took 18 minutes and cost $0.65. Without it, the Mustache times were 7 minutes against 4. All four Mustache runs downloaded the official spec tests and ran them before finishing. Our hidden tests for that task are the same files, so the Mustache scores are not independent.
When Highspeed is worth it
- Someone is waiting: chat, coding assistants, interactive agents. Two to three times faster generation is easy to feel. An agent task that takes 7 minutes takes about 3.
- Long answers: code generation and long-form writing, where generation is most of the time.
- Agents with long sessions: the prompt cache keeps the extra cost to about 1.5 times.
Stay on Kimi K3.1 Pro for:
- Batch jobs and pipelines, where nobody watches the clock. You pay twice as much for time nobody uses.
- Long input, short output: summarising, extraction and search over big documents. On our 52,000-token log, Highspeed saved 2.5 seconds per request at twice the price.
Limits of this test
- One day of measurements (2026-11-02). Serving speed depends on load, so another day or time could give different numbers, for either version.
- Eight runs per API request type and two runs per agent task. The agent times varied by up to 2.5 times between two runs of the same task, mostly because of how much the model chose to reason or check its own work.
- Times include network time from our client to QuickSilver Pro and on to the provider.
- Default settings only. We did not change the reasoning effort or limit reasoning tokens. Either would change speed and cost for both versions.
- One agent, OpenCode, and small Python tasks of 1.5 to 18 minutes each, not a multi-hour change in a large codebase.
Run it yourself
Stream a request to each model and watch the difference:
export QSP_API_KEY=YOUR_QSP_KEY
for model in kimi-k3.1-pro kimi-k3.1-pro-highspeed; do
echo "== $model"
time curl -sN https://api.quicksilverpro.io/v1/chat/completions \
-H "Authorization: Bearer $QSP_API_KEY" \
-H "Content-Type: application/json" \
-d "{\"model\": \"$model\", \"stream\": true, \"messages\": [{\"role\": \"user\", \"content\": \"Write a Python LRU cache with TTL.\"}]}" \
> /dev/null
done
To try both in OpenCode, add QuickSilver Pro as a provider in opencode.json:
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"quicksilverpro": {
"npm": "@ai-sdk/openai-compatible",
"name": "QuickSilver Pro",
"options": {
"baseURL": "https://api.quicksilverpro.io/v1",
"apiKey": "{env:QSP_API_KEY}"
},
"models": {
"kimi-k3.1-pro": { "name": "Kimi K3.1 Pro" },
"kimi-k3.1-pro-highspeed": { "name": "Kimi K3.1 Pro Highspeed" }
}
}
}
}
opencode run --auto -m quicksilverpro/kimi-k3.1-pro "Fix the failing test in tests/"
opencode run --auto -m quicksilverpro/kimi-k3.1-pro-highspeed "Fix the failing test in tests/"
Every request shows up in your QuickSilver Pro dashboard with its model, token counts and cost, so you can compare the two versions on your own work. Prices for every model are on the pricing page.