If you run agents through an API, the question in late October 2026 is not which of Kimi K3.1 Pro, Claude Opus 5.5 and GPT-6.1 Sol is best. It is which one is cheapest for the shape of traffic you actually send, and whether the cheaper one can do the job. On October 26, 2026 we read all three labs' own pricing and model pages and put the models through the same three hypothetical workloads. The headline rates say Kimi and Sol tie at $2 in and $10 out and Opus costs double. The worked numbers say something more useful. Each model has a quirk that a headline rate hides. Kimi K3.1 Pro cannot switch thinking off, so every request carries reasoning tokens whether you want them or not. Claude Opus 5.5 charges the highest cache write rate of the three, which matters in loops that rewrite their prefix often. GPT-6.1 Sol prices any request with more than 272K input tokens at double the input rate and one and a half times the output rate, for the whole request, not just the overage.
This post is a companion to our Kimi K3.1 Pro release guide, which covers what Moonshot shipped and when the weights are due. Here the subject is the comparison only: list prices, cache mechanics, context thresholds, effort controls, access terms and the reason no benchmark table on any of the three sites names a winner across all three.
- 01Headline rates tie Kimi and Sol; the cache rates do not.Kimi K3.1 Pro and GPT-6.1 Sol both list $2 input and $10 output per million tokens. Sol's cache read is $0.10 and its cache write $2.50; Kimi's are $0.20 and $2 (five-minute) or $4 (one-hour). Opus 5.5 is $4 in, $20 out, $0.20 read, $5 or $8 write.
- 02On a hundred-turn cached loop, our arithmetic lands at $3.99, $4.74 and $7.98.Sol, Kimi and Opus respectively, for a hypothetical loop with an 80K cached prefix, 5K fresh input and 2K output per turn, assuming every turn hits the cache. The output column, not the cache column, is what separates Opus from the other two.
- 03Sol reprices the whole request above 272K input tokens.A 272K-input, 10K-output request on Sol costs $0.644 by its list rates; at 273K it costs $1.242, because the 2× input and 1.5× output multipliers apply to the entire request. Kimi and Opus are flat across their windows.
- 04Thinking is always on for Kimi and Opus; Sol has no 'none' either.Kimi's effort runs low, high or max with max as default. Opus 5.5 defaults to medium and cannot disable thinking. Sol supports low to max with medium as default and rejects none and minimal. Budget for reasoning tokens on all three.
- 05No vendor table covers all three on one harness, so there is no winner.Moonshot compares K3.1 Pro with Opus 5.5 and GPT-6 Astra, not Sol, on its own runs. OpenAI describes Sol as near-Astra and tells you to compare on your tasks. Route by workload shape and your own evals.
01 — List PricesThe three price lists, side by side #
Every figure below is the lab's own first-party list rate, read on October 26, 2026, before tax and before any regional or fast-mode premium. We did not use aggregator or router quotes, because routers set their own rates and metadata, so this comparison keeps the purchasing channel consistent rather than combining different contracts. The three sources are the Kimi API pricing page, Anthropic's model pricing page and OpenAI's GPT-6.1 Sol model page.
Two conventions differ between the labs and matter for reading the table. Moonshot and Anthropic publish two cache write rates, one for a five-minute lifetime and one for an hour. OpenAI publishes one cache write rate on the model page for its default thirty-minute lifetime; its caching guide adds a twelve-hour option at two and a half times the input rate. The "cache read" column is what you pay for tokens the provider already has, and it is where Sol pulls ahead.
| First-party list prices in USD per million tokens, read October 26, 2026 from each lab's pricing or model page. Cache write shows the shorter and longer lifetime where two are published. | |||
|---|---|---|---|
| Rate | Kimi K3.1 Pro | Claude Opus 5.5 | GPT-6.1 Sol |
| --- | --- | --- | --- |
| Input | $2.00 | $4.00 | $2.00 |
| Output | $10.00 | $20.00 | $10.00 |
| Cache read | $0.20 | $0.20 | $0.10 |
| Cache write | $2.00 (5 min) · $4.00 (1 h) | $5.00 (5 min) · $8.00 (1 h) | $2.50 (30 min) · $5.00 (12 h) |
| Context window | 1,048,576 | 1M | 1,050,000 (922,000 input) |
| Max output | up to 1,048,576 (default 131,072) | 128K | 128,000 |
| Batch discount | None listed on the pricing page | 50% off | Batch and Flex 50% lower |
Read the cache rows as ratios and the shape of each lab's design shows. Moonshot charges a five-minute cache write at exactly the input rate and a cache read at 10% of it. Anthropic charges a five-minute write at 1.25 times input, an hour write at double, and reads at 5% on Opus 5.5, half the 10% it charges on most of its lineup. OpenAI charges a write at 1.25 times input and reads at 5% on Sol specifically, where its caching guide says most of its models read at 10%.
The failure case for the table is the batch row. Kimi's pricing page describes pay-as-you-go billing with no subscription and lists no batch tier, which does not prove one is unavailable elsewhere in Moonshot's documentation. If a nightly offline job is your main workload, Opus and Sol both halve their list rates for it and Kimi, on the page we read, does not.
02 — Three WorkloadsThree workloads, the same arithmetic #
A list price only becomes a bill when you multiply it by a token mix, so we defined three hypothetical mixes and did the sums the same way for every model. They are not measurements of any product. They are shapes that agent traffic commonly takes, chosen so a reader can swap in their own numbers. All three assume global routing, standard service tier and no regional premium. Equal token counts isolate price differences; different tokenisers, reasoning lengths and task success mean they do not predict equal costs for the same real task. The uncached Sol examples use explicit-only caching with no breakpoints, which creates no cache writes. The cached loop instead places a breakpoint after the stable 80K prefix, leaving the changing suffix at the ordinary input rate.
The first is a short tool-calling turn: 20,000 input tokens and 2,000 output tokens, nothing cached. Kimi costs 0.02 × $2 plus 0.002 × $10, which is $0.04 plus $0.02, or $0.06. Sol is identical at $0.06. Opus is 0.02 × $4 plus 0.002 × $20, which is $0.08 plus $0.04, or $0.12. On uncached short turns the headline rate is the whole story and Opus is simply double.
The second is the one that matters for agents: a hundred-turn loop with an 80,000-token prefix (system prompt, tool definitions, repository context) written to cache once and read on the other ninety-nine turns, plus 5,000 fresh input tokens and 2,000 output tokens per turn. That gives 80K of cache writes, 7.92 million cache reads, 500K of fresh input and 200K of output. The breakdown below shows each column.
The third workload is a single long-document request: 400,000 input tokens and 10,000 output, no cache. Kimi is 0.4 × $2 plus 0.01 × $10, or $0.90. Opus is 0.4 × $4 plus 0.01 × $20, or $1.80. Sol is not $0.90, because 400K is above its 272K line: the request is billed at 2 × $2 for input and 1.5 × $10 for output, so 0.4 × $4 plus 0.01 × $15, or $1.75. On this shape Sol costs almost exactly what Opus costs, and Kimi costs half of either.
The failure case for all three sums is the cache-hit assumption. The loop arithmetic assumes every one of the ninety-nine later turns finds the prefix still cached, which means each turn arrives inside the lifetime: five minutes by default on Kimi and Anthropic, thirty on OpenAI. A loop that waits on a slow tool, a human approval or a rate limit for longer than that pays the write again. A loop that edits its system prompt mid-run invalidates everything after the edit on all three. The numbers are a ceiling on savings, not a forecast.
20K in, 2K out, uncached
Opus is $0.12. With nothing cached the headline rate decides, and two of the three share it.
100 turns, 80K prefix
Kimi $4.74, Opus $7.98. Sol's 5% read rate and Opus's $20 output rate are the two moving parts.
400K in, 10K out
Opus $1.80, Sol $1.75. Above 272K input Sol's whole request is repriced and the tie with Kimi disappears.
The column that moves Opus
In the cached loop, output is $4.00 of Opus's $7.98. Cache reads are the same $1.58 as Kimi.
03 — Context CliffWhere Sol's price doubles #
OpenAI's Sol page states the rule in one line: prompts with more than 272K input tokens are priced at twice the input and cache rates and one and a half times the output rate for the full request. The words "full request" are the part to underline. This is not a marginal rate on the tokens above the line. It is a repricing of every token in the call once the line is crossed.
A worked pair shows the step. A request with 272,000 input tokens and 10,000 output tokens costs 0.272 × $2 plus 0.01 × $10, which is $0.544 plus $0.10, or $0.644. Add one thousand input tokens and the same request costs 0.273 × $4 plus 0.01 × $15, which is $1.092 plus $0.15, or $1.242. One extra thousand tokens nearly doubles the bill. The same two requests on Kimi cost $0.644 and $0.646; on Opus $1.288 and $1.292.
Anthropic's pricing page says the opposite for its current lineup: Claude 4.6 and later models, apart from Haiku 5.5, include the full one-million-token window at standard pricing, so a 900K request is billed at the same per-token rate as a 9K one. Moonshot's page says all K3 series models share a 1,048,576-token window and prints one rate per column with no threshold. For long-context work the two flat models are predictable and Sol is predictable only if you measure your prompts.
The example that catches teams is a retrieval-heavy agent that keeps appending tool results. Turn forty of a Sol session might carry 260K tokens of accumulated context and cost $0.52 of input; turn forty-one, after a large file read, carries 280K and the input alone costs $1.12 at the doubled rate. Nothing in the response tells you which side of the line you were on except the usage object and your invoice. A ceiling on accumulated context at, say, 250K, with compaction before the next turn, keeps Sol on its headline rate.
04 — CachingHow each cache is written and read #
The cached-loop arithmetic above depends on three different caching designs behaving the same way, which they do not. Kimi's pricing page says the API automatically enables context-cache billing for repeated request prefixes with a default five-minute lifetime, and the quickstart explains that the cache is stored in blocks, with a partial block billed as a miss. The default is automatic, but request structure still affects which blocks can be reused.
Anthropic's prompt caching guide offers two modes. A single top-level cache field makes the system place the breakpoint at the last cacheable block and move it forward as the conversation grows; explicit breakpoints on individual content blocks give finer control. The minimum cacheable prompt on Opus 5.5 is 512 tokens. Reads refresh the lifetime at no charge, and the one-hour tier costs double the input rate to write. The failure case is a developer who never adds the field: nothing is cached, and the loop pays $4 per million for every prefix token on every turn.
OpenAI's guide describes implicit and explicit modes too. In implicit mode OpenAI places a breakpoint at the end of the latest eligible message; in explicit mode you mark up to four breakpoints yourself, and content after the last one is processed at the uncached rate with no write charge. The minimum cacheable length is 1,024 tokens for GPT-5.6 and later. The guide also notes that a changed reasoning effort can alter the model-side instructions and so the prefix, which is a trap for teams that step effort up mid-session; on GPT-6 models it recommends a configuration update input item instead, which keeps the cached prefix.
| Caching mechanics as documented by each lab, read October 26, 2026. Lifetimes are minimums; providers may keep entries longer. | |||
|---|---|---|---|
| Mechanic | Kimi K3.1 Pro | Claude Opus 5.5 | GPT-6.1 Sol |
| --- | --- | --- | --- |
| How it switches on | Automatic on repeated prefixes | Top-level cache field (automatic) or per-block breakpoints | Implicit breakpoint, or explicit mode with up to four |
| Lifetimes | 5 min default · 1 h option | 5 min default · 1 h option | 30 min default · 12 h option |
| Minimum cacheable | Block-based; partial block is a miss | 512 tokens | 1,024 tokens |
| Read rate vs input | 10% | 5% | 5% |
05 — Effort ControlsThinking you cannot switch off #
All three models reason before they answer, and on all three the reasoning is billed as output. What differs is the control you are given. Moonshot's quickstart says thinking is always on for K3.1 Pro, steered by a reasoning effort of low, high or max, with max as the default. Anthropic's Opus 5.5 overview says adaptive thinking is always on and cannot be turned off, steered by an effort parameter whose default is medium. OpenAI's Sol page lists low, medium, high, xhigh and max, with medium the default, and states that none and minimal are not supported.
The example that bites is a classification or extraction job moved from an older model that allowed thinking to be disabled. Every request now spends reasoning tokens at the output rate, and the only lever is to pick the lowest effort each API offers. On Kimi that is low; on Opus and Sol it is low as well, but the default is medium rather than max, so a Kimi integration that never sets effort pays for the deepest setting by default while the other two pay for the middle one.
Sampling is the other difference. Kimi fixes temperature at 1.0 and top-p at 0.95 and asks you to omit them. Anthropic's Opus 5.5 migration guide goes further: temperature, top-p and top-k must be omitted, and the API rejects them with a 400 error. OpenAI's Sol model page does not address sampling parameters. A team porting prompts that depend on a low temperature should expect to steer with prompting instead on Kimi and Opus, and test Sol before assuming behaviour carries over.
- Kimi K3.1 Proreasoning_effort
- low · high · maxdefault max; thinking always on; sampling fixed
- Claude Opus 5.5effort parameter
- adaptive, default mediumthinking cannot be disabled; forced tool use returns an error
- GPT-6.1 Solreasoning.effort
- low · medium · high · xhigh · maxdefault medium; none and minimal rejected
- Tool calling routewhere tools work
- Kimi chat API · Claude Messages · Sol Responses onlySol's Chat Completions endpoint has no tool calling
- Image inputhow images arrive
- all threeKimi takes base64 or an uploaded file, not a public URL; Kimi also reads video
06 — Access TermsAccess terms and limits that change the choice #
Price assumes you can get the model, keep it, and run it where your data is allowed to go. The three labs answer those questions differently. Moonshot's quickstart says K3.1 Pro is a flagship model unlocked after a top-up of at least one dollar, with the rate-limit tier set by cumulative top-up, and the launch post says API customers get zero data retention. The weights are promised by November 4, 2026 and were not published when we checked on October 26, so self-hosting is a future option, not a present one.
Anthropic's models overview lists Opus 5.5 on the Claude API, Amazon Bedrock, Google Cloud (both Google-managed and Anthropic-managed) and Microsoft Foundry, with a retirement commitment of not sooner than September 22, 2027. A fast mode at $8 in and $40 out is available for teams that need lower latency. OpenAI's Sol page says the model supports US and EU data residency, that regional processing adds a 10% premium, and that fast mode is double and ultrafast six times the standard rate.
The failure case is a procurement team that prices Kimi and Sol as equals and then discovers that one of them cannot be deployed inside the cloud account its security policy requires. Anthropic's models page lists Opus 5.5 on AWS, Google Cloud and Microsoft Foundry. Sol's OpenAI page lists only regional residency on OpenAI's own platform, but Microsoft lists GPT-6.1 Sol as generally available in Microsoft Foundry. Kimi is a direct platform account until the weights ship and a licence is published.
Direct platform, weights pending
Unlock by $1 top-up; tier by cumulative top-up. Thinking always on. Weights due by Nov 4, 2026; licence and hardware unknown until then.
Every major cloud, dated retirement
Retirement not sooner than Sept 22, 2027. Batch 50% off. Fast mode $8/$40. Highest cache write and output rates of the three.
Cheap reads, a repricing line
5% cache reads, 30-minute default lifetime. Above 272K input the whole request costs 2× in and 1.5× out. Batch and Flex 50% lower.
07 — BenchmarksWhy there is no winner #
We looked for one table, from any of the three labs, that scores all three models on one benchmark under one harness. There is not one on the pages we read. Moonshot's K3.1 Pro launch post compares its model with Claude Opus 5.5 and GPT-6 Astra on Terminal-Bench 4.0, with the K3.1 Pro run made through the Claude Code harness and the comparators taken as the higher of blog and leaderboard figures. GPT-6.1 Sol is not in that table. OpenAI's Sol page does not print a score at all; it says Sol delivers near-Astra performance at a lower cost and asks you to compare it with Astra on your own tasks.
That leaves two honest statements. Moonshot's own run puts K3.1 Pro within a point of Opus 5.5 on one terminal benchmark, in Moonshot's own run through the Claude Code harness, against a comparator figure Moonshot took as the higher of blog or leaderboard. OpenAI's own description positions Sol just below its flagship. Neither statement ranks the three, and stitching them together through Astra would compare a vendor-run score against a vendor's prose. We covered the Opus 5.5 launch numbers in our Opus 5.5 pricing and benchmarks guide and Sol's in the GPT-6.1 Sol upgrade guide; both carry the harness notes that a comparison table drops.
The failure case is familiar. A team picks the model with the highest number on a vendor chart, ships it, and finds that its own tool set, its own repository and its own prompts produce a different ordering. A twenty-task eval drawn from your real queue, run through the API door you will actually use, can provide evidence the vendor charts cannot. Estimate its cost from the token budgets, then compare success rates and the cost of accepted results.
08 — RoutingWhich one to route where #
Separate the three questions and the decision gets easier. Cost is arithmetic on your token mix, and the sums above show which shape favours which model. Context is a ceiling question: Kimi and Opus are flat to a million tokens, Sol is flat to 272K and then expensive. Quality still needs evaluation on your tasks; the cited sources do not establish an ordering across all three. The router below is our reading of the documentation, not a test result, and it should be overridden by your own evals the moment you have them.
One more cost line sits outside all of this: the cost of switching. All three APIs differ in how thinking blocks, tool results and caches are expressed, so a harness tuned for one of them does not move for free. Our earlier three-way comparison of Muse Spark, Kimi K3 and GLM 5.3 made the same point about open models, and the maintained frontier model API price index tracks the rates as they change. If you want help building the eval and the router rather than the spreadsheet, that is the kind of work our AI transformation engagements cover.
Our reading Treat the $2/$10 tie between Kimi K3.1 Pro and GPT-6.1 Sol as a starting point, not a finding. Sol is cheaper in our cached-loop example; Kimi is cheaper in our uncached long-document example. Opus has double the standard input and output rates, while its cache reads cost the same as Kimi's. It is the only one of these three listed on AWS and Google Cloud as well as Microsoft Foundry, where Sol is also sold. Pick by the shape of your traffic, confirm with your own eval, and re-run the sums when any of the three pages changes.
09 — ConclusionThe headline rate is the least useful number on the page #
Price your own token mix on all three, cap Sol below 272K, and let a twenty-task eval decide quality.
Three first-party price lists, read on the same day, give three different answers depending on what you send. On uncached short turns Kimi and Sol tie at $0.06 in our example and Opus is $0.12. On a hundred-turn cached loop Sol's 5% read rate lands it at $3.99 against Kimi's $4.74 and Opus's $7.98, and the gap to Opus is mostly its $20 output rate. On a 400K-token document Kimi's flat rate gives $0.90 while Sol's repricing above 272K lifts it to $1.75, within a few cents of Opus.
Behind the rates sit three caching designs, three effort controls that none of the labs lets you switch off, and three access models: a $1 top-up on a direct platform with weights still pending, a model on several named cloud platforms with a dated retirement commitment, and a model with regional residency and a context line that costs money rather than throwing an error.
None of the three labs publishes a table that scores all three models on one harness, and we will not invent one. Measure the token mix you actually send, run the arithmetic above with your own numbers, and let a small eval from your own queue decide which model earns the traffic. Then check the Kimi repository on November 4.