The most consequential line in this fortnight’s latest AI model releases is not a benchmark. It is a second price for a model that already existed. On 23 September 2026 a third-party directory added an accelerated tier of an existing flagship, priced at exactly double the base model’s rate, with the same weights underneath. Speed has been sold as a premium before — reserved capacity, provisioned throughput, priority queues — but it has always been sold as an arrangement around the model. Now it is sold as a model-shaped row with its own name and its own number, and that changes what a price list is for. On OrcaRouter the Qwen3.8 Max page is where the base model’s row lands, one enclosure away from the tier’s rate, which is the only place the pattern becomes obvious.
Two numbers, one model
The base model is listed at $2 per million input tokens and $6 per million output. The accelerated tier, listed on 23 September 2026, is $4 and $12.
That doubling is not a coincidence and it is not a rounding artefact — it is the same ratio the other accelerated tiers in this batch use, which suggests the pricing is being set by convention rather than by a measured improvement in cost of goods. When several independent vendors land on the same multiple within the same month, the number is a market convention: it is what the market has decided a faster response is worth, expressed as a multiple of the slower one.
The weights are the same. There is no new generation, no capability claim, no new context window. The 1,000,000-token context and the text, image and video inputs are properties of the base model, and the accelerated tier inherits them unchanged. The one new thing is how the tokens are produced.
What the buyer is actually purchasing
Three distinct things get bundled under the word “speed”, and only one of them is what a per-token premium can pay for.
The first is latency: how long a single call takes. This is invisible in a price list, because a price list measures quantity, not time. If your application shows a user a result, latency is the product, and a tier that halves it is worth a great deal at any per-token price, because it changes whether the feature is usable rather than what it costs.
The second is throughput: how many calls one deployment completes per unit of time. If your constraint is a worker pool or a rate limit, a faster tier raises the ceiling without you buying more capacity, and that is a genuine saving on infrastructure that never appears in the per-token comparison.
The third is consistency. A tier sold as accelerated is usually not just faster on average — it is less variable, because the reduced queueing removes the tail. Tail latency is what breaks timeouts, and timeouts are what generate retries, and retries are what turn a cost estimate into a surprise.
A per-token premium can only be justified by the second and third; the first is justified by whether you have users waiting. That is the whole evaluation.
The base model’s own latency, in our production
We serve the base version, and our model page records a p50 time-to-first-token of 3,345 ms for it, alongside the same $2 / $6 rate the third-party directory lists. That figure is our own production telemetry, measured across real traffic on our infrastructure, and it moves over time — it is not a vendor benchmark and it is not a guarantee.
What it gives you is a denominator. If a call currently starts producing output after roughly three and a half seconds at the median, and the accelerated tier halves that, you can price the improvement against your own patience budget instead of against an abstract percentage. If your interface already shows a spinner and a partial result, three seconds may be entirely acceptable and the premium buys nothing you can perceive.
The score belongs to the base model
The independent index we checked on 28 September 2026 records 45.42 for the base model under a configuration labelled `0902`, referring to the base release rather than the accelerated tier. There is no separate row for the accelerated tier, which is exactly what you would expect of two names for one set of weights: there is nothing new to measure.
The habit worth building is to read the configuration label before the number, every time. A score is a property of a model plus a reasoning setting plus sometimes a serving configuration, and a leaderboard column that shows only the first of those is telling you less than it appears to. In this batch alone, several quoted scores turn out to have been produced under non-default settings, which means comparing two models by their headline scores can be comparing two different configurations rather than two different models.
Why this is a durable change rather than a pricing stunt
It is tempting to read an accelerated tier as a temporary premium — a launch-week upcharge that will disappear. The economics point the other way.
Serving a model faster costs the provider real money. Latency comes from wasted capacity: batches that are not full, hardware held in reserve for a spike, speculative decoding that spends compute to save time. A provider that gives you lower latency is running your request less efficiently on purpose, and that inefficiency has a price. Charging for it is not an upcharge on the same goods; it is the correct price for a more expensive way of producing them.
Which means the right way to think about the next year of model pricing is not “prices go down” but “prices differentiate”. The same weights will be available at several rates, and the rate you choose encodes how much you care about the user’s wait. A cost model that assumes one price per model name will be wrong in a way that is invisible until someone flips a tier.
The practical action is small and worth doing now: name the tier explicitly in your configuration rather than deriving it from the model name, and record which tier each production route uses. Once a single model can be billed at two rates, “we use this model” stops being a complete description of your cost.
Sourcing note: The accelerated tier’s listing date of 23 September 2026 and its third-party listed rates of $4 per million input tokens and $12 per million output tokens were read from a third-party public model directory on 28 September 2026 and are that directory’s figures; the base model’s rates of $2 and $6 per million tokens are from the same directory and agree with OrcaRouter’s own model page. The base model’s p50 time-to-first-token of 3,345 ms and its 1,000,000-token context with text, image and video input are from OrcaRouter’s own model page read on 28 September 2026 and are our production telemetry, which moves over time. The independent index figure of 45.42, in a configuration labelled 0902, is that index’s number for the base model and not for the accelerated tier. The claim that the accelerated tier serves the same weights is the vendor’s framing of the tier. The observation that qwen.ai served one 94,344-byte document for the blog index path and the individual post path, that the vendor’s blog index has since moved to /research, and that the index page carries no mention of the accelerated tier, is our own check on 28 September 2026. The latency, throughput and tail-consistency argument and the statement that differentiation rather than decline is the likely price path are editorial framing, not measured results. This article names no competing platform and describes none.
