Kimi K3 bills at a third of GPT-6 Astra’s per-token rate and still cost more than twice as much to finish the same seven jobs. That is not a benchmark artefact. It is what the invoice said after 42 API calls, and the reason is a single request field that most people never set.
This Kimi K3 vs GPT-6 Astra comparison skips the model cards. We gave both models the same seven tasks a sysadmin actually hands to a model, ran each task three times, then graded every answer by executing it: the awk one-liner had to print the right number, the SQL had to return the right rows, the Dockerfile had to build and run. What follows is the measured cost per task, the latency, the token accounting behind the bill, and the one setting that flips the price comparison completely, all measured in September 2026 against kimi-k3 and gpt-6-astra through OpenRouter.
What Kimi K3 and GPT-6 Astra cost per million tokens
Astra costs 3.33x more per token than K3 on both input and output. Every price below comes from each vendor’s own pricing page and was cross-checked against the broker’s catalogue.
| Per 1M tokens | Kimi K3 | GPT-6 Astra |
|---|---|---|
| Input | $3.00 | $10.00 |
| Cached input | $0.30 | $1.00 |
| Cache write | not billed separately | $12.50 |
| Output | $15.00 | $50.00 |
| Batch input / output | same as standard | $5.00 / $25.00 |
| Above 272K input tokens | no change | $20.00 / $75.00 |
That last row is the one to plan around. OpenAI’s model page states it plainly: “Prompts with more than 272K input tokens are priced at 2x input and cache rates and 1.5x output for the full request.” Crossing 272K by a single token re-prices the entire call, so a 280K-token prompt costs more than double a 270K one. Moonshot publishes a single tier across K3’s whole 1,048,576-token window, which makes Astra 6.7x more expensive on input and 5x on output once you are past the threshold.
You can pull both price cards yourself without an account:
curl -s https://openrouter.ai/api/v1/models | jq -r '.data[] | select(.id=="moonshotai/kimi-k3" or .id=="openai/gpt-6-astra") | {id, ctx: .context_length, pricing}'The Astra entry carries an overrides array that the K3 entry does not have, and it encodes exactly the surcharge quoted above:
"overrides": [
{
"min_prompt_tokens": 272000,
"prompt": "0.00002",
"completion": "0.000075",
"input_cache_read": "0.000002",
"input_cache_write": "0.000025"
}
]The seven tasks and how every answer was graded
Nothing here was scored by reading it. Six of the seven tasks produce an artefact a machine can check, so the grader runs the model’s output and compares it to a known-correct result computed independently from the fixture.
- awk one-liner: count distinct client IPs that got a 5xx in a 600-line nginx log, excluding 10.0.0.0/8. The fixture was generated with a fixed seed and the answer is 23, while the log holds 40 distinct external IPs, so a model that counts the wrong thing lands on a different number.
- SQL window function: latest deploy per service and environment from an 11-row SQLite table. Graded on exact row-for-row output.
- jq filter: pull pod names in CrashLoopBackOff with a restart count above 5 out of real
kubectl get pods -o jsonshaped input. - Python bug fix: a retry helper that swallows the final exception and returns
None. Graded by a hidden three-assertion test. - Dockerfile: multi-stage Go build,
FROM scratch, CGO off, UID 65532. Built and executed on Ubuntu 26.04.1 with Docker 29.8.0. - systemd unit: eight required directives including the
Wants=plusAfter=network-online.targetpair that people habitually get half right. - A question with no answer: which single
systemctlsubcommand lists units sorted by memory use. There is none. Denying it scores a pass, inventing one scores a fail.
Every call went through the same broker so the cost figures are comparable, and each response was saved to disk before grading. The cost numbers throughout this article are the usage.cost value the API returned per call, not an estimate multiplied out by hand. Two caveats worth stating: temperature: 0 was sent on the default runs and K3 accepts it, while Astra exposes no temperature on this endpoint so it is dropped. No seed was set on either model, and default runs capped completion at 8,000 tokens via max_completion_tokens. Model-generated shell was screened against a denylist before the grader executed it.
The run and the grading pass produce this:
The reason= column carries most of the story that follows.
Which model passed which task
Astra went 21 for 21. K3 went 20 for 21. On raw correctness across these seven tasks the two models are a tie, and any article claiming a wide capability gap on ordinary sysadmin work is not measuring ordinary sysadmin work. The same held when we put Astra up against Claude Opus 5, where the separation was in price and behaviour rather than in whether the answer worked.
| Task | Kimi K3 | GPT-6 Astra |
|---|---|---|
| awk one-liner | 3/3 | 3/3 |
| SQL window function | 3/3 | 3/3 |
| jq filter | 3/3 | 3/3 |
| Python bug fix | 3/3 | 3/3 |
| Dockerfile | 3/3 | 3/3 |
| systemd unit | 3/3 | 3/3 |
| Question with no answer | 2/3 | 3/3 |
| Total | 20/21 | 21/21 |
The two awk answers show how little separated them. Astra accumulated into an array and counted the keys at the end, K3 used the idiomatic one-pass increment. Both printed 23:
awk '$1 !~ /^10\./ && $9 ~ /^5[0-9][0-9]$/ {ips[$1]=1} END {for (ip in ips) n++; print n+0}' access.log
awk '$9 ~ /^5/ && $1 !~ /^10\./ && !seen[$1]++ {n++} END {print n+0}' access.logThe Dockerfiles were closer still. Both produced a two-stage build ending in FROM scratch with USER 65532:65532, and all six images built and printed the expected string on a real Docker host. K3 emitted a # syntax=docker/dockerfile:1 directive on every run that Astra never added, while both models reached for -ldflags="-s -w" on most builds, all stylistic preferences rather than correctness differences.
Cost per task, not cost per token
Here is where the sticker price stops predicting anything. Finishing all seven tasks cost $0.1387 on K3 and $0.0606 on Astra, so the model that is 3.33x cheaper per token produced a bill 2.29x larger.
| Task | Kimi K3 | GPT-6 Astra | K3 / Astra |
|---|---|---|---|
| awk one-liner | $0.0249 | $0.0118 | 2.10x |
| SQL window function | $0.0028 | $0.0050 | 0.57x |
| jq filter | $0.0084 | $0.0112 | 0.75x |
| Python bug fix | $0.0159 | $0.0101 | 1.57x |
| Dockerfile | $0.0098 | $0.0057 | 1.71x |
| systemd unit | $0.0069 | $0.0074 | 0.94x |
| Question with no answer | $0.0700 | $0.0094 | 7.47x |
| All seven | $0.1387 | $0.0606 | 2.29x |
K3 came out cheaper on three tasks and more expensive on four. The pattern is not random: it wins where the answer is short and the problem is well-posed, and it loses badly where the problem invites deliberation.
Swapping the price cards isolates the cause. Billing K3’s own token counts at Astra’s rates, and Astra’s counts at K3’s rates, separates “what does a token cost” from “how many tokens did it emit”:
| Token counts from | Billed at K3 rates | Billed at Astra rates |
|---|---|---|
| Kimi K3 (7,095 prompt + 26,606 completion) | $0.4204 | $1.4013 |
| GPT-6 Astra (5,457 prompt + 2,544 completion) | $0.0545 | $0.1818 |
K3 emitted 10.5x the completion tokens Astra did over the same 21 calls. A 10.5x token count comfortably beats a 3.33x per-token discount, and that is the whole arithmetic of the higher bill. The list-price column is not a model either: Astra was charged $0.1818 for those 21 calls, matching its list price to the cent with zero cache hits recorded, while K3 was charged $0.4161 against a $0.4204 list, a shade under because 1,600 of its input tokens came back as cache hits at a tenth of the input rate, worth $0.0043.
Where Kimi K3’s extra tokens come from
Almost all of them are reasoning tokens. Moonshot’s model documentation states that K3 “configures reasoning effort with the top-level reasoning_effort request field (supports "low" / "high" / "max", default "max")”. Send no effort parameter and you are buying the most expensive setting on every call.
| Task | K3 output | K3 reasoning | Astra output | Astra reasoning |
|---|---|---|---|---|
| awk one-liner | 1,572 | 1,501 | 154 | 95 |
| SQL window function | 163 | 78 | 79 | 0 |
| jq filter | 394 | 331 | 54 | 0 |
| Python bug fix | 1,029 | 916 | 168 | 69 |
| Dockerfile | 623 | 514 | 87 | 0 |
| systemd unit | 438 | 350 | 129 | 37 |
| Question with no answer | 4,649 | 4,616 | 177 | 133 |
Read the SQL and jq rows carefully. Astra spent zero reasoning tokens on both and got them right three times out of three, while K3 spent 78 and 331. On the trap question K3 spent 4,616 reasoning tokens to produce a one-sentence answer that Astra reached with 133.
The second source of extra tokens is smaller but perfectly consistent. The identical prompt bytes are counted 75 to 79 tokens higher on the K3 endpoint than on Astra’s, on all seven tasks: 495 against 416, 180 against 101, 926 against 847, and so on. That looks like fixed template overhead on the serving side rather than tokenizer drift, and on short prompts it is most of the input bill.
The third and most operationally annoying difference is spread. Three identical calls to Astra returned 79, 79 and 79 completion tokens on the SQL task and 54, 54 and 54 on jq. K3 varied on every task, up to 5.15x:
| Task | K3 tokens across 3 runs | K3 spread | Astra tokens across 3 runs | Astra spread |
|---|---|---|---|---|
| awk one-liner | 520 to 2,677 | 5.15x | 140 to 174 | 1.24x |
| SQL window function | 144 to 178 | 1.24x | 79 to 79 | 1.00x |
| jq filter | 316 to 546 | 1.73x | 54 to 54 | 1.00x |
| Python bug fix | 625 to 1,700 | 2.72x | 162 to 175 | 1.08x |
| Dockerfile | 318 to 983 | 3.09x | 82 to 90 | 1.10x |
| systemd unit | 352 to 550 | 1.56x | 126 to 130 | 1.03x |
| Question with no answer | 2,534 to 8,000 | 3.16x | 160 to 199 | 1.24x |
If you are sizing a budget per ticket rather than per month, that spread is the number that hurts. The same prompt can cost you 5x more on a Tuesday for no visible reason.
Error: finish_reason: "length" with an empty message and a full bill
K3’s single failure was not a wrong answer. On the third run of the trap question it spent the entire 8,000-token output allowance on reasoning, hit the cap, and returned a message with no content at all. The response object tells the whole story:
"finish_reason": "length"
"completion_tokens": 8000
"completion_tokens_details": { "reasoning_tokens": 8000 }
"message": { "content": null }
"cost": 0.1202172That call produced 28,622 characters of internal reasoning, zero characters of answer, and a charge of $0.12. The two sibling runs answered the same question correctly for $0.038 and $0.051. An open-ended question at max effort can therefore spin past any output cap you set and bill you in full for nothing, which is a retry-logic problem and not a quality problem: your client has to treat finish_reason: "length" with a null content field as a failure and try again, ideally at a lower effort. Astra never came close, topping out at 199 completion tokens on that question.
Setting reasoning effort to low reverses the price comparison
Pin the effort explicitly on both models and the arithmetic snaps back to what the price cards predict. This is the same seven tasks, one run each, with nothing changed but the effort field.
curl -s https://openrouter.ai/api/v1/chat/completions \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"moonshotai/kimi-k3","reasoning":{"effort":"low"},"messages":[{"role":"user","content":"..."}]}'The effect on K3 is not subtle. Reasoning tokens on the awk task fell from 1,501 to 22 and the answer stayed correct.
| Task | K3 at default | K3 at low effort | Reduction | Still correct |
|---|---|---|---|---|
| awk one-liner | $0.0249 | $0.0020 | 12.3x | yes |
| SQL window function | $0.0028 | $0.0017 | 1.7x | yes |
| jq filter | $0.0084 | $0.0078 | 1.1x | yes |
| Python bug fix | $0.0159 | $0.0062 | 2.6x | yes |
| Dockerfile | $0.0098 | $0.0021 | 4.8x | yes |
| systemd unit | $0.0069 | $0.0023 | 3.0x | yes |
| Question with no answer | $0.0700 | $0.0012 | 58.6x | yes |
Side by side, the default column and the low-effort column are barely the same model on price:
K3 finished all seven tasks for $0.0232 at low effort against $0.1387 at its default, an 83% cut with no loss of correctness. Both models scored 7 out of 7 at low effort. Astra fell from $0.0606 to $0.0476, a 21% cut, since its default already spends nothing on reasoning for well-posed problems. At matched low effort the ranking is the one the price cards imply: K3 costs 0.49x Astra, roughly half, for identical results.
Two practical notes. Low effort is not free of risk on genuinely hard problems, and this task set deliberately contains none: an 11-row SQL query and a 600-line log are not where deliberation earns its keep. Astra’s effort ladder behaves differently again, which we measured level by level in the Astra launch breakdown, where the thinking budget roughly doubles per step.
How long each task took
Astra answered faster on all seven tasks, and the gap tracks the token counts rather than any network difference. Every figure is wall-clock time for a non-streaming call, with the range across three runs in brackets.
| Task | Kimi K3 | GPT-6 Astra |
|---|---|---|
| awk one-liner | 47.2s (20.1 to 70.2) | 4.9s (4.5 to 5.1) |
| SQL window function | 5.2s (4.6 to 5.9) | 4.0s (2.5 to 6.9) |
| jq filter | 11.3s (7.5 to 13.6) | 2.7s (2.5 to 3.0) |
| Python bug fix | 24.9s (22.9 to 26.2) | 5.4s (4.7 to 6.4) |
| Dockerfile | 20.6s (7.5 to 38.3) | 3.3s (3.0 to 3.7) |
| systemd unit | 10.6s (8.3 to 13.9) | 4.0s (3.5 to 4.7) |
| Question with no answer | 92.7s (86.8 to 99.9) | 8.0s (6.0 to 11.6) |
A 92-second mean on a one-line question is disqualifying for anything interactive. Behind a queue it matters far less, and low effort brought the same question down to 2.8 seconds. The serving provider matters too: these K3 calls were served by Together, except the single 100K needle call which OpenRouter routed through Modal, and the Astra calls by OpenAI directly, so K3 latency on Moonshot’s own endpoint or on different hardware will not match these numbers exactly. Cost and token counts are properties of the model and the effort setting, latency is a property of whoever is running it.
Finding three needles in a 100K-token log
Both models found all three. We buried three maintenance tokens at 10%, 50% and 90% depth in a 2,100-line application log, asked for all three values, and both returned them exactly, with matched low effort on each side.
| Metric | Kimi K3 | GPT-6 Astra |
|---|---|---|
| Prompt tokens | 100,063 | 99,745 |
| Needles recovered | 3/3 | 3/3 |
| Completion tokens | 285 | 47 |
| Wall-clock time | 7.0s | 5.2s |
| Cost for the one call | $0.3043 | $1.2492 |
Identical answers, and Astra billed 4.11x more for the pair. That measured gap is inflated by how the call priced out: Astra’s usage came back on its cache-write rate of $12.50 per million tokens, not its $10 sticker input rate, because the prompt was cold and got written to cache. Priced at both models’ standard input rates the ratio is 3.3x, $10 against $3 per million, which matches the per-token spread. Warm the cache and Astra reads it back at $1 per million, but that is still above K3’s $0.30 cached-read rate, so K3 stays the cheaper of the two whether the context is cold or reused, and only the size of the gap moves. This single K3 needle call did not write the haystack to cache, so treat the exact reuse economics as workload-dependent. Retrieval accuracy is not the differentiator at this depth, the input bill is, and at list rates it widens to 6.7x once a prompt crosses the 272K threshold. The same 264,532-character haystack came to 99,745 tokens on Astra’s tokenizer and 100,063 on K3’s, about 2.65 characters per token for log text on both.
Error: what happens when the prompt overflows the window
The first attempt at this test used a 3,774,184-character log, which is around 1.43M tokens and well past both windows. The two APIs fail in completely different ways. K3 rejects it on token count:
"code": "start_generation_failed",
"message": "Failed to start generation: The input token count (1426093) exceeds the model's maximum context length (1048576)"Astra never reached the model at all. OpenRouter’s budget guard rejected the request up front because its maximum cost exceeded the account’s remaining credit balance, and the response carries limit_source: openrouter_credits to say so. At the above-272K rate of $20 per million, roughly 1.43M input tokens estimates near $28 for a single call, so the guard tripped before the model ran:
"code": 402,
"message": "This request's maximum cost exceeds your available credits. Add credits, or lower max_tokens or prompt size.",
"reason": "weight_exceeds_budget"Worth internalising before you point either model at a large corpus: 1.43M tokens is past both published windows, so neither model would have run it. K3 rejects it plainly on token count, while Astra’s surcharge pushed the estimated cost past a credit guard first. A surcharged model can trip a per-request cost ceiling at a prompt size a flat-rate model would still price affordably.
Capability gaps a task score does not show
Both models advertise a context window of roughly 1M tokens, and the similarity ends there. The differences below decide real integration work more often than a benchmark delta does.
| Property | Kimi K3 | GPT-6 Astra |
|---|---|---|
| Context window | 1,048,576 | 1,050,000 |
| Max output tokens | 943,718 on the endpoint tested | 128,000 |
| Input modalities | text, image, video | text, image |
| Reasoning levels | low, high, max (default max) | low, medium, high, xhigh, max (default medium) |
| Sampler control | temperature, top_p, top_k, min_p, seed, logprobs, logit_bias | seed only |
| Weights | open, 2.8T parameters | API only |
| Content moderation on the endpoint | not moderated | moderated |
The output ceiling is the one that bites first. Astra stops at 128,000 output tokens, so a single call cannot emit a large generated corpus no matter how much context you feed it. The sampler row matters for anyone building deterministic pipelines. Astra exposes only seed on this endpoint, no temperature or top_p, while K3 exposes the full set. We left seed unset on both, so the repeatability Astra showed in practice came from how little it deliberates rather than from pinning a sampler. Setting seed would harden it further.
Open weights are the structural difference. K3 can be downloaded and served on your own hardware, which is a different cost model entirely rather than a cheaper version of this one, and the practical floor for that is covered in our walkthrough of running K3 on local hardware. For a smaller open model that fits a single machine, Muse Glimmer 30B is a more realistic self-hosting target, and the wider field is tracked in the open-weight model comparison.
What this workload costs per month on each model
Take the measured mix above as one “job” of seven tasks and scale it. The numbers are per-job costs multiplied out, which is honest for a queue of similar work and optimistic for anything with longer inputs.
| Jobs per month | K3 at default effort | K3 at low effort | Astra at default |
|---|---|---|---|
| 1,000 | $138.70 | $23.20 | $60.60 |
| 10,000 | $1,387 | $232 | $606 |
| 100,000 | $13,870 | $2,320 | $6,060 |
At 10,000 jobs a month, leaving reasoning_effort unset on K3 costs $781 more than Astra for a slightly lower pass rate, while setting it to low saves $374 against Astra for the same results. The entire decision between these two models on this class of work is one request field, and the default is the expensive choice.
Two adjustments to make before trusting the table for your own workload. If your prompts routinely exceed 272K tokens, Astra’s surcharge doubles its input line and K3’s flat tier becomes decisive on price. If your work is interactive, the latency column outweighs everything in this section, and Astra’s 3 to 8 second responses against K3’s 5 to 93 seconds is the number your users will actually feel. Batch pricing narrows the gap from the other direction, halving Astra’s rates for anything that can wait.
None of this transfers cleanly to a coding agent, where the tool-call loop multiplies every one of these token counts by the number of turns. If that is the workload you are pricing, start from the agent comparison instead, and if you want K3 driving a terminal today the quickest route is Kimi CLI pointed at OpenRouter.
All 58 graded calls behind this comparison cost $2.22 in total, and the two 100K-token retrieval calls were $1.55 of that. Running your own handful of real tasks through both models costs less than lunch and beats any published benchmark, including this one.
