Two rows in the catalogue of new LLM models carry the same model name and different prices, and the difference between them is not a weight change. One is the model. The other is the same model served faster, sold as its own line item at roughly twice the rate. It is the cleanest example this month of a pricing idea that has been arriving quietly across several vendors at once, and it is routinely flattened into “the new, more expensive version” by anyone reading a release calendar. On OrcaRouter the GLM-5.3 entry for the base model exposes the price you actually pay, and setting it beside the accelerated tier’s rate is what makes the distinction easy to see and easy to get wrong.
What the accelerated tier is
The base model and its accelerated sibling run the same weights. The vendor’s own documentation for the base tier describes the model, and the accelerated entry appears as a separately named SKU with its own rate rather than as a setting on the original. Nothing about the model changed; what changed is how it is served.
That is a real product. Inference speed on a fixed model is a function of batching strategy, speculative decoding, hardware allocation and how aggressively the provider is willing to trade throughput for latency or vice versa. A vendor that has built a faster serving configuration can charge for it, and charging a premium for a faster tier is the oldest idea in cloud computing.
What makes it confusing here is the naming. A word like “Prime” attached to a model reads as a generation bump — the implication is more parameters, newer weights, better scores. In this case the implication is wrong, and the only place the truth is visible is the price and the vendor’s own framing of the tier as an acceleration.
The four prices on one page
The base model’s per-token rate is $1.40 input and $4.40 output, and that figure agrees across the vendor’s own product data and the independent index we checked on 28 September 2026. The accelerated entry is listed at $2.80 and $8.80 — exactly double on both sides.
There is a wrinkle worth stating because it is the kind of thing that makes a price table untrustworthy rather than merely inconvenient: our own model page carries $1.26 and $3.96 in its summary description while its structured product data and its FAQ answer both say $1.40 and $4.40. One of those is wrong and the two have coexisted on the same page, which is a defect on our side rather than a third opinion about the vendor. The figure to plan against is $1.40 and $4.40, because that is what the vendor publishes and what the independent index records.
The point of mentioning it is not to litigate our own page. It is that this is what per-token pricing looks like in September 2026: the same model can carry four different numbers depending on which field of which page you read, and the only defence is to name the source every time you write one down.
Why a 2x premium can still be the cheap option
Paying double per token for the same model sounds like a bad trade until you look at what the tokens are for.
If the workload is a long agent loop with many sequential steps, the wall-clock time of the whole task is the sum of the per-step latencies, and a faster serving tier compresses every step. The per-token premium is then buying back the thing that actually constrains the product — how long the user waits, or how many concurrent sessions a fixed pool of workers can hold. In that frame the expensive tier is not a markup on the same goods; it is a different good.
If the workload is a batch job that runs overnight, the trade inverts. There is no latency to buy back, the premium is pure cost, and the accelerated tier is only worth it if the same hardware budget produces more completed work in the window — which is possible but is a throughput question the per-token price does not answer.
The decision rule is one question: does anything you ship wait on this call? If yes, price the tier against your latency budget. If no, price it against the base model and take the base model.
The version of this that is not the same thing
In the same fortnight, another vendor shipped two names that look identical in shape and mean something completely different: two reasoning modes of one model, sold at the same base rate, where the “Pro” name selects a reasoning configuration rather than a serving configuration. Same price, different behaviour. Here, the accelerated name selects a serving configuration and carries a different price. Same weights, different bill.
Both are worth having. Neither is a new model. And no competitor page we read on 28 September 2026 separates them — the two patterns get filed under “new variants” and the reader is left to guess whether the premium buys capability or speed. It buys speed here, and capability there, and the price column is the only field that distinguishes them at a glance.
What to do with the base model’s headline score
The independent index we checked records 44.78 for the base model, in a configuration labelled `max` — meaning the highest reasoning setting, not the default. The accelerated entry does not have its own separate score on that page, which is consistent with it being the same weights: there is nothing new to measure.
Two habits follow. First, never quote the number without the configuration, because a `max`-setting result and a default-setting result on the same model are different products and the difference is often larger than the gap between adjacent models. Second, do not treat an accelerated SKU’s absence from a score table as an unknown score. For a serving tier, the score is the base model’s score by construction, and the published premium is the only new information.
The general rule this release is an instance of
Across this batch, three vendors have now shipped a faster configuration of an existing model as a separately priced product. The pattern is consistent enough to write down as a rule: when two rows in a catalogue share a model name, read the price before the name, and read the vendor’s description of the tier before either. A doubling is almost always serving, and a matching price is almost always behaviour.
The corollary is about your own cost model. If your architecture assumes one price per model name, it will silently under-count the moment anyone on the team enables a faster tier — because the tier is not a parameter you set, it is a row you select. Naming the row explicitly in your config, rather than deriving it from the model name, is the difference between a cost report that is right and one that is quietly wrong by a factor of two.
Sourcing note: The base model’s rates of $1.40 per million input tokens and $4.40 per million output tokens are from the vendor’s published product data and from a third-party public model directory read on 28 September 2026, and the two agree. The accelerated entry’s listing date of 23 September 2026 and its listed rates of $2.80 and $8.80 were read from that directory on the same date. The observation that our own model page carries $1.26 and $3.96 in its summary description while its structured product data and FAQ state $1.40 and $4.40 is our own finding on 28 September 2026 and is recorded here as an inconsistency on our side, not as vendor information. The independent index figure of 44.78, in a configuration labelled max, is that index’s number for the base model, not for the accelerated tier. The statement that the accelerated tier serves the same weights is the vendor’s own framing of the tier. The latency-versus-batch decision rule and the caching and concurrency arguments are editorial framing rather than measured results. This article names no competing platform and describes none.
