How to read tokens and a price table
Model pricing is charged by token, not by character or by request. A token is a fragment the text is split into for processing. Kimi's documentation puts a typical English token at roughly three to four characters. Korean and other non-Latin scripts split more finely, so the same meaning costs more tokens than its English equivalent.
A price table states the cost per million tokens, usually in three columns. Input is what you push in — prompt plus attached documents. Output is what the model writes back. Cache hit is the discounted rate for resending a prefix identical to one sent before. The more your workload repeats the same instructions and the same codebase, as agents do, the larger the cache-hit share becomes.
One point trips people up. The listed rate is a price per million tokens, not the price of a call. Your bill is always rate times quantity, and this piece is about what happens on the quantity side.
How far apart are the official rates?
As of 26 July 2026, the vendors' own documentation lists the following. All three carry roughly a million tokens of context, so the size of work they can hold is comparable.
On rates alone the order is unambiguous. Fable 5 sits at 3.3x Kimi K3, and what is exact there is that input and output carry the same multiple. Against Sol the gap is narrower and uneven: 2x on input but 1.7x on output. The column worth staring at is cache hit. All three are set to exactly 10% of their own input price. Caching therefore lowers all three together and gives none of them a relative advantage — which matters, because caching is the first thing most people reach for when cost is the question.
| Model | Input (1M) | Cache hit (1M) | Output (1M) | Context |
|---|---|---|---|---|
| Claude Fable 5 | $10 | $1 | $50 | 1M tokens |
| GPT-5.6 Sol | $5 | $0.50 | $30 | ~1.05M tokens |
| Kimi K3 | $3 | $0.30 | $15 | 1,048,576 tokens |
Why the same text becomes a different number of tokens
A tokenizer is the rule that splits text into tokens. Change the rule and the same sentence yields a different count. Anthropic's pricing documentation states that Claude 4.7 and later models, along with Mythos Preview, use a newer tokenizer that produces approximately 30% more tokens for the same text, described as a trade made for better performance.
Be precise about what that 30% compares against. It is measured against Anthropic's own previous tokenizer; no official figure compares token counts across vendors. So the number cannot be multiplied into a cross-vendor cost comparison.
The practical conclusion still holds. The multiple you read off a price table is a floor on the spending gap, not a ceiling. Since the same document can bill as different quantities on different models, the only real comparison is to run the same job on each and read the usage each console reports. All three vendors return token counts with the response, so this is easy to check.
There is a length band where the rate itself changes
OpenAI applies a length surcharge to Sol. Once input passes 272,000 tokens, the entire request is billed at 2x input and 1.5x output — an effective $10 and $45 per million. Crucially, this is not applied only to the excess but to the whole request.
That band is easier to reach than it sounds: refactoring against a whole repository, or dropping in a bundle of long transcripts and contracts. The Fable 5 and Kimi K3 tables, by contrast, carry no length tiers. Anthropic states that the full 1M context bills at standard rates, and the Kimi K3 table lists a single row against a 1,048,576-token context.
So the ranking moves with the shape of the work. On many short requests, the table order holds. On agent work that pushes hundreds of thousands of tokens at once, Sol's effective rate climbs toward Fable 5.
Getting it right the first time — retries multiply the rate
One review gave all three models the same prompt exactly once and compared what came back. Human intervention would stop measuring the model, so a single prompt was the control. Three tasks were set under identical conditions: a city traffic simulator, an agent UI, and a browser fighting game.
The results diverged. On the traffic simulator, Fable produced physics for vehicles crossing an intersection along with signal behaviour, while Sol drew cars as plain boxes with no collision handling, so they stacked on top of each other. Kimi sat between them: better road rendering than Sol, similar overlap problems. On the agent UI, Fable came first and Kimi second, while Sol attached connector lines to the wrong points. The reviewer's read on Sol was that it lacked the loop of checking its own completeness and going back to fix it.
This is where quality rejoins cost. If the result is not right the first time you run it again, and input and output are billed again. Running the same job once more doubles a cheap model's effective rate. A 3.3x gap only flips after roughly three extra attempts, so the cheap side still wins across a wide band — but the saving you computed off the table does not arrive intact.
One more note: the same reviewer found that the same model produced visibly different quality depending on the execution tooling it was run through. That is a reason to audit your current setup before swapping models.
So how do you choose?
Start by finding which item your work runs into. Does a single request approach 272,000 tokens of input? Do you resend the same instructions often enough for cache to dominate? Do you use the first result, or revise it two or three times? Once those three are answered, the choice falls out of arithmetic.
A worked example. One uncached job of 200,000 input and 20,000 output tokens costs Fable 5 $2 plus $1, so $3; Sol $1 plus $0.60, so $1.60; Kimi K3 $0.60 plus $0.30, so $0.90. So far the table's 3.3x holds exactly. Push input to 300,000 and only Sol crosses into its surcharge band, landing at $3 plus $0.90, or $3.90. Fable 5 costs $4.00 on the same job, so the difference all but disappears. Sol's 1.9x advantage at 200,000 tokens shrinks to 1.03x, while its gap to Kimi K3 — $1.20 for the same work — widens from 1.8x to 3.3x. The ranking does not flip, but the saving you computed off the table evaporates in this band.
On a subscription there is one more test. If your current model leaves headroom, there is no reason to switch. If your limit runs dry and you wait hours each time, filling those gaps with a cheaper model pays. Either way the evidence is your own usage history, not a price table.
Organisations should add one more factor. How often work has to be redone depends not only on the model but on how precisely the instruction was given and whether anything verifies the result. Halving retries on the same model has the same effect as cutting the rate by two thirds — usually cheaper and faster than changing models.