Kimi K3.1 Pro vs Sonnet 5.5 in Claude Code: same score, Kimi cost 2.4x as much and took 8x as long
We ran the same tricky billing-date task 10 times in Claude Code, 5 with Claude Sonnet 5.5 and 5 with Kimi K3.1 Pro through Moonshot's Anthropic-compatible endpoint. All 10 passed every hidden test. Kimi checked its work more often, but averaged $0.127 and 148 seconds a run against $0.054 and 18 seconds for Sonnet.
Other checks: All 5 Sonnet runs missed “added tests for billingDates”; All 5 Sonnet runs missed “ran tests after last edit”; All 5 Kimi runs missed “added tests for billingDates”; Kimi runs 4 and 5 missed “ran tests after last edit”. Kimi's costs are worked out from its token usage at Moonshot's published kimi-k3.1-pro prices, not Claude Code's cost figure, which assumes Anthropic prices. No run in either column added tests to the repo.
Kimi K3.1 Pro came out on Oct 23, and Moonshot says it’s built for coding agents, Claude Code included. Its list prices for input and output tokens, $2 and $10 per million, are the same as Sonnet 5.5’s. We wanted to know what it’s like to swap it in: same Claude Code, same task, only the model changed.
The setup
We reused the task from our “think hard” recipe: a small subscription billing module with one empty function, billingDates(start, rule). The spec is a comment above it, full of traps: month ends (Jan 31, Feb 28, Mar 31 without drifting to the 28th), leap years, count, until and skip together, a RangeError for dates that don’t exist like 2026-02-30, and the same results on servers in Chicago and Auckland.
The prompt, the same in every run:
Implement billingDates() in src/schedule.js. The spec is in the comment above it.
We ran it 5 times with each model, all fresh runs on Oct 25 with Claude Code 2.1.302:
- Sonnet 5.5: Claude Code’s normal setup, talking to Anthropic.
- Kimi K3.1 Pro: the same Claude Code, pointed at Moonshot’s Anthropic-compatible endpoint (
ANTHROPIC_BASE_URL=https://api.moonshot.ai/anthropic) with--model kimi-k3.1-pro. We also set Claude Code’s small/fast, Haiku, Sonnet, Opus and subagent model names tokimi-k3.1-pro, so nothing went to Anthropic. The usage data for every Kimi run listskimi-k3.1-proas the only model called.
Same repo, same allowed tools, same 30-turn limit. The repo had one test for billingDates, a mid-month start billed monthly. Afterwards, four hidden test files neither model saw checked the spec.
How we priced Kimi. Claude Code’s cost figure uses Anthropic’s prices, so for Kimi it’s wrong. It said $0.330 a run. We worked Kimi’s cost out from the token usage each run reported, at Moonshot’s published kimi-k3.1-pro prices: $2.00 per million input tokens, $0.20 per million cached input tokens, $2.00 per million tokens written to the cache, and $10.00 per million output tokens. Sonnet’s cost is Claude Code’s own figure at Anthropic’s list prices.
We checked the Kimi figures against the Moonshot account. Its balance went from $25.00 to $24.19985 over these 5 runs plus one setup run, a drop of $0.800. Our token math for the same 6 runs comes to $0.800 ($0.7998).
What happened
| Sonnet 5.5 | Kimi K3.1 Pro | |
|---|---|---|
| All four hidden spec tests passed | 5 of 5 | 5 of 5 |
| Month-end dates (hidden test) | 5 of 5 | 5 of 5 |
| count, until and skip together (hidden test) | 5 of 5 | 5 of 5 |
Rejects bad input with RangeError (hidden test) |
5 of 5 | 5 of 5 |
| Same dates in any server time zone (hidden test) | 5 of 5 | 5 of 5 |
npm test passes |
5 of 5 | 5 of 5 |
Added tests for billingDates |
0 of 5 | 0 of 5 |
| Ran tests after its last edit (runner check) | 0 of 5 | 3 of 5 |
| Average cost per run | $0.054 | $0.127 |
| Cost range | $0.046 to $0.064 | $0.087 to $0.178 |
| Average turns | 5.6 | 12.8 |
| Average time per run | 18.3s | 147.9s |
| Time range | 15.4s to 22.4s | 106.9s to 237.2s |
| Average output tokens | 2,569 | 6,315 |
| Average input tokens (incl. cached) | 82,815 | 209,780 |
Claude Code 2.1.302, 5 runs per column. Every run, check and diff: run data.
What we learned
Both models got the logic right every time. All 10 runs worked out each monthly date from the start date rather than the previous one, did their date math in UTC, and checked that a date really exists in its month. The two models wrote much the same function.
Kimi did more homework. Every Sonnet run read src/schedule.js and started writing. Every Kimi run first looked around the repo and read package.json and the existing tests before editing. Kimi also ran npm test far more: 4 of 5 Kimi runs ran it successfully after their last edit to src/schedule.js. The runner’s check counts 3, because one run (Kimi run 4) wrote a scratch file in /tmp after its last npm test, and the check counts any file write as an edit. The fifth Kimi run tried npm test --prefix <path>, which our allowed-commands list doesn’t match, so it was blocked. Four of the five Kimi runs ended by saying npm test passed, which was true. The fifth said its tests hadn’t run.
Sonnet tried to check its work but got blocked. Every Sonnet run tried a quick check with node or a scratch script in /tmp. Our test setup only allows npm test, npm run, node --test, git diff and git status, so those were blocked, and all five Sonnet runs finished by saying the code was untested. In a normal session you’d probably have approved the check. Every Kimi run also tried an extra edge-case script, and those were blocked too. Note that the repo’s one existing test only covers a mid-month start, so npm test passing says little about the edge cases.
Kimi cost about 2.4 times as much per run. Both charge $2 per million input tokens and $10 per million output tokens, so the difference is how much each used. Kimi took 12.8 turns on average against 5.6, read about 2.5 times as many input tokens (most of them cached) and wrote about 2.5 times as many output tokens. That added up to $0.127 a run against $0.054.
Kimi was about 8 times slower. 147.9 seconds a run on average, against 18.3. Its slowest run took 237.2 seconds. We used the standard kimi-k3.1-pro. Moonshot also sells a “highspeed” version at twice the price, which we didn’t test.
The endpoint worked. Over 5 runs and 64 turns, tool calls, edits, permission prompts and thinking all worked through Claude Code with no API errors and no retries. One extra setup run before these 5 isn’t counted. It also passed every hidden test.
Neither added tests. No run in either column added a test for billingDates to the repo. If you want tests, ask for them, as in our tests-first recipe.
Ten runs is a small sample, and this is one task, written in JavaScript, with a clear spec. On a task where Sonnet gets something wrong, Kimi’s extra checking might pay for itself. We haven’t tested that. We ran Kimi through its Anthropic-compatible endpoint, so this is Kimi inside Claude Code’s prompts and tools, not Kimi in its own coding agent. We also don’t know what reasoning setting that endpoint uses by default. Prices and speeds are from Oct 25, 2026. Kimi’s speed may also change as the new model’s load settles.
The recipe
- Kimi K3.1 Pro can drive Claude Code. Set
ANTHROPIC_BASE_URLto Moonshot’s Anthropic endpoint, use your Moonshot key, and set every model name Claude Code uses (including the small/fast one) tokimi-k3.1-pro, so nothing goes to Anthropic. - Don’t trust Claude Code’s cost line with another backend. It priced Kimi at $0.330 a run. Worked out from tokens at Moonshot’s prices, it was $0.127.
- Same token prices didn’t mean the same bill. Kimi used more turns and more tokens, and cost about 2.4 times as much as Sonnet on this task.
- Budget for the wait. About 2.5 minutes a run against under 20 seconds. That’s fine for a background job and slow for back-and-forth work.
- On a well-specified task, both got it right. All 10 runs passed every hidden test.