Almost every AI coding assistant pricing comparison published this year is a list of sticker prices. That is the least useful number on the page. What a developer actually pays depends on how the plan meters work, whether the vendor bills tokens or requests, how much of the allowance a real coding session consumes, and — for one vendor in particular — whether the tokens being counted are even the same size as everyone else’s.
This page reconstructs the pricing from primary sources as of 24 July 2026, then does the arithmetic that nobody else on this search results page has done: what a month of real work costs on each option, and exactly where a flat subscription stops being cheaper than paying per token.
What this page covers
What changed since 1 June 2026
Two changes make most of the pricing articles currently ranking for this query wrong rather than merely dated.
GitHub Copilot no longer bills “premium requests.” On 1 June 2026 GitHub moved Copilot to token-metered GitHub AI Credits, and now describes the old system as legacy on its own request-based billing (legacy) page. One AI credit equals $0.01. Any article still telling you that Copilot Pro includes “300 premium requests” and charges “$0.04 per additional request” is describing a system GitHub retired almost two months ago — and at least two articles currently in the top ten still do, because GitHub’s old premium-requests URL still resolves and still shows the old numbers.
OpenAI shipped GPT-5.6 on 9 July 2026 in three variants (Sol, Terra, Luna). Its pricing matters here because Sol’s published API rate — $5.00 input, $0.50 cached input, $30.00 output per million tokens — resets the ceiling for frontier-tier metered coding.
One thing we flagged here as a coming change has now been settled the other way. Anthropic’s $2/$10 per million token rate for Claude Sonnet 5 was announced at launch as introductory pricing through 31 August 2026, and Anthropic’s pricing documentation now states that $2/$10 is the standard price and that the scheduled increase to $3/$15 on 1 September 2026 will not occur. If you are modelling a budget past the end of August, use $2/$10, not the higher pair. See the update at the end of this page for what that does to the tables above.
Quick verdict: cheapest option by situation
| Situation | Cheapest defensible answer | Monthly |
|---|---|---|
| You mostly want autocomplete, occasional agent | GitHub Copilot Pro | $10 |
| Frontier-quality agent, light use (under ~1 task/day) | Pay per token via API, no subscription | $10–30 |
| Frontier-quality agent, full-time use | Claude Max 5x or Codex Pro | $100 |
| Maximum agent throughput, single developer | Claude Max 20x / Cursor Ultra | $200 |
| Good-enough agent, heavy use, cost is the constraint | Z.ai GLM Coding Plan Lite (runs inside Claude Code) | $18 |
| Batch or overnight work, quality tolerance | DeepSeek-V4-Flash API | under $1 |
| Team of five, predictable invoice | Copilot Business at $19/seat | $95 |
Every one of those numbers is defended below, and the workload assumption behind “light” and “full-time” is stated explicitly rather than hidden.
The unit problem: why most per-token tables on this page are not comparable
Before any pricing table means anything, one correction has to be applied, and as far as we can tell only one other article in the current top ten mentions it at all.
Anthropic’s own pricing documentation notes that Claude 4.7 and later tokenise the same text into roughly 30% more tokens than earlier versions. Anthropic bills per token. So when a comparison table puts Claude Opus 5 at $5 per million input tokens next to GPT-5.6 Sol at $5 per million input tokens and concludes “same price,” it is comparing two different units — like quoting one fuel price per litre and the other per gallon and calling it a tie.
The correction is straightforward: for the same actual work, multiply Claude’s token counts by about 1.3 before comparing. That turns a headline parity into a roughly 30% real premium on the input side. It does not make Claude a bad choice — it changes the crossover point at which its subscription beats its API, which is the number this article is actually built around.
We apply that 1.3 multiplier to every Claude figure in the cost model below and label it where it appears. No other vendor in this comparison has published a comparable tokenisation caveat, so no other row is adjusted.
AI coding assistant pricing compared: the official subscription tiers
OpenAI Codex
| Tier | Price | What the price buys |
|---|---|---|
| Free | $0 | Exploration of quick tasks; included credit amount not published |
| Go | $8/mo | Lightweight coding tasks |
| Plus | $20/mo | Web, CLI, IDE extension, iOS; GPT-5.5, 5.4, 5.3-Codex, 5.4-mini |
| Pro | From $100/mo | 5x or 20x the Plus rate limits; includes GPT-5.3-Codex-Spark |
| Business (standard seat) | $25/seat/mo, or $20/seat billed annually | Codex baseline access |
| Business (Codex-only seat) | No seat fee; pay-as-you-go per token | OpenAI’s wording: “no rate limits” |
| Enterprise / Edu | Contact sales — not published | Priority processing, SCIM/EKM/RBAC, audit logs, data residency |
Note the Pro row. A great many comparison articles state “Codex Pro = $200/month.” OpenAI’s own developer pricing page says “From $100/month” and does not publish a price for the 20x tier separately. The $200 figure appears to originate in secondary blogs. We are quoting what OpenAI publishes.
Codex expresses included usage as ranges of messages per rolling five-hour window rather than as a credit allowance. On Plus that is 15–80 GPT-5.5 messages; on Pro 5x, 80–400; on Pro 20x, 300–1,600. The width of those ranges is itself informative: OpenAI is telling you that consumption per message varies by roughly 5x depending on what you ask.
OpenAI’s own published estimate for a working developer is $100–200 per developer per month.
Anthropic Claude / Claude Code
| Tier | Price | Claude Code included? |
|---|---|---|
| Free | $0 | No |
| Pro | $20/mo, or $17/mo billed annually ($200 prepaid) | Yes — positioned for “short coding sprints on small codebases” |
| Max 5x | $100/mo | Yes — “daily use on larger codebases” |
| Max 20x | $200/mo | Yes |
| Team Standard | $20/seat/mo annual, $25 monthly | Yes |
| Team Premium | $100/seat/mo annual, $125 monthly | Yes |
| Enterprise | Seat fee plus API-rate usage; annual only, sales contact | Yes |
Two structural details that change the maths. First, Claude Code and the Claude web app draw from the same allowance pool — using one reduces the other. Second, all models share that pool, so switching with /model does not restore capacity. Anthropic doubled the Claude Code five-hour limits for Pro, Max, Team and Enterprise in 2026 and removed peak-hour throttling for Pro and Max.
What Anthropic does not publish, and what nobody should be quoting: the absolute weekly limit in tokens, messages or hours for any tier. Every “Pro gets you X hours of Sonnet per week” figure circulating online is a third-party estimate. We treat it as unpublished.
Anthropic does publish something more useful: measured enterprise cost of around $13 per developer per active day, or $150–250 per developer per month, with 90% of users under $30 on any given active day.
GitHub Copilot (post-1 June 2026 AI Credits model)
| Plan | Monthly | Included AI credits | Dollar value of allowance | Overage |
|---|---|---|---|---|
| Free | $0 | Not published; 2,000 completions/mo, auto model only | — | — |
| Pro | $10/user | 1,000 base + 500 flex = 1,500 | $15 | $0.01/credit, budget-gated |
| Pro+ | $39/user | 3,900 + 3,100 = 7,000 | $70 | $0.01/credit |
| Max | $100/user | 10,000 + 10,000 = 20,000 | $200 | $0.01/credit |
| Business | $19/granted seat | 1,900/user | $19 | $0.01/credit or hard block |
| Enterprise | $39/granted seat | 3,900/user (GHEC only) | $39 | $0.01/credit or hard block |
Copilot meters per token at published per-model rates — GPT-5.5 at $5.00/$30.00 per million, Claude Opus 5 at $5.00/$25.00, GPT-5 mini at $0.25/$2.00 — with cached input discounted 90%. Critically, code completions and next-edit suggestions are not billed at all and are unlimited on paid plans. Only agent and chat work consumes credits. GitHub Copilot CLI is included with every plan and does draw on credits.
One caveat worth flagging because it quietly changed a lot of bills: GitHub’s Business and Enterprise credit allowances were promotionally inflated from 1 June to 1 September 2026 — 3,000 credits per seat on Business and 7,000 on Enterprise, for existing customers only. That promotion ended on 1 September 2026. The 1,900 and 3,900 figures in the table above are the standard allowances and are what applies now.
Cursor
| Plan | Monthly | Included usage | Metering |
|---|---|---|---|
| Hobby | $0 | “Limited agent requests” — not published | — |
| Pro | $20/user | $20 of API-priced usage, plus a bonus Auto/Composer pool | Pass-through at model API rates |
| Pro Plus | $60/user | $70 | Pass-through |
| Ultra | $200/user | $400 | Pass-through |
| Teams Standard | $40/user | Not published in dollars | Pass-through |
| Teams Premium | $120/user | “5x Standard limits on Agent” | Pass-through |
Cursor’s model is the most legible of the four: you buy a dollar allowance of usage priced at the underlying model’s API rate. Tab completions are unlimited on paid plans. Above the allowance, Cursor continues at pay-as-you-go and states that “requests are never downgraded in quality or speed.”
Neither GitHub nor Cursor publishes annual pricing for any tier. Both are listed here as monthly only, because that is what the vendors publish.
The flat-rate coding plans nobody else is covering
This is the largest hole in the current search results. Of the nine articles ranking for AI coding assistant pricing that we examined, zero cover the Chinese labs’ flat-rate coding subscriptions — despite the fact that one of them costs $18 a month and runs inside Claude Code.
| Vendor | Plan | Price | What you get |
|---|---|---|---|
| Z.ai (GLM) | Coding Plan Lite / Pro / Max | $18 / $72 / $160 | ~80 / ~400 / ~1,600 prompts per 5-hour window; covers GLM-5.2, GLM-5-Turbo, GLM-4.7; works with Claude Code, Cline and OpenCode |
| Alibaba Model Studio | Coding Plan Pro | $50 | 6,000 requests per 5h, 45,000/week, 90,000/month; covers qwen3.7-plus, qwen3-coder-next, qwen3-coder-plus, plus third-party Kimi, GLM and MiniMax models |
| MiniMax | Token Plan Plus / Max / Ultra | $20 / $50 / $120 | Rolling 5-hour plus weekly windows; all platform models; overflow via prepaid credits |
| Moonshot (Kimi) | Moderato / Allegretto / Allegro / Vivace | $19 / $39 / $99 / $199 | Kimi Code usage included at no extra charge; annual billing drops the entry tier to about $15/mo |
| DeepSeek | — | No subscription published | Pay-as-you-go only; the Deep Code CLI bills against your API key |
The Z.ai entry deserves emphasis. A $18/month plan that a developer drives through the Claude Code interface they already know is a direct substitute for a $20 Claude Pro subscription, and a partial substitute for a $100 Max 5x plan. Whether the model quality is acceptable is a separate question — our comparison of the coding models themselves goes through what each vendor has actually published on benchmarks, and why cross-vendor benchmark tables are less trustworthy than they look. But at the level of pricing, no honest cost comparison in 2026 can omit an $18 option that plugs into the incumbent’s own client.
What you will actually pay per month
Sticker prices tell you the floor. This section models the real number.
The workload unit. We define one feature-sized agentic task as a session that bills 250,000 input tokens (80% of them cache reads, which is typical once a session has warmed up) and produces 25,000 output tokens. This is our assumption, not a vendor figure, and we state it plainly so you can substitute your own. Everything below is arithmetic on top of it.
Cost per feature-sized task, at published API rates
| Model | Cost per task | 20 tasks/mo | 60 tasks/mo |
|---|---|---|---|
| Claude Opus 5 (raw rates) | $0.98 | $19.50 | $58.50 |
| Claude Opus 5 (tokeniser-corrected, +30%) | $1.27 | $25.35 | $76.05 |
| GPT-5.6 Sol | $1.10 | $22.00 | $66.00 |
| Claude Sonnet 5, promo rate, corrected | $0.51 | $10.14 | $30.42 |
| Claude Sonnet 5, from 1 Sept, corrected | $0.76 | $15.21 | $45.63 |
| Qwen3-Coder-Plus (≤128K tier, no published cache discount) | $0.68 | $13.50 | $40.50 |
| Claude Haiku 4.5, corrected | $0.25 | $5.07 | $15.21 |
| GLM-5.2 | $0.23 | $4.64 | $13.92 |
| MiniMax-M3 | $0.057 | $1.14 | $3.42 |
| DeepSeek-V4-Pro (status changed 14 Sep 2026 — see update below) | $0.044 | $0.88 | $2.65 |
| DeepSeek-V4-Flash (retired 10 Sep 2026 — see update below) | $0.015 | $0.29 | $0.87 |
AI coding assistant pricing, expressed as cost per unit of work rather than per subscription tier. Log scale — each gridline is a 10x step.
Kimi K2.6 and K3 are excluded from this table because Moonshot publishes their API rates in RMB only (K2.6 at ¥6.50 input / ¥1.10 cached / ¥27 output per million; K3 at ¥20 / ¥2 / ¥100). Converting them into this table would require picking an exchange rate and presenting it as a vendor price, which it is not. On Moonshot’s own RMB rates, K2.6 works out to about ¥1.22 per task.
The spread is the finding: the same defined task costs about 85x more on tokeniser-corrected Claude Opus 5 than on DeepSeek-V4-Flash. Not 85% more — 85 times.
A reality check on our own model
Run 60 tasks a month on tokeniser-corrected Opus 5 and the model says $76. Anthropic’s measured figure for real enterprise developers is $150–250 a month, and OpenAI’s for Codex is $100–200. Our model lands at roughly a third to a half of what both vendors report from production usage.
We are not going to reconcile that by inflating our assumptions until they match. The honest reading is that a clean per-task model is a floor, not a forecast. Real sessions include retried tasks, abandoned branches, exploratory questions that never become commits, cache misses after idle periods, and — on tools that support them — parallel subagents. Anthropic notes that agent-team runs consume roughly seven times the tokens of a standard session. Use our table for relative comparison between models, which is what it is reliable for, and use the vendors’ own $100–250 range for budgeting headcount.
Where subscriptions stop being cheaper than the API
This is the calculation the rest of the search results discuss qualitatively and never actually perform. Using the per-task costs above, here is how many tasks per month you must run before a flat plan beats metered billing.
| Flat plan | Breaks even at | Per working day (21 days) |
|---|---|---|
| Claude Pro, $20 | 16 tasks/mo | 0.8 |
| Codex Plus, $20 | 18 tasks/mo | 0.9 |
| Copilot Business, $19/seat | 17 tasks/mo | 0.8 |
| Cursor Pro, $20 | 18 tasks/mo | 0.9 |
| Alibaba Coding Plan Pro, $50 | 74 tasks/mo | 3.5 |
| Z.ai GLM Coding Plan Lite, $18 | 78 tasks/mo | 3.7 |
| Claude Max 5x, $100 | 79 tasks/mo | 3.8 |
| Codex Pro, from $100 | 91 tasks/mo | 4.3 |
| Claude Max 20x, $200 | 158 tasks/mo | 7.5 |
| MiniMax Token Plan Plus, $20 | 351 tasks/mo | 16.7 |
Three conclusions fall out of this table that we have not seen stated anywhere else.
The $20 tier is almost always correct. Fewer than one substantial agentic task per working day and the API is cheaper; more than that and the subscription wins. Almost every professional developer who has adopted these tools at all clears one task per day, which is why the $20 tier is the right default and why arguing about it is a waste of time.
The $100 tier is a genuine decision. It breaks even at roughly four feature-sized tasks per working day. That is a real workload — an engineer using an agent as their primary interface hits it; an engineer using it as an occasional assistant does not. This is the one number worth measuring your own usage against before you commit.
Cheap models make their own flat plans hard to justify. GLM’s $18 plan needs 78 tasks a month to beat GLM’s own API, and MiniMax’s $20 plan needs 351, because the underlying metered rates are so low. If you are buying a Chinese lab’s flat plan, you are buying rate-limit headroom and predictability, not savings. That is a legitimate purchase — it is just not the purchase the pricing page implies.
The Copilot and Cursor allowances, expressed the same way
Because both meter in dollars, their allowances convert directly. At GPT-5.6 Sol rates, Copilot Pro’s 1,500 credits buy about 14 tasks a month, Pro+ about 64, and Max about 182. Cursor Pro’s $20 buys about 18, Pro Plus about 64, and Ultra about 364.
Comparing what you pay to what you receive gives an effective multiplier: Copilot Pro returns $1.50 of metered usage per dollar, Pro+ $1.79, Max $2.00; Cursor Pro returns $1.00, Pro Plus $1.17, Ultra $2.00. Copilot Business and Enterprise return exactly $1.00 — you are paying for governance, seat management and unlimited completions, not for discounted inference. Copilot Max and Cursor Ultra are the only two plans in this comparison that hand back two dollars of metered usage for every dollar of subscription, which is a straightforward reason to prefer them at high volume over stacking cheaper seats.
The stack nobody is modelling
Every article on this query prices tools one at a time. Developers do not use them one at a time. Two combinations worth costing:
The $28 stack. Copilot Pro at $10 for unlimited completions, next-edit suggestions and 1,500 credits of agent work, plus the Z.ai GLM Coding Plan Lite at $18 for roughly 80 prompts per five-hour window driven through Claude Code. Total $28/month, versus $100 for Claude Max 5x. You give up frontier model quality on the agent side and you take on a second vendor relationship. You keep the editor experience and gain considerably more agent headroom than $28 buys anywhere else.
The $40 dual-frontier stack. Codex Plus at $20 plus Claude Pro at $20. This is the configuration most experienced practitioners report using, because the two agents fail differently — and running the one that is not stuck is worth more than optimising which single subscription to hold. Our head-to-head on Codex vs Claude Code covers how the two behave in practice, including where each one’s failure modes show up.
At $40, the combined breakeven is about 34 tasks a month, or 1.6 per working day. If you clear that — and a full-time user does — running both is cheaper than the API for either.
What happens when you run out
Exhaustion behaviour differs more than pricing does, and it is where a cheap plan turns expensive.
Cursor continues at pay-as-you-go and bills in arrears, explicitly promising no quality or speed downgrade. Predictable behaviour, unpredictable invoice.
Copilot on individual plans continues against a budget you set, so overage is capped by your own configuration. On Business and Enterprise, the administrator chooses between overage billing and a hard block. Predictable invoice, potentially interrupted work.
Claude subscribers can enable extra usage billed at standard API rates, with a top-up ceiling of $2,000 per day. One side effect worth knowing: prompt cache lifetime drops from one hour to five minutes once you are drawing on overflow credits, which makes long sessions meaningfully more expensive at exactly the moment you are already over budget.
If your answer to running out is to run somewhere else, that is a separate calculation. We compared twelve Claude Code alternatives and worked out the break-even point for each, which is the number that decides whether switching actually saves you anything.
Codex Business offers a Codex-only seat with no seat fee and pure pay-as-you-go billing, which OpenAI describes as having no rate limits. For teams with a few very heavy users and many light ones, mixing seat types is likely cheaper than upgrading everyone.
MiniMax and Alibaba overflow into prepaid credit balances. Codex credits expire twelve months after purchase, which is the only hard expiry we found in this comparison and is easy to miss when buying in bulk.
Who should choose what
Solo developer, occasional agent use. Copilot Pro at $10. Unlimited completions are the feature you use hourly; 1,500 credits cover the agent work you do weekly. Nothing else in this comparison delivers both under $20.
Solo developer, agent is the primary interface. Claude Max 5x or Codex Pro, both $100. The breakeven arithmetic supports it at roughly four substantial tasks per working day, and both are below the vendors’ own measured $100–250 range for full-time users.
Cost-constrained but high-volume. Z.ai GLM Coding Plan Lite at $18, driven through Claude Code. If the model quality holds for your codebase, it is the highest ratio of agent headroom to dollars available anywhere in this table.
Batch, overnight, or high-tolerance work. DeepSeek-V4-Flash at roughly 1.5 cents per feature-sized task, or Claude’s Batch API at half of standard rates. For work where latency does not matter and a human reviews the output anyway, paying frontier rates is difficult to justify.
Team of five to twenty. Copilot Business at $19 per seat. The credit allowance was promotionally inflated for existing customers until 1 September 2026 and is now back to the standard 1,900. It returns exactly its cost in metered usage, so you are paying for governance and completions — which for a team is the right thing to be paying for.
Enterprise. Anthropic’s published $150–250 per developer per month and OpenAI’s $100–200 are the planning figures. Both are higher than any single subscription tier, which tells you that at organisational scale the seat price is not the cost driver — consumption is.
What we could not verify
Stating this is the point. Every figure above comes from a vendor’s own documentation. These do not exist in any official source we could find, and we would rather leave a hole than fill it with a secondary blog’s guess:
- Annual pricing for every GitHub Copilot tier and every Cursor tier.
- Copilot Free’s included credit allowance.
- Cursor Hobby’s included usage, and Cursor Teams and Enterprise allowances expressed in dollars.
- Per-model credit multipliers under Copilot’s AI Credits system.
- The specific monthly price of Codex Pro’s 20x tier (OpenAI publishes only “From $100”).
- Included credit quantities for any Codex tier, and Codex’s general credit-to-dollar rate. The $0.04 per credit figure we see quoted derives from a single student-offer sentence (“2,500 credits, which is equivalent to $100”) and is not a general pricing statement.
- Absolute weekly usage limits for any Claude tier, in any unit.
- USD pricing for Kimi K2.6 and K3, and for Qwen3-Coder-Next.
- Any subscription plan from DeepSeek.
Two further caveats on the numbers we did verify. Alibaba’s English-language site presents mainland Chinese prices as USD conversions of the RMB list, so quoting both regions as dollars double-counts. And a striking share of the prices above are explicitly promotional — Qwen3.7-Max’s “limited-time 50% off,” MiniMax’s “permanent 50% off,” Sonnet 5’s advertised expiry on 31 August, Copilot’s inflated summer credits. Two of those have since resolved in opposite directions: Anthropic made the Sonnet 5 rate permanent, while GitHub let the Copilot credit promotion lapse on schedule. The stable list price of AI coding assistance in 2026 is, in several cases, simply not on sale yet.
Read next
- Claude Code vs Cursor: what each plan actually buys
- Claude Code vs GitHub Copilot: credits, limits and real cost
- Is Claude Code free? The short answer and the real cost
Frequently asked questions
How much do AI coding tools actually cost per developer per month?
The vendors’ own measured figures converge: Anthropic documents $150–250 per developer per month from real enterprise usage, and OpenAI estimates $100–200 for Codex. Both are well above the headline $20 tier, which is an entry point rather than a full-time working price. Our own per-task model produces roughly $76/month for 60 feature-sized tasks on Claude Opus 5, which we read as a floor — real usage includes retries, exploration and abandoned work that a clean model omits.
What is the cheapest paid AI coding assistant?
GitHub Copilot Pro at $10/month is the cheapest plan from a major vendor, and it includes unlimited completions plus $15 worth of metered agent credits. If you are optimising purely for agent volume rather than editor integration, Z.ai’s GLM Coding Plan Lite at $18/month buys roughly 80 prompts per five-hour window and runs inside Claude Code. On raw API rates, DeepSeek-V4-Flash is cheaper than everything else by an order of magnitude.
Is a $100 subscription worth it compared to paying per token?
It breaks even at about four feature-sized agentic tasks per working day — 79 tasks a month for Claude Max 5x, 91 for Codex Pro at its published “From $100” price. Below that, the API is cheaper. Above it, the subscription is. This is the one threshold worth measuring your actual usage against; the $20 tier’s breakeven of roughly one task per day is cleared by nearly everyone and needs no analysis.
Does GitHub Copilot still charge per premium request?
No. GitHub moved Copilot to token-metered AI Credits on 1 June 2026 and now labels the request-based system as legacy. One credit is $0.01. Copilot Pro includes 1,500 credits, Pro+ 7,000, Max 20,000, Business 1,900 per seat and Enterprise 3,900 per seat. Completions and next-edit suggestions are not billed at all on paid plans.
Why does Claude’s API look the same price as OpenAI’s but cost more?
Because Anthropic bills per token and Claude 4.7 and later tokenise the same text into roughly 30% more tokens. Identical headline rates therefore mean roughly a 30% higher real cost for identical work. Every per-million-token comparison table that does not apply this correction is comparing different units.
What happens when I hit my usage limit?
It depends on the vendor, and the differences are larger than the price differences. Cursor continues at pay-as-you-go with no stated quality or speed reduction. Copilot individuals continue against a self-set budget; Copilot organisations choose between overage billing and a hard block. Claude subscribers can enable overflow at standard API rates up to $2,000/day, but prompt cache lifetime drops from one hour to five minutes once overflow is active. Codex Business offers a no-seat-fee, pure pay-as-you-go seat type.
Should I subscribe to one tool or two?
Two $20 subscriptions — typically Codex Plus plus Claude Pro — break even at about 34 tasks a month, or 1.6 per working day, which a full-time user clears comfortably. The practical argument is not cost but failure diversity: the two agents get stuck on different things, and having the other one available is worth more than optimising which single one to hold.
Are the Chinese labs’ coding plans a real alternative?
At the level of pricing, unambiguously yes: Z.ai at $18, MiniMax at $20, Kimi at $19 and Alibaba at $50 are all real, published, flat-rate plans, and the Z.ai plan runs through the Claude Code client. Whether the model quality is sufficient is a separate question that depends on your codebase, and one that published benchmark scores answer less clearly than they appear to — we walk through why in our comparison of the underlying models.
All pricing verified against vendor documentation on 24 July 2026. AI pricing changes fast and several rates above are explicitly promotional; Two promotions carried on that date have since resolved: Anthropic’s Sonnet 5 introductory $2/$10 rate became the standard price rather than expiring on 31 August 2026, and GitHub’s inflated Business and Enterprise credit allowances lapsed on 1 September 2026 as scheduled. Where a vendor has not published a figure, this page says so rather than estimating.
Related: Claude Max vs ChatGPT Pro: what 5x and 20x actually mean — the usage ceilings behind these prices, quoted from each vendor.
Update, 30 August 2026: Z.ai has restructured the GLM Coding Plan
The GLM Coding Plan figures earlier on this page describe the plan as it was documented earlier in 2026 — prompt counts per five-hour window, covering GLM-5.2, GLM-5-Turbo and GLM-4.7. Z.ai has since replaced that structure entirely. Read from docs.z.ai on 30 August 2026:
- The unit is now credits, not prompts. Lite gets 2,000 credits per five-hour window and 10,000 per week; Pro gets 12,000 and 60,000; Max gets 28,000 and 140,000.
- Credit usage = (input tokens x input multiplier + cached input tokens x cached multiplier + output tokens x output multiplier) / 10,000. For GLM-5.3 the multipliers are 6.9 / 1.7 / 24; for GLM-5.3-Flash they are 2.3 / 0.56 / 8.
- Only GLM-5.3 and GLM-5.3-Flash are servable on the plan. Requests for GLM-5.2 and GLM-5.1 are automatically routed to GLM-5.3; GLM-4.7 requests are routed to GLM-5.3-Flash.
- There is a time-of-day discount. Off-peak usage is charged at 50% of the standard credit rate. Z.ai defines peak hours as Monday to Friday, 14:00–18:00 Singapore time (UTC+8) — which, by our arithmetic, is 02:00–06:00 US Eastern, so North American developers are off-peak almost all of the time.
- Five-hour credits refresh dynamically (five hours after consumption) rather than on a fixed clock; weekly credits reset every seven days from the moment you subscribed.
Z.ai’s documentation still says only “starting at 18 USD per month” and does not publish the Pro and Max monthly prices on any page we could read, so treat the $72 / $160 figures above as unverified until you see them on your own subscription page. We have worked the new credit arithmetic through against a concrete weekly workload, and priced the same week on the Anthropic API and on Anthropic’s flat plans, in GLM Coding Plan vs Claude Code: what each actually costs.
One more change on the Anthropic side of this page’s tables: Anthropic’s pricing documentation now states that the $2/$10 per million token pricing for Claude Sonnet 5, originally introductory pricing through 31 August 2026, is the standard price, and that the scheduled increase to $3/$15 on 1 September 2026 will not occur.
Update, 31 August 2026: the Sonnet 5 increase is cancelled, and it changes the arithmetic on this page
Every table on this page that involves Claude Sonnet 5 was built while $2/$10 per million input/output tokens was described as introductory pricing that ran out today. Anthropic’s pricing documentation now states that $2/$10 is the standard price for Sonnet 5 and that the previously scheduled increase to $3/$15 on 1 September 2026 will not occur. Nothing about the number changed; what changed is that it stopped having an expiry date attached to it.
That matters more for planning than for today’s invoice. Anyone who built a September-onward budget at $3/$15 — which is what this page told you to do until today — overstated Sonnet 5 token cost by 50% on input and 50% on output (our arithmetic on Anthropic’s official list prices: $3 against an actual $2, $15 against an actual $10). On a workload heavy enough to matter, that is the difference between provisioning for one seat and provisioning for one and a half.
The line that moves most is the one nobody quotes. Prompt cache reads are billed at 0.1x the base input rate, so Sonnet 5 cache hits stay at $0.20 per million tokens rather than rising to $0.30. On an agentic coding workload where most of the context is re-read from cache on every turn, cache reads — not fresh input — are the dominant input line, so cancelling the increase takes roughly a third off the input side of a cache-heavy bill (our arithmetic; $0.20 against the $0.30 that would have applied).
The caveat that applies to every cross-vendor row in this article
Per-token list prices are not directly comparable across vendors, and Anthropic says so itself. Anthropic’s pricing documentation notes that Claude 4.7 and later models use a newer tokenizer that produces approximately 30% more tokens for the same text, with the exact increase depending on content and workload shape; Claude Sonnet 4.6 and earlier use the previous tokenizer. A model priced 20% lower per token but tokenising 30% more of the same source file is not cheaper. We have not found a published cross-vendor tokenisation benchmark that would let us convert list prices into a like-for-like figure, so we are not going to invent one — but treat every per-million-token comparison on this page, and on any other page that compares vendors this way, as an upper bound on precision rather than a settled number.
For the same cache-line reasoning applied to a single head-to-head matchup, see our breakdown of the GLM coding plan against Claude Code, where the cached-input row reverses the answer most comparisons give. For what the API rates mean if you are trying to avoid a subscription entirely, see whether Claude Code is free.
Official list prices, read 31 August 2026.
Update, 1 September 2026: GitHub’s Copilot credit promotion has lapsed
The promotional included usage that GitHub granted existing Copilot Business and Copilot Enterprise customers ran from 1 June to 1 September 2026 and has now ended. Per GitHub’s usage-based billing documentation, the promotional amounts were 3,000 AI credits per user per month on Business and 7,000 on Enterprise; the standard amounts, in force from today, are 1,900 and 3,900 respectively. Those are the numbers already shown in the comparison table above, so the table needs no correction — but the caveat attached to it has changed from a forecast to a fact.
Two details matter for anyone budgeting from this page. First, GitHub fixes the conversion at 1 AI credit = $0.01 USD, and overage is billed at that same rate, so the included allowance converts cleanly to dollars: Business drops from $30 to $19 of included usage per seat, Enterprise from $70 to $39 — falls of $11 and $31 per seat per month, or roughly 37% and 44% (our arithmetic on GitHub’s official credit counts and conversion rate). Second, credits pool at the billing entity and reset at 00:00:00 UTC on the first of each calendar month with no carry-over, so the reduction took effect in a single step rather than tapering.
A separate GitHub billing change follows on 1 October 2026: per its 28 August changelog, existing Business and Enterprise customers paying by credit card or PayPal will see assigned seats incur an upfront charge at the start of the billing cycle. GitHub states that Copilot Business and Enterprise prices are not changing. Treat the two as distinct events when you model a rollout.
We have worked through the per-seat and per-hundred-seat consequences, and the reason a Copilot seat now returns exactly its own price in metered usage, in the corresponding update to our Claude Code versus GitHub Copilot comparison. The short version for this page: the seat economics are unchanged for teams that stayed inside the standard allowance, and only teams that had built on the summer headroom will see a new overage line. As always, and as the metered-versus-subscription breakdown sets out at greater length, the decision turns on your actual draw rather than on the headline allowance.
Verified 1 September 2026 against GitHub Docs (“Usage-based billing for organizations and enterprises” and “About billing for GitHub Copilot in organizations and enterprises”) and the GitHub Changelog of 28 August 2026. Credit counts, seat prices and the $0.01 conversion are GitHub’s published figures; the dollar deltas and percentages are our arithmetic on them.
Update, 4 September 2026: what the $18 line in our table actually buys
The cheapest credible entry in the table at the top of this page is Z.ai’s GLM Coding Plan Lite at $18 a month. Two things about that number have changed underneath it, and both are the kind of change that never makes it into a price comparison because the headline figure stayed the same.
First, the plan behind the price was replaced. Z.ai’s Plan Update Announcement, published 30 July 2026, states that the GLM Coding Plan moved to a credits-based system and that the previous plans “are no longer sold to new users.” Subscriptions bought before that date were grandfathered as Legacy Plan V1, V2 or Team. The familiar allowance figures — around 80 prompts per five hours on Lite, 400 a week — now appear on that page under a heading Z.ai labels “Usage Reference for Legacy Plans.” A new subscriber gets 2,000 credits per five hours and 10,000 per week instead, and Z.ai publishes no conversion between prompts and credits.
Second, a credit is not a fixed amount of money. The official multipliers for GLM-5.3 are 6.9 for input, 1.7 for cached input and 24 for output, divided by 10,000. Set those against Z.ai’s own API list prices of $1.40, $0.26 and $4.40 per million tokens and a credit redeems for $0.00203, $0.00153 and $0.00183 respectively depending on what you spend it on (our arithmetic). Any comparison that converts credits to dollars at one rate — including, until today, ours — is assuming a linearity the multipliers do not have.
The practical consequence is uncomfortable for the cheap option: the plan discounts cached tokens by about 4.1x against fresh ones, where Z.ai’s own API discounts them by about 5.4x and Anthropic’s API discounts them by a stated 10x. Cache reads are the dominant line item in agent coding work, so the subscription is least generous exactly where the work lives. We work the whole calculation through, and check it against Z.ai’s published token-allowance table, in GLM Coding Plan vs Claude Code: what each actually costs.
The $18 recommendation in our table stands. What does not stand is the idea that you can compare it to a Claude or Codex subscription by dividing dollars by tokens. Note also the standing caveat on every cross-vendor row here: Anthropic states that Claude 4.7 and later models use a tokenizer producing approximately 30% more tokens for the same text, so per-token prices across vendors are not directly comparable. Prices read from docs.z.ai and platform.claude.com on 4 September 2026.
Update, 6 September 2026: the cheapest row on this page doubles in price on 10 September
A dated warning for anyone using the cost-per-task table above to pick a budget model. Z.ai’s pricing page states that the 50% launch discount on GLM-5.3-Flash “ends at 24:00 on September 9, 2026 (UTC+8, Singapore time)”. Its rates have since returned to list — input from $0.075 to $0.15, cached input from $0.015 to $0.03, and output from $0.25 to $0.50 per million tokens. Every one of those doubles. (The reversion did not happen on the date Z.ai published for it — see the 13 September 2026 update at the foot of this page.) Any per-task figure you compute for Flash this week is half of what the same task will cost next week.
Two things this does not affect, both re-read on the official pages today. GLM-5.3 and GLM-5.2 are unchanged at $1.4 input, $0.26 cached input and $4.4 output. And the GLM Coding Plan subscription is billed in credits through a separate multiplier table, not from these per-token prices, so the $18-a-month line in our table above does not move on 10 September — at least, the documentation does not say it does, and the two tables live on different pages with no cross-reference between them.
Running underneath the price promotion is a second, separate offer that most coverage has merged with the first: a Flash usage campaign for paying GLM Coding Plan subscribers, which Z.ai’s notice dates as 3 to 20 September 2026 and which applies daily from 23:00 to 09:00 Singapore time. In that window, Flash through ZCode consumes no quota at all, and through other supported agents the plan’s quota is doubled. Two Flash deadlines, eleven days apart, doing different things to different customers.
We have worked through what both deadlines mean for subscription buyers — including the finding that Flash undercuts GLM-5.3 by roughly nine to one on the API but by exactly three to one inside the Coding Plan — in the 6 September update to our GLM Coding Plan versus Claude Code comparison.
Update, 13 September 2026: the GLM-5.3-Flash discount has been withdrawn, four days after the date the vendor published
Re-reading Z.ai’s pricing documentation on 13 September 2026, the GLM-5.3-Flash row now shows plain list prices with no strikethrough and no expiry tip: $0.15 input, $0.03 cached input, $0.50 output per million tokens. The 50% launch discount is gone, exactly as the paragraph above anticipated, and every Flash figure in the per-task table on this page should be read as half of what the same task now costs.
The timing is worth recording, because we got it wrong by relying on the vendor. Z.ai’s own tip said the promotion ended at 24:00 on 9 September 2026 (UTC+8), so we told readers the rise would land on 10 September. When we re-read the page on 10 September the discount was still live, with the lapsed tip still sitting underneath it. Our next clean read was 13 September, by which point it had gone. The accurate statement is that the price changed between 11 and 13 September 2026; Z.ai has published no withdrawal date and we are not going to assign one.
If you maintain a cost model, the transferable point is that a published promotion end date is a statement of intent, not a billing event. The billing event is the moment the price table changes, and the two can be days apart in either direction. The only reliable way to date it is to read the table.
Two details that limit the blast radius. First, the withdrawal is confined to GLM-5.3-Flash — GLM-5.3, GLM-5.2 and GLM-5.1 remain at $1.40 / $0.26 / $4.40, and the rest of the Z.ai table is unchanged. Second, the discount had been applied uniformly across input, cached input and output, so removing it doubled the level of a Flash bill without altering its internal proportions at all: the output-to-input ratio is 3.33 before and after, and the cached-input share is 20.0% before and after (our arithmetic on Z.ai’s published figures). Any conclusion you drew from the shape of Flash pricing still holds; only the absolute dollars need redoing. We work through what that means for the Claude Code comparison, including the cache-heavy blend where Anthropic quietly comes out ahead of GLM-5.3, in our GLM Coding Plan versus Claude Code breakdown.
Update, 15 September 2026: the same Qwen model costs 21% more in Singapore than in Frankfurt — and its default cache is dearer than Anthropic’s
Alibaba’s model page for qwen3.8-max (self-dated “Last Updated: Sep 11, 2026”, read verbatim on 15 September 2026) publishes two price columns for one model. Not two models, not two context tiers — the same weights, priced differently depending on which region you call. We have not seen this written up anywhere, and it breaks the headline every roundup runs about Chinese models being several times cheaper.
| qwen3.8-max, USD per 1M tokens | Beijing / Frankfurt / Virginia / Tokyo / HK | Singapore (International) |
|---|---|---|
| Input | 1.65 | 2 |
| Output | 4.951 | 6 |
| Input (implicit cache hit) | 0.206 | 0.25 |
| Explicit cache creation | 2.063 | 2.5 |
| Explicit cache read | 0.137 | 0.17 |
Our arithmetic on those official numbers: Singapore is 21.2% more expensive than the other regions on both input and output. That is a larger gap than most of the model-versus-model price differences people spend afternoons arguing about.
Against Claude Sonnet 5, the answer depends on which region you deploy in
Anthropic’s published rate for Claude Sonnet 5 is $2 per million input tokens, $10 per million output tokens, and $0.20 per million tokens on a cache read (pricing page, read verbatim 15 September 2026 and unchanged across six consecutive daily readings). Set the two side by side:
- Non-Singapore regions. Our arithmetic: Qwen is 17.5% cheaper on input and 50.5% cheaper on output.
- Singapore. Our arithmetic: input is identical at $2, and output is 40% cheaper.
So “17.5% cheaper on input” and “the same price on input” are both true statements about the same two models on the same day. Which one applies to you is a deployment-region question, and no comparison table we have seen asks it.
The cache row is where the cheaper model quietly loses
Coding agents are cache-hit machines. They resend the same system prompt, the same repository context and the same tool definitions on every turn, which is why a mature agent workload can run well above 90% cached input. On that shape of traffic the cache row, not the headline input row, is the price you actually pay.
Qwen publishes two cache mechanisms with very different economics. Our arithmetic against Sonnet 5’s $0.20 cache read:
- Implicit cache — the one you get automatically, without changing your code — is $0.206 outside Singapore. That is 3% more than Anthropic charges. In Singapore it is $0.25, or 25% more.
- Explicit cache read — which requires you to create and manage cache entries, paying $2.063 per million tokens to create them — is $0.137, or 31.5% less than Anthropic.
Read that as a sentence rather than a table: the default configuration of the cheaper model is more expensive than the pricier model on the single line item that dominates agent workloads, and you only reach the discount by doing explicit cache management and amortising a creation charge that is 25% above the standard input price. Whether that pays back depends on how many reads you get per write — which is your architecture’s question to answer, not the price list’s.
This is the second time the cache row has overturned a headline comparison on this site. The first was the GLM Coding Plan comparison, where a model marketed as several times cheaper turned out to charge more per cached token than Sonnet 5. Two vendors, same pattern: the advertised discount lives on the rows that high-cache workloads barely touch.
The caveat that makes all of these percentages softer than they look
Anthropic’s own documentation states that Claude 4.7 and later changed tokenizer, and that the same text now produces approximately 30% more tokens. A per-million-token price is a price per unit of a thing that is not the same size across vendors. A 17.5% input advantage measured in dollars per million tokens is comfortably inside a 30% difference in how many tokens the same file becomes — and it points the other way, meaning the dollar comparison understates rather than overstates the gap. We are not going to multiply the two, because we have no vendor-published measurement of Qwen’s tokenizer on the same corpus, and inventing one would be worse than leaving the caveat open. The practical version: treat every cross-vendor per-token table on this page, ours included, as a starting hypothesis to be settled by running your own workload through both and reading the invoices.
Two smaller asymmetries worth knowing before you pick a region
Batch inference is not available everywhere. Beijing publishes batch file rates of $0.825 input and $2.475 output — half list, by our arithmetic. Singapore does not support batch inference at all, and the dated snapshot build qwen3.8-max-0902 supports it in no region. The region that charges 21% more is also the region with the fewest ways to pay less.
Throughput differs by build. The -0902 snapshot is capped at 150,000 TPM on the international endpoint. If you pin a snapshot for reproducibility — which is the responsible thing to do in production — you are also accepting a throughput ceiling that the rolling alias does not have.
One number we could not get: the current promotional price. The official page states plainly that it lists original pricing only and directs you to the Model Studio Console for promotions, and the Console requires an account login. So the honest answer is that Alibaba’s effective price is not published, and any site quoting a promotional Qwen rate is quoting something you cannot verify from the documentation. The context-window side of this model — one million tokens, with no long-context surcharge tier anywhere in the price table — is covered in our breakdown of what a million-token context actually costs.
Update, 16 September 2026: DeepSeek retired one of the models in the table above, and announced then un-announced the retirement of the other
The pricing table earlier in this article lists two DeepSeek entries, V4-Flash and V4-Pro. As of 04:00 UTC on 10 September 2026, one of them no longer exists as a model you can call, and the other was scheduled for removal and then reprieved in the vendor documentation on the same day. We are leaving the old rows in place above rather than silently deleting them, because the way this table went stale is more useful than the numbers in it, and because DeepSeek has not published replacement figures in a form we are willing to quote. Details below.
What actually changed
DeepSeek shipped V4.1-Flash on 10 September 2026 and repriced its API at 04:00 UTC the same day. Alongside the launch, the release notes state plainly that V4-Flash and V4-Flash-Vision-Exp are retired. For compatibility, requests using those two old model names are temporarily routed to V4.1-Flash. So the V4-Flash row in our table above is no longer a model you can select; it is an alias pointing at a different model with different pricing.
The flagship is messier. The release page announced that DeepSeek was phasing out V4-Pro, and said that starting at 04:00 UTC on 14 September 2026 every deepseek-v4-pro request would route to V4.1-Flash, billed at V4.1-Flash rates, until a V4.1-Pro launches. The change log published the same day says the opposite: “In response to user demand, we have decided to continue providing API services for DeepSeek V4 Pro after September 14, 2026, with the billing method remaining unchanged.” Both statements are official and both were live when we checked on 16 September 2026. We cannot determine from the documentation whether the 14 September routing was ever switched on, and we are not going to guess. We treat the change log as the operative, later word: V4-Pro is still billable at its own rates.
Why this section contains no new DeepSeek prices
DeepSeek says the new architecture is more efficient and the API prices are lower, and that the new pricing took effect at 04:00 UTC on 10 September 2026. It also says off-peak rates are 50% of peak rates, and recommends scheduling flexible workloads off-peak.
What it does not say, in text, is what any of those rates are. The V4.1-Flash price list is published as an image file, not as machine-readable or copyable text, and the peak and off-peak windows are not stated in the prose either. That leaves three options: transcribe a JPEG and present the result as an official figure, copy numbers from a third-party aggregator, or tell you the price is not publicly documented in text. We are taking the third option. A number we transcribed from a picture is not a citation, and the whole point of this page is that our figures come from vendor documentation you can open yourself. DeepSeek per-million-token pricing for V4.1-Flash: not published in text as of 16 September 2026.
The same caveat that governs every cross-vendor row in this article applies with extra force here. Anthropic has confirmed that Claude 4.7 and later use a different tokenizer that produces roughly 30% more tokens for the same text, which means per-token list prices are not directly comparable across vendors even when both are published. Adding an untranscribed, image-only price to that comparison would produce a number with two unknowns in it.
The part worth generalising: price tables for Chinese vendors decay by SKU, not by price
Every pricing comparison on the web, including this one, is built to track one kind of change: the number next to a model goes up or down. That is the failure mode people design for, and it is not what happened here. The V4-Flash price in our table above is still, as far as we know, the correct price for V4-Flash. The problem is that V4-Flash is gone. A row can be simultaneously accurate and useless, and no amount of re-checking prices will catch it, because you have to re-check the model list.
This has a practical consequence for anyone picking a model on cost. The cheapest row in a comparison table is disproportionately likely to be the volatile one: it is usually the newest small model, the one the vendor is iterating on fastest, and therefore the one most likely to be renamed, retired, or aliased inside a quarter. Two of DeepSeek’s model names were retired in a single announcement here. If you are pinning a model name in production config because it was cheapest in a table, you have taken on a supply risk that the table does not show you.
The reprieve makes the same point from the other direction. A vendor that publishes a flagship deprecation and reverses it in the same day’s change log, explicitly citing user demand, is telling you that its SKU list is negotiated with its largest customers rather than fixed by a roadmap. That is arguably good news if you are one of those customers. It is bad news if you are budgeting eighteen months out from a spreadsheet. Pin the model names you depend on, check them on a schedule, and treat the price column as the stable part.
For how a different Chinese vendor structures the same off-peak discount, and why the cache-hit line matters more than the headline rate, see our GLM Coding Plan versus Claude Code cost comparison. For the vendor-claimed benchmark numbers behind the V4-Pro decision, and what the architecture means for self-hosting, see our benchmark comparison of the leading coding models. For the long-context pricing thresholds that interact with all of this, see our guide to the Claude Code context window.
Update, 17 September 2026: Moonshot published its batch discount and its priority tier — and the two of them say more about how this market prices than either does alone
Three things appeared on Moonshot’s pricing documentation that we had not read before. Individually they are small. Read against the rest of the table on this page, they expose a gap between what these rate cards advertise and what a real bill is made of.
1. The batch discount — and why “cheaper” and “a deeper discount” are not the same claim
Moonshot states it directly: “Batch API inference costs are 60% of the standard model price, ideal for large-scale tasks with low real-time requirements.” Anthropic’s batch API is priced at 50% of standard. Put those next to each other carefully, because it is easy to get backwards:
| Vendor | Batch price as share of standard | Discount off standard (our arithmetic) |
|---|---|---|
| Anthropic (Claude) | 50% | 50% off |
| Moonshot (Kimi) | 60% | 40% off |
So Anthropic’s batch discount is the deeper one — 50% off against Moonshot’s 40% off — while Moonshot’s batch line remains far cheaper in absolute dollars, because its standard prices start much lower. Both statements are true at once, and they answer different questions:
- “Which vendor is cheaper for this workload?” is answered by the absolute price. Moonshot wins that one on this line, comfortably.
- “Is it worth re-engineering my pipeline to be asynchronous?” is answered by the discount depth, because that is what you are buying with the engineering time. Here Anthropic pays you more for the same restructuring work.
We flag this because the conflation runs in a predictable direction. “Chinese models are five times cheaper” is the sentence everyone writes, and it makes people assume every line of the rate card leans the same way. It does not. We found the same inversion on cache-hit pricing three weeks ago, where a Chinese vendor’s cache-hit line was the more expensive of the two despite much cheaper headline rates — the fuller version of that argument is on our GLM Coding Plan vs Claude Code comparison.
2. The discount does not cover the flagship — and that is a category of budgeting error nobody warns about
The same documentation states which models the batch endpoint accepts: “Batch API supports kimi-k2.7-code and kimi-k2.6 models.” Kimi K3, the vendor’s newest and largest model, is not on that list.
| Model | Standard (cache hit / miss / output, per 1M tokens) | Batch available? | Batch price |
|---|---|---|---|
kimi-k2.7-code | $0.19 / $0.95 / $4.00 | Yes | $0.114 / $0.57 / $2.40 |
kimi-k2.6 | — | Yes | $0.10 / $0.57 / $2.40 |
kimi-k3 | — | No | Not offered |
The pattern is worth naming because it generalises. Discount programmes lag model lineups. Batch endpoints, cache tiers and committed-use discounts get wired up to a model after it ships, and sometimes long after. Anyone who wrote “we will run the new flagship, and we will batch it to halve the cost” into a budget has costed a combination that does not currently exist — the new model is available, the discount is available, and the intersection is empty.
This is the same class of error we corrected on this page yesterday, where our own table listed a model the vendor had retired. There, the model had gone and the price stayed. Here, the model is present and the discount programme is absent. In both cases checking that the numbers are still right does not catch it, because the numbers are still right. You have to check that the thing the number describes still exists and is still purchasable in the configuration you assumed.
3. The new “highspeed” tier is priced at exactly 2×, and the vendor will not say what you get for it
A SKU we had not seen before appeared on the pricing page: kimi-k2.7-code-highspeed.
| Model | Input (cache hit) | Input (cache miss) | Output | Context |
|---|---|---|---|---|
kimi-k2.7-code | $0.19 | $0.95 | $4.00 | 262,144 |
kimi-k2.7-code-highspeed | $0.38 | $1.90 | $8.00 | 262,144 |
Two things are missing from the page, and we are not going to supply either from guesswork. There is no stated launch date for this SKU. And there is no stated definition of “highspeed” — no latency target, no throughput figure, no explanation of how it is triggered or what happens under load. You are asked to pay exactly double for a property the vendor does not quantify.
The round number is the interesting part. MiniMax prices its priority tier on the same structure — a flat 2× over the standard tier. When two vendors independently land on precisely 2.00×, across every line of the rate card, that number is not derived from the cost of serving the request. Serving costs do not come out round. It is a pricing convention: a tier priced by what the market will tolerate paying for “faster,” not by what faster costs to provide. That is not a scandal — most premium tiers in most industries work this way — but it does mean the 2× tells you nothing about how much faster it is, and you should treat the speed claim as unmeasured until you measure it on your own workload.
4. One more line that moved in the opposite direction from the headlines
MiniMax’s rate card carries both its current and its legacy models. The legacy tiers price cache reads at $0.03 per 1M tokens. From M2.7 onward the same line is $0.06. That is a doubling of the cache-read price (our arithmetic) across a generation in which the headline rates did not rise and a “permanent 50% off” banner stayed up.
Which direction your bill moved across that transition therefore depends on your cache hit rate, not on the headline. On an agent workload running 90%-plus cache hits — which is what a coding agent re-reading the same repository looks like — the cache-read line is most of the bill, and it doubled. Nobody’s comparison table has a column for it. Ours now discusses it in three places, which is three more than we managed before 30 August.
The usual caution applies to every cross-vendor figure above: tokenizers differ, so per-token prices are not directly comparable. Anthropic states that Claude 4.7 and later tokenize the same text into roughly 30% more tokens than earlier models. A rate-card comparison that ignores that is comparing two different units of measurement. For capability rather than billing, see our AI coding models compared; for the head-to-head most readers arrive here for, see Codex vs Claude Code.
Sources for this update: Moonshot pricing documentation at platform.kimi.ai/docs/pricing/chat and platform.kimi.ai/docs/pricing/batch, and MiniMax pay-as-you-go pricing at platform.minimax.io/docs/guides/pricing-paygo, all read 17 September 2026. Anthropic’s batch share read from platform.claude.com the same day. Every price above is a vendor list price; every ratio and discount figure is labelled as our arithmetic on those list prices. Where a launch date or a definition is not published, we have said so rather than estimating it.
Update, 18 September 2026: Google has already printed the date its Flash prices double, and it is sitting on the same page as today’s price
Every number on this page is one a vendor can change with a blog post. Google’s Gemini API pricing page currently does something different: it prints two prices in the same cell, and the date the second one takes over. We read the page on 18 September 2026, and the same sentence appears in six separate rows of the Flash table — standard input, standard output, cached input, cache storage, the Batch and Flex tiers, and the Priority tier:
$0.75 through December 31, 2026. $1.50 starting January 1, 2027.
That is not a rumour, a leak, or a third-party estimate. It is the vendor’s own list price for a date 105 days away, published on the page you would open to build next year’s budget. (105 days is our arithmetic, counting 18 September 2026 to 1 January 2027.)
What doubles, and by how much
Gemini 3.8, 3.7 and 3.6 Flash, per million tokens, as read from the official pricing page on 18 September 2026. Every tier moves by the same factor on the same day — there is no partial increase and no grandfathering language anywhere in the table.
| Tier | Through 31 Dec 2026 | From 1 Jan 2027 |
|---|---|---|
| Standard input | $0.75 | $1.50 |
| Standard output | $3.75 | $7.50 |
| Cached input | $0.075 | $0.15 |
| Cache storage (per 1M per hour) | $0.50 | $1.00 |
| Batch / Flex input | $0.375 | $0.75 |
| Batch / Flex output | $1.875 | $3.75 |
| Priority input | $1.35 | $2.70 |
| Priority output | $6.75 | $13.50 |
Against Sonnet 5, the advantage does not halve — it falls to 40% of its size
Anthropic’s Claude Sonnet 5 lists at $2.00 input, $10.00 output and $0.20 cache read per million tokens. Set the two vendors side by side and the discount is the same figure on all three rows, which is itself worth a moment.
| Row | Gemini Flash now | Gemini Flash from 1 Jan 2027 | Sonnet 5 | Cheaper by (our arithmetic) |
|---|---|---|---|---|
| Input | $0.75 | $1.50 | $2.00 | 62.5% now, 25% from January |
| Output | $3.75 | $7.50 | $10.00 | 62.5% now, 25% from January |
| Cache read | $0.075 | $0.15 | $0.20 | 62.5% now, 25% from January |
Be precise about what changes. The price exactly doubles. The discount does not halve — it falls from 62.5% to 25%, which is 40% of its former size. Those are different statements and only the second one is what you feel in a monthly bill.
Our arithmetic, on a round million. Take a workload of one million input tokens and one million output tokens. Today that costs $4.50 on Gemini Flash and $12.00 on Sonnet 5 — you save $7.50. From 1 January it costs $9.00 on Gemini Flash, and you save $3.00. The saving falls by 60%, even though the gap in headline prices is still real. If the switch to Flash was justified by a monthly saving, that saving is scheduled to shrink to two fifths of itself on a date you already know.
Why the discount is one number and not three
It is not a coincidence that input, output and cache all come out at exactly 62.5%. Google prices Flash output at exactly 5x its input and cached input at exactly 0.1x its input. Anthropic prices Sonnet 5 output at exactly 5x its input and cache read at exactly 0.1x its input. Two vendors who chose the same internal ratios will always produce a single comparison figure, and a single figure is exactly the kind of thing that ends up in a headline.
The interesting cases are the vendors whose ratios do not line up, because that is where the headline reverses. We found one earlier on this site: on cache reads, GLM-5.3 lists at $0.26 against Sonnet 5’s $0.20, so on a heavily cached agent workload the model everyone calls five times cheaper is the more expensive one on the row that carries most of the traffic. Google is not that case. But you only know which case you are in by reading every row, and the ratio test above is a fast way to find out: if the ratios match, one number is enough; if they do not, no single number is safe.
The same week, one vendor cancelled an increase and another published one
Anthropic’s pricing page still carries its own note that Sonnet 5’s previously scheduled increase to $3 / $15 will not occur. So within the same seven days of reading, we have one vendor withdrawing an announced increase and another committing to one with a date attached.
The useful conclusion is not that one vendor is honest and the other is not. It is that a scheduled price is a plan in both directions. Google’s January figure can be revised the way Anthropic revised its own. What a printed future price genuinely gives you is not certainty about January — it is the knowledge that the vendor has already decided the current price is below where it wants to be. That is a different and more durable signal than the number itself.
On this price page, the older model is the more expensive one
Gemini 3.5 Flash lists at $1.50 input and $9.00 output, with no promotional line and no future date. Against 3.8 Flash at today’s promotional price that is 100% more on input and 140% more on output (our arithmetic). The detail worth carrying forward is what happens on 1 January:
- Input converges to identical. 3.8 Flash goes to $1.50; 3.5 Flash is already $1.50. The newer model’s input advantage does not shrink, it disappears (our arithmetic).
- Output stays 20% apart. $9.00 against $7.50 (our arithmetic). The only remaining reason to pay more for the older model is that you have not migrated.
Teams routinely pin an older model to avoid a migration and treat that as the conservative, low-cost choice. On this vendor’s rate card it is neither: it is the choice that pays a premium today and an equal price in January. We have written about the reverse failure — a model that vanishes while its price row stays put — in our Codex versus Claude Code comparison, where a model scheduled for retirement is still sitting in the rate card. A pricing page tells you what a model costs. It is not a reliable statement about whether you should still be on it.
Two caveats we will not paper over
These per-token prices are not directly comparable across vendors. Anthropic states that Claude 4.7 and later changed tokenizer and that the same text now yields roughly 30% more tokens. A per-million-token quote is a price per unit, and the units are not the same size. Every cross-vendor table on this site carries that warning, this one included.
Google states its own prices may not be the prices you pay. The pricing page carries the line that prices may differ from those listed and from those offered on Gemini Enterprise Agent Platform. If you buy through an enterprise platform rather than the direct API, the table above is a reference point rather than your rate card — the same problem we hit with regional price differences elsewhere. Read the terms attached to your own contract.
Officially not published: the context window limits for 3.8, 3.7 and 3.6 Flash do not appear on the pricing page, and neither do their release dates. We are not filling those in from third-party figures. For the cliff that is published — the one on Gemini 3.1 Pro at 200k tokens, and why its output multiplier of 1.5x almost never helps a coding agent — see our breakdown in Claude Code’s context window and what long prompts actually cost. For where Google sits among the working alternatives rather than just on price, see Claude Code alternatives.
Update, 19 September 2026: xAI publishes four billing clauses that never appear in its price table, and one of them reverses grok-4.6’s advantage over Sonnet 5
Every comparison on this page, including ours until today, is built from the per-million-token table each vendor prints at the top of its pricing page. On 19 September 2026 we read xAI’s pricing page (docs.x.ai/developers/pricing, the page itself carrying “Last updated: September 14, 2026”) from top to bottom rather than lifting the headline rows, and found four further billing clauses sitting below that table. None of them changes a single number in the table. Between them they decide what you actually pay, and one of them inverts the conclusion the table alone would give you.
First, the list prices, so the rest has something to move
xAI’s flagship grok-4.6 has a 500k context window and lists at $2.00 input / $0.50 cached input / $6.00 output per million tokens. Anthropic’s Claude Sonnet 5 lists at $2.00 / $0.20 / $10.00. Both are vendor list prices read on 19 September 2026, not our estimates.
On 18 September we set ourselves a rule while comparing Gemini Flash to Sonnet 5: before you publish a single headline number, check whether the two vendors use the same internal ratios. If they do, one number is safe. If they do not, no single number is. Applying it here takes about ten seconds. Sonnet 5 prices output at exactly 5x its input and cached input at exactly 0.1x. grok-4.6 prices output at 3x and cached input at 0.25x. The ratios do not match, so there is no honest single-number version of “grok-4.6 versus Sonnet 5.” There are three lines and they point three different directions:
| Line | grok-4.6 | Sonnet 5 | Verdict |
|---|---|---|---|
| Input / 1M | $2.00 | $2.00 | Identical |
| Output / 1M | $6.00 | $10.00 | grok 40% cheaper (our arithmetic) |
| Cached input / 1M | $0.50 | $0.20 | grok 150% more expensive (our arithmetic) |
That third row is the one that matters for coding agents, because a coding agent re-sends a largely unchanged codebase on every turn and therefore spends most of its input budget at the cached rate. It is the same shape of finding we published on 30 August about GLM-5.3, and it keeps recurring for the same structural reason: the cached-input line is the line nobody compares, and it is the line agents live on.
Clause one: the batch discount, which excludes the flagship and reverses the comparison
xAI’s page lists a 20% batch discount and names exactly which models receive it: grok-4.3, grok-4.20-0309-reasoning, grok-4.20-0309-non-reasoning and grok-4.20-multi-agent-0309. It then closes the list with a sentence worth quoting in full, because it is the sentence that does the damage: “Models not listed above have no batch discount.”
grok-4.6 is not on that list. xAI’s flagship has no batch discount at all. Anthropic, by contrast, applies 50% to its entire line, Sonnet 5 included. Run the same workload through each vendor’s batch endpoint and the table above turns over completely:
| grok-4.6 batch | Sonnet 5 batch | Verdict | |
|---|---|---|---|
| Discount applied | None | 50% line-wide | — |
| Input / 1M | $2.00 | $1.00 | grok 100% more expensive (our arithmetic) |
| Output / 1M | $6.00 | $5.00 | grok 20% more expensive (our arithmetic) |
Read the two tables together. At standard rates grok-4.6 is level on input and 40% cheaper on output. At batch rates it is 100% more expensive on input and 20% more expensive on output. Nothing about the models changed; the only thing that changed is which endpoint you posted to. Any article that tells you which of these two is cheaper without telling you whether the work is batched is not answering the question it appears to be answering.
There is a second-order effect inside xAI’s own line that is easy to miss. The 20% discount lands only on models that were already the cheapest ones xAI sells. grok-4.3 lists at $1.25 / $0.20 / $2.50 with a 1M window; batched, that becomes $1.00 / $2.00 (our arithmetic). Against batched Sonnet 5 at $1.00 / $5.00, input is level and output is 60% cheaper (our arithmetic). So xAI does have a genuinely aggressive batch price — it simply is not on the model most people mean when they say “Grok”. The discount widens the gap inside xAI’s own line rather than narrowing the flagship’s gap to anyone else’s.
Clause two: priority processing at a 2x premium, with an unusually clean billing trigger
xAI states that “Priority requests are billed at a 2x premium over standard rates.” For grok-4.6 that is $4.00 input / $1.00 cached / $12.00 output per million (our arithmetic on the published list price). Note where that lands: priority grok-4.6 output at $12.00 is more expensive than standard Sonnet 5 output at $10.00 (our arithmetic). The 40% output advantage does not survive one tier of urgency.
The clause attached to it is the part we would like to see copied by every other vendor: “You are only billed at the priority rate when the response confirms "service_tier": "priority".” That is a verifiable billing trigger. You can reconcile the premium against a field in the response body instead of against a hope that the request was served the way you asked. Most speed tiers in this market ask you to pay for an intent; this one makes you pay for a confirmation.
Clause three: a $0.05 fee for a request that returns you nothing
xAI charges “a $0.05 usage guideline violation fee per request” when the Responses API blocks a request before generation. We have now read eight vendors’ pricing pages under this project and we have not seen an equivalent clause at any of the other seven.
The interesting thing is not the size of the fee, it is the shape. Every other line on every pricing page in this comparison is a function of tokens. This one is a function of requests that produced no tokens, which means it is invisible to the cost model you almost certainly built, because that model multiplies token counts by unit prices and a blocked request has a token count of zero. For scale: at grok-4.6’s $2.00 per million, one blocked request costs the same as 25,000 successfully processed input tokens, and a thousand of them costs $50 (our arithmetic). A content-moderation pipeline or a red-teaming harness — workloads that deliberately send borderline text — is exactly the kind of system that could accumulate this line item without a single token appearing in its usage dashboard.
What we are not claiming
Two stacking questions are officially not published: xAI states that the regional-endpoint premium is applied after the cache discount, but it does not state how the batch discount and the regional premium interact if you use both, and Anthropic does not publish a stacking order for its batch discount and its US inference geography either. We are not going to guess at either one. And the standing warning on this page applies with full force to every figure above: Anthropic states that Claude 4.7 and later use a different tokenizer that produces approximately 30% more tokens for the same text, so cross-vendor per-token prices are not directly comparable even when the units look identical. Every percentage in this section compares prices, not bills.
The long-context surcharge is the fourth clause, and it needs more room than this section has; we have put it where the rest of our cliff analysis lives, in our breakdown of context-window pricing cliffs. The US data-residency premium is the subject of a new section in Codex vs Claude Code, because it is a procurement question more than a pricing one. And for the other end of the market — where promotional pricing rather than surcharges is what moves the number — see the GLM Coding Plan comparison.
Update, 20 September 2026: Anthropic’s Managed Agents product line cannot use the batch discount at all, which makes the same tokens cost exactly 2.00x more than the price table implies
This page has carried a detailed treatment of Anthropic’s batch discount for months, because at 50% across the line it is the single largest lever available to anyone running asynchronous work on Claude. On 20 September 2026 we read two sentences in Anthropic’s pricing documentation that we had never recorded here, and together they remove that lever from an entire product line.
The first, from the Managed Agents section of the pricing page, verbatim: “Sessions are stateful and interactive. There is no batch mode.”
The second, on the same page: when a Managed Agent’s model.inference_geo is pinned to "us", the usage is “billed at 1.1x the standard rates”.
Neither sentence appears in a price column. Neither changes a single per-million-token figure in the tables above. Both change the bill.
The arithmetic, on Sonnet 5
Sonnet 5’s published rates are $2.00 per million input tokens, $10.00 per million output tokens, and $0.20 per million cache-hit input tokens. Batch is 50% across the line. So for one million input tokens, uncached (all of the following is our arithmetic on Anthropic’s published list prices):
| How you send it | 1M input | 1M output | vs batch |
|---|---|---|---|
| Batch API | $1.00 | $5.00 | 1.00x |
| Standard Messages API | $2.00 | $10.00 | 2.00x |
| Managed Agents (no batch mode exists) | $2.00 | $10.00 | 2.00x |
Managed Agents, inference_geo: "us" | $2.20 | $11.00 | 2.20x |
The bottom row is the one worth sitting with. $11.00 per million output tokens is more than Sonnet 5’s standard, undiscounted, unpinned output price of $10.00 — and it is 2.20x the price the same model charges for the same tokens through the batch endpoint. The model did not change. The context length did not change. The prompt did not change. What changed is which product surface you sent the work to, and whether you told it where to run.
Why a spreadsheet built from the price table gets this wrong by a factor of two
Because batch eligibility is not a property of the model. It is a property of the endpoint. A cost model built the obvious way — take the model’s rate, multiply by expected tokens, apply the 50% batch discount to the asynchronous share — will be exactly right for work sent to the Messages API and exactly 2.00x too low for the identical work moved into Managed Agents (our arithmetic). Nothing in the model’s row in the price table flags this, because the constraint lives in a paragraph about session semantics.
We have now hit this same shape three times in three weeks on three different vendors, which is why we are naming it rather than filing it as trivia. On 19 September we documented that xAI’s flagship grok-4.6 receives no batch discount at all while four of its cheaper siblings receive 20%, so the model everyone means when they say “Grok” is the one that cannot be discounted. Before that, the same page showed that the cheapest headline input price on the table produced the second most expensive actual call once long-context surcharges applied. And now Anthropic: a product line where the discount does not merely fail to apply, but does not exist as a mode. The common structure is that the price table is a table of rates, and the bill is a function of rates and eligibility, and only one of those two things is tabulated.
The trade is the same one xAI makes, drawn on a different axis
Yesterday we wrote up an interaction in xAI’s pricing page: the only model eligible for its US-region endpoint is the only flagship excluded from its batch discount, so a regulated team with asynchronous workloads must choose between US data residency and the 20% discount, with no configuration that delivers both.
Anthropic reaches a structurally identical place by a completely different route. There, the exclusion was between models. Here it is between product lines: the surface that gives you a managed, stateful agent loop is the surface on which bulk discounting does not exist, and pinning that surface to US inference adds 10% on top. Two vendors, two entirely different pricing architectures, and in both cases the managed or compliant option and the bulk-discount option are priced as alternatives rather than as things that stack.
We are not going to speculate about why. We have no evidence on intent and two data points is not a trend. But as a planning assumption for anyone building a cost model in the next quarter, “assume managed agent infrastructure and bulk discounts are mutually exclusive until the vendor says otherwise” now has two independent vendors behind it, which is more support than most surcharge assumptions get.
The one mitigation that does survive: caching still works, and the 10% scales with what you were already going to pay
Managed Agents lose the batch discount, but they do not lose prompt caching, and Anthropic’s documented order of operations is that the cache discount is applied first and the 1.1x regional multiplier is applied afterwards. That ordering matters more than the 10% does, because it means the residency premium scales with your actual bill rather than with the list price.
Worked through on one million input tokens at a 95% cache hit rate, which is an ordinary figure for a coding agent with a stable prompt prefix: 950,000 tokens at $0.20 plus 50,000 tokens at $2.00 is $0.29. Pinning that to US inference takes it to about $0.32 — roughly three cents. The same million tokens with no caching at all is $2.00, and pinning that costs a full 20 cents (our arithmetic). Identical compliance guarantee, about seven times the absolute cost, decided entirely by prompt prefix stability.
So the practical shape of the advice inverts the usual one. On a product line that has lost its 50% batch discount, cache hit rate stops being an optimisation and becomes the primary cost control, and it happens to also be the thing that makes the residency premium nearly free. A team that has already done prefix stabilisation work absorbs the move into Managed Agents far better than a team that has not.
What is officially not published
Whether Anthropic intends to add a batch mode to Managed Agents, and whether any other discount mechanism replaces it, is officially not published. Whether the 1.1x multiplier interacts with any Managed-Agents-specific fee beyond token rates is officially not published. We have not filled either gap from third-party sources and we are not estimating.
The tokenizer warning that governs every cross-vendor figure on this page governs these too: Anthropic states that Claude 4.7 and later produce approximately 30% more tokens for the same text, so a 2.00x or 2.20x multiplier computed inside Anthropic’s own price list is exact, while any comparison of these dollar figures to another vendor’s is not.
Related reading on this site: the weekly-allowance view of the same question in GLM Coding Plan vs Claude Code, the data-residency pricing comparison in Codex vs Claude Code, and the long-context surcharge cliffs in Claude Code context window.
Update, 21 September 2026: one vendor charges you to put something in the cache, the other charges you nothing to keep it there, and the cheaper one depends entirely on how many times you read it back
Almost every cross-vendor price comparison you will find, including earlier versions of this page, compares two numbers per model: input and output. Anthropic publishes five numbers for Sonnet 5, and the three in the middle are the ones that decide agent workload bills.
Read verbatim from Anthropic documentation on 21 September 2026, per million tokens, Sonnet 5 is $2 input, $2.50 for a five-minute cache write, $4 for a one-hour cache write, $0.20 for a cache hit, and $10 output. Read verbatim from Z.ai documentation the same day, GLM-5.3 is $1.4 input, $0.26 cached input, $4.4 output, with Cached Input Storage marked Limited-time Free across the entire line.
These are not two prices for the same thing. They are two different billing structures
Look at what each vendor charges for. Anthropic prices the act of writing to the cache above the price of ordinary input: $2.50 for the five-minute tier against $2 for plain input, and $4 for the one-hour tier. Reading back from the cache is then very cheap at $0.20. Z.ai currently charges nothing to write or store, and $0.26 to read back.
So Anthropic makes you pay up front and then makes reuse nearly free, while Z.ai makes entry free and charges a little more on every read. Those are opposite shapes. A single-number comparison cannot express a difference in shape, which is why every article that says one of these vendors is cheaper on cached input is answering a question that has no vendor-level answer.
The break-even is about 42 reads, and no price table contains it
Take one million tokens of context that you intend to reuse, and count the calls. The following is our arithmetic on the published list prices above.
With Anthropic at the five-minute tier, you pay $2.50 once to write it, then $0.20 for each read. Total cost for N reads is 2.50 + 0.20N. With Z.ai, you pay nothing to write it while storage is free, then $0.26 per read. Total cost for N reads is 0.26N. Setting those equal gives 0.06N = 2.50, so N is about 41.7.
Below roughly 42 reads of the same cached context, the free-entry structure wins. Above it, the cheap-reads structure wins, and it keeps winning by a widening margin: at 500 reads the five-minute-tier total is $102.50 against $130. At the one-hour tier the write costs $4, so the equation becomes 4 + 0.20N = 0.26N, and the break-even moves to about 66.7 reads.
That number is the whole answer, and it is not a property of either vendor. It is a property of your session length. An agent loop that grinds over the same repository prefix for an hour reads its cache hundreds of times and sits far above the line. A CI job that builds a fresh context on every run, or a one-shot document question, reads it once or twice and sits far below. The same two price lists produce opposite recommendations for those two workloads, and the price list does not ask which one you have.
Why this keeps happening on this page
This is the same shape we have now documented three weeks running, and we may as well state it as a standing rule: a price table is a rate card, and a bill is a function of rate multiplied by eligibility and by usage pattern, and only the first of those has ever been tabulated. We have seen it between models, where the only model eligible for one feature was the only model excluded from a discount. We have seen it between product lines, where a managed surface simply has no batch mode. Today it appears between billing structures, where the cheaper vendor flips depending on a number that appears nowhere in either table.
Four caveats, and the first one is load-bearing
First, Limited-time Free is a promotion, and we spent this morning watching a different Z.ai promotion end. How long the free cache storage lasts is officially not published. The moment it is priced, the 42 moves, and it moves towards Anthropic. Do not build a twelve-month forecast on the free side of this comparison. Our GLM coding plan versus Claude Code comparison covers what we learned this week about how vendor promotions actually end, which is: not on the stated date, and not with a notification.
Second, tokens are not a standard unit. Anthropic states in its own documentation that its tokenizer produces approximately 30% more tokens for the same text. Dividing a per-token price from one vendor by a per-token price from another assumes the two are counting the same thing, and they are not. The break-even calculation above is internally valid for each vendor in isolation, and the cross-vendor crossover point should be read as an order of magnitude rather than as 41.7.
Third, Anthropic publishes two cache tiers with different write prices and different lifetimes, and we do not know from the Z.ai pricing page whether it offers a comparable time-to-live choice. Whether Z.ai has tiered cache lifetimes is officially not published on the page we read.
Fourth, caching does more than change price. It reduces latency, and neither table prices that at all. A team that would have paid the write cost for responsiveness alone should not be reading the break-even as a reason to skip caching.
What to actually do with this
Before you compare cached input prices between any two vendors, measure one number from your own logs: how many times a typical cached prefix is read before it is discarded. If that number is in the single or low double digits, prefer the vendor that does not charge for entry. If it is in the hundreds, prefer the vendor with the cheap read, and the write premium disappears into the noise. If you have never measured it, that is the measurement to take this week, and it costs nothing.
Two related pages: our breakdown of subscription usage limits explains why subscription allowances and API rate cards cannot be put in the same table, and our Codex versus Claude Code comparison covers the regional endpoint surcharge that interacts with cached pricing in a way that makes compliance nearly free.
All prices in this section are vendor list prices read verbatim on 21 September 2026. Break-even points, totals and ratios are our arithmetic on those published numbers.
Update, 22 September 2026: the price of X Search did not change, the unit did, and the unit is the larger change
As of yesterday afternoon US Pacific time, xAI’s X Search tool is billed differently. Per the vendor’s own announcement, from 21 September 2026 at 12:00 PM PT, X Search is billed at $5 per 1,000 posts fetched and $10 per 1,000 user profiles fetched, replacing the previous $5 per 1,000 calls.
Look at the headline number. It was $5 per thousand. It is $5 per thousand. Anyone maintaining a pricing table by copying the dollar figures across would record no change at all, and every automated price-tracker we are aware of would agree with them. The dollar figure is identical and the bill is not, because the denominator moved.
Why a denominator change has no upper bound
A call is a thing you issue. A post is a thing the service returns. Those are not the same kind of object, and crucially you control the first and the service controls the second.
If a search call returns ten posts on average, the same workload now costs 10x what it did. If it returns fifty, 50x (our arithmetic; the multiplier is simply your average result-set size). The average number of posts returned per call is officially not published, which means the size of this change is not a property of the price list at all — it is a property of your query patterns, and the vendor cannot tell you what it is even in principle.
This is the cleanest example we have yet found of the pattern this page keeps running into. A rate card can only express the rate. The bill is the rate multiplied by something the rate card does not contain. Usually that something is eligibility, or a usage pattern, or a tokenizer. Here it is the literal denominator, changed in place, with the numerator held constant so that the change is invisible to anyone comparing numbers.
The second half of the announcement introduces something that did not previously exist as a billable line at all: user profiles, at $10 per thousand — twice the per-unit rate of posts. There was no profile-based charge under the old structure. So a workload that resolves author profiles alongside search results has gained a cost category, not merely a repriced one, and it is the more expensive of the two.
A third clock, and this time it is the vendor’s own timestamp
We wrote last month that vendor promotions run on at least three independent clocks — the stated date, the moment the advertising comes down, and the moment the notice page is retired — and that they rarely fire in order. This week supplies the same structure on a price increase rather than a promotion, and one of the clocks is now the documentation’s own last-updated stamp.
When we read the page on 22 September 2026, several hours after the stated effective moment had passed, it still carried a last-updated date of 7 September 2026 and still displayed the change as a forward-looking banner beginning with “Starting September 21, 2026.” The rate card below it had not been rewritten. The announcement had taken effect; the page describing it had not caught up.
So a last-updated stamp does not track effectivity, and a pricing page can be simultaneously current by its own timestamp and wrong about what you will be charged. Our position for this site is to follow the vendor’s stated effective date over the state of the rate card, and to say so explicitly — which is what this paragraph is. If your own monitoring keys on the last-updated field, it would have told you nothing happened yesterday.
The general form, which is worth more than the specific case: a documentation page has at least three dates attached to it — when it was written, when it was last touched, and when the thing it describes takes effect — and only the middle one is usually displayed. Monitoring the displayed one is monitoring the least informative of the three.
What to do if you use search tooling inside an agent loop
The exposure here is concentrated in exactly one place: agents that call search on their own initiative, in a loop, without a human reading each result. Under per-call pricing, a chatty agent was cheap because each decision cost the same trivial amount. Under per-result pricing, the same agent’s cost scales with how much the world has to say about its query, which is not a quantity it or you are choosing.
- Measure your posts-per-call before you estimate anything. This is a number you already have in your logs and the vendor does not. It is the entire multiplier, and until you have it your cost estimate is not an estimate.
- Cap the result set at the call site if the API lets you. Under per-call billing, requesting more results than you need was free. It is now linear in cost, which makes an over-broad limit parameter a recurring charge rather than a harmless default.
- Account for profile lookups separately. They are a new line at double the rate, and code that resolves authors as a convenience was previously invisible on the bill.
- Re-run the build-versus-buy comparison, not just the budget. A 10x or greater change in one input can flip a decision that a 10% change would not have touched.
The wider lesson for reading any price table, including this one
Every table on this page has a unit in its column header, and until today we would have said the units were the boring part. They are not. The four units currently in play across the vendors we track are per call, per returned item, per token, and per credit, and they have wildly different properties:
- Per call — you control the count exactly. Fully predictable, and the only one of the four that is.
- Per returned item — the service controls the count. Predictable only after you have measured your own average, and it can change without any price changing.
- Per token — roughly controllable, but not comparable across vendors, because tokenizers differ. Anthropic has stated that Claude 4.7 and later produce approximately 30% more tokens for the same text, which means identical per-million prices are not identical prices for identical work.
- Per credit — controllable only if the vendor publishes the credit-to-work conversion, and several do not. An unconvertible unit cannot be budgeted in at all, whatever its price.
Ranked by how much you can trust a comparison built on them, that list is in descending order, and yesterday’s change moved one product from the top of it to the second rung without changing a single dollar figure. When you next compare two vendors, check that the column headers match before you compare the cells. We have been caught by this ourselves, which is why it is written down here.
Two related pages, if this is the thread you are pulling. The same rate-versus-unit problem shows up inside a single vendor’s own lineup, where a model ladder is priced by multiplier rather than per rung — we work through a published example in our GLM Coding Plan versus Claude Code comparison, including a subscription that is denominated in credits with no published conversion. And the reason search-heavy agent loops are expensive in the first place is that every fetched result has to be carried in context on subsequent turns, which is the mechanism our guide to the Claude Code context window covers in detail: a per-result charge and a per-token charge bill you twice for the same fetched post, once to retrieve it and once for every turn it stays in the window. If you want the narrower question of how two coding agents compare on total cost rather than rate, our Codex versus Claude Code breakdown is the page for that.
Qualifiers
- We are following the vendor’s announced effective date, not the state of its rate card. When read on 22 September 2026 the pricing page still carried its pre-change rate and a 7 September last-updated stamp. If the rollout slipped, our reading of “now in effect” is wrong, and the page itself would not tell you either way.
- The 10x and 50x figures above are illustrations, not measurements. The multiplier equals your average posts returned per call, and that number is officially not published by the vendor. Yours is in your logs and nowhere else.
- We did not fetch the vendor’s full developer pricing index, only the X Search page. Other tools in the same family may or may not have had their units changed in the same pass.
- Nothing here transfers to other vendors’ search tooling. Per-call pricing elsewhere remains per-call until separately announced, and we are not extrapolating an industry trend from one vendor’s change.
Update, 23 September 2026: DeepSeek’s price list turned out to be readable after all, and it contains a time-of-day multiplier that charges two teams different amounts for identical work
We owe a correction before the numbers. On 16 September we recorded DeepSeek’s pricing as officially not published, having judged the pricing page to be a client-rendered application whose figures were rendered as images. That judgment was either wrong or has since stopped being true. On 23 September 2026 an ordinary fetch of the same URL returned the complete table in plain text. We are recording the correction at the same prominence as the original claim, and we have added a rule to our own process: any source marked unreadable gets retried on a fixed cycle rather than written off. Thirteen days of numbers sat in the open because we did not have that rule.
The table, as published
US dollars per million tokens, effective 10 September 2026 at 04:00 UTC. Each cell is off-peak / peak.
| Row | deepseek-flash (DeepSeek-V4.1-Flash) | deepseek-v4-pro (DeepSeek-V4-Pro-0813) |
|---|---|---|
| Input, cache hit | $0.003 / $0.006 | $0.022 / $0.044 |
| Input, cache miss | $0.15 / $0.30 | $0.66 / $1.32 |
| Output | $0.60 / $1.20 | $1.98 / $3.96 |
| Context / max output | 1M / 384K | 1M / 384K |
| Concurrency ceiling | 2,500 | 500 |
| Vision | Supported | Not supported |
The peak definition, verbatim
Off-peak rates are half of the peak rates. Peak hours are 01:00 – 04:00 and 06:00 – 10:00 UTC, Monday through Friday, excluding Chinese public holidays. All other hours are off-peak, including weekends and Chinese public holidays in full.
Seven peak hours a day, five days a week, with a three-hour gap in the middle. Everything else on the clock — including all of both weekend days, and Chinese public holidays in their entirety — is half price.
Who pays peak, and it is not who you would guess
Convert the published window into local time and the pricing page acquires a column it does not have.
- Beijing time (UTC+8): peak is 09:00–12:00 and 14:00–18:00 on weekdays — the Chinese working day with the lunch hour cut out of the middle (our arithmetic).
- US Pacific daylight time (UTC−7, in effect through 1 November 2026): peak is 18:00–21:00 and 23:00–03:00 — entirely outside the American working day (our arithmetic).
- Central European summer time (UTC+2): peak is 03:00–06:00 and 08:00–12:00 — the European morning is peak, the European afternoon is not (our arithmetic).
Put numbers on it. A team working 09:00–18:00 in Beijing with an hour for lunch spends seven of its eight billable hours inside peak: 87.5%. A team working 09:00–17:00 in San Francisco spends 0% of its billable hours inside peak. Holding usage exactly identical, the Beijing team’s blended rate is 1.875x the San Francisco team’s (our arithmetic: 0.875 x 2 + 0.125 x 1). Same product, same list price, same workload, nearly double the invoice.
Readers of this page will recognise the shape. This is the fifth distinct column we have found that determines your bill and does not appear on any price list: eligibility (who is allowed to buy the cheap thing), usage pattern (cache-hit rate, average result-set size), the tokenizer (Anthropic states that Claude 4.7 and later produce roughly 30% more tokens for the same text), the denominator (xAI changing per-call to per-post without touching the dollar figure), and now the time zone you happen to work in.
And note what it is not. Nobody is being overcharged, nothing is hidden, the window is stated plainly in UTC with a worked definition. The page simply does not contain a row saying which of those two teams the price was designed for — and that row would change the purchasing decision more than any of the rows it does contain.
The pattern across two vendors
We wrote up Alibaba Model Studio’s off-peak window on 22 September: 22:00–08:00 Beijing time, at 0.2x for Qwen3.7-Max and 0.4x for 3.7-Plus. Converted, that discount window is 14:00–00:00 UTC, which contains the entire US Pacific working day (our arithmetic).
So the two Chinese vendors on this page, using completely different mechanisms — one an explicit discount multiplier, the other an implicit surcharge expressed as peak hours — arrive at the same place: the cheap window is, in practice, the American working day, and the full rate applies during their own. Neither page states a reason. The obvious one is domestic capacity, but that is our inference from the timing and not something either vendor says, so treat it as a hypothesis rather than a finding.
The actionable version, for anyone doing this comparison from outside China: a headline rate from a Chinese vendor is more likely to be the rate you actually pay than the same rate quoted by a team in Shenzhen. That is a strange sentence to have to write on a pricing page, and it follows directly from published numbers.
Against Anthropic’s list, with the caveat that has to come first
Before any cross-vendor per-token percentage on this site: Anthropic states that Claude 4.7 and later use a tokenizer producing roughly 30% more tokens for the same text. A price per million tokens therefore does not buy the same amount of text at the two vendors, and every figure in the next list is an upper bound on precision, not a measurement.
With that stated, against Claude Sonnet 5 at $2 / $10 and the newly added Claude Opus 5.5 at $4 / $20:
- deepseek-flash cache-miss input, peak $0.30 against Sonnet 5’s $2.00: 85% less. Off-peak $0.15: 92.5% less (our arithmetic).
- deepseek-flash output, peak $1.20 against $10: 88% less. Off-peak $0.60: 94% less (our arithmetic).
- deepseek-v4-pro peak $1.32 / $3.96 against Opus 5.5’s $4 / $20: 67% and 80.2% less (our arithmetic).
- Cache hits, the row nobody compares: deepseek-flash at $0.006 peak and $0.003 off-peak against $0.20 at Anthropic for both Sonnet 5 and Opus 5.5: 97% and 98.5% less (our arithmetic).
Apply the tokenizer adjustment and these gaps widen rather than narrow, because the correction makes the Anthropic side more expensive per unit of text, not less. Which is precisely why none of those percentages should be quoted to one decimal place by anyone, including us. The defensible statement is “an order of magnitude on cache-miss input and roughly two orders on cache hits” — and if a decision flips between 85% and 92.5%, the decision was not really about price.
A retired model that still answers to its old name
From the same page: “The legacy names deepseek-v4-flash and deepseek-v4-flash-vision-exp are still accepted, but the corresponding models have been retired, their requests are served by the DeepSeek-V4.1-Flash model and billed at the Flash price.”
Set that beside the OpenAI situation documented elsewhere on this page and you get a matched pair of opposites. OpenAI keeps deprecated models listed on the rate card at their own rates, so the card describes models you may no longer be able to reach. DeepSeek keeps retired names reachable but silently reroutes them to a different model and reprices them. In the first case the price list outlives the model; in the second the model name outlives the model.
The common consequence is the one worth writing down: the model string in your configuration file is no longer a reliable statement of what you are running or what you are billed for. If you want to know either, the only trustworthy sources are the response metadata and the invoice.
Concurrency, sold from a different aisle
DeepSeek publishes concurrency ceilings as an attribute of the model: 2,500 for Flash, 500 for v4-pro. The subscription vendors on this page publish concurrency as an attribute of the plan — a number of parallel agents that goes up as you pay more.
Same constraint, opposite shelf. With DeepSeek, running more agents in parallel costs nothing extra until you hit a hard ceiling that money cannot move on that model. With a subscription, the ceiling is exactly what the upgrade is selling you. Anyone whose real constraint is fan-out rather than volume should compare those two sentences before comparing any prices at all.
Anthropic’s third cache multiplier, briefly
Also this week, the Anthropic price list added Claude Opus 5.5 at $4 input and $20 output with a cache hit of $0.20, under a footnote reading “Cache hits and refreshes on Claude Opus 5.5 are priced at 0.05x the base input price.” Anthropic now runs three different cache multipliers across its lineup — 0.1x standard, 0.05x on Opus 5.5, 0.025x on Fable and Mythos 5.1 — which means the cached-input column on this page can no longer be computed from the input column and has to be quoted model by model. The consequence for the Sonnet-versus-Opus decision, where the two now share an identical $0.20 cache-hit price, is worked through on our Codex vs Claude Code comparison.
What to do with this table
- Work out what share of your calls land in 01:00–04:00 and 06:00–10:00 UTC. That single percentage turns every DeepSeek figure above into one number instead of two. It is in your request logs and it takes one query.
- If that share is high and your work is batchable, moving it is a 2x price change for zero engineering. Very few cost levers on this page are that cheap to pull. Most of them require changing model, vendor or architecture; this one requires changing a cron expression.
- Do not compare a peak rate to a competitor’s flat rate. Pick the one that matches when you actually work, state which you picked, and say so in the comparison. Quoting off-peak against a rival’s only rate is the same category of error as quoting a promotional price against a list price.
- Re-read your own model strings. Between OpenAI’s deprecated-but-listed rows and DeepSeek’s retired-but-routable names, the config string and the invoice line have come apart at two vendors in the same week.
Related reading on this site: DeepSeek also published an official Claude Code configuration this week, including a model mapping that decides which of the two price columns above you land in — we work through that on GLM Coding Plan vs Claude Code. For why a large stable context makes the cache-hit row the one that dominates an agent bill in the first place, see Claude Code’s context window.
Update, 24 September 2026: Kimi K3’s cheapest cache tier costs exactly what sending the tokens would have cost, and a sentence vanished from Anthropic’s price page while every number stayed put
Two changes worth recording today, one of them a rate card and one of them the absence of a rate card. We take the numbers first.
Kimi K3 now publishes tiered cache writes
| kimi-k3 | Price per million tokens |
|---|---|
| Input | $3.00 |
| Output | $15.00 |
| Cache write, 5 minute | $3.00 |
| Cache write, 1 hour | $6.00 |
| Cache hit | $0.30 |
| Context | 1,048,576 |
We cannot tell you whether the cache-write tiering is new or whether we simply failed to record the column earlier — our 17 September notes do not have it, and those two possibilities look identical from the outside. We say so rather than presenting it as a change we observed.
The five-minute cache write is free, in the only sense that matters
Look at the first and third rows. Input is $3.00 per million. A five-minute cache write is $3.00 per million. They are the same price.
That single coincidence removes an entire calculation that every other vendor forces on you. Everywhere else, caching is a bet: you pay a premium to write, and you need enough reuse before expiry to earn the premium back, so you compute a break-even and you get it wrong because you do not know your own reuse rate. On Kimi K3’s five-minute tier there is no premium, so there is no break-even and no bet. The tokens cost what they would have cost if you had simply sent them. Every subsequent hit inside those five minutes is billed at $0.30 instead of $3.00, which is a 90% discount on a cost you had already committed to (our arithmetic).
The actionable form is unusually blunt for this site, which normally has to tell you it depends on your workload: on K3, if any part of your prompt might be reused within five minutes, cache it, and you do not need to check whether it was worth it. A single reuse is pure profit. Zero reuses cost you nothing. We cannot think of another line on this page where the correct decision is independent of your usage pattern.
The one-hour tier is a real bet and does need arithmetic. It costs $6.00, which is 2.00x input (our arithmetic), so you are paying $3.00 extra per million up front. Each hit then saves you $2.70 against a fresh read. $3.00 divided by $2.70 is 1.11, so the one-hour tier pays for itself on the second reuse within the hour (our arithmetic). If your agent loop touches the same context twice an hour, take it. If it touches it once, take the five-minute tier and let it lapse.
Note also that the hit-to-input ratio here is $0.30 against $3.00, exactly 0.1x — the same constant we have seen across OpenAI’s current models and Anthropic’s standard tier. The industry has converged on a tenth for cache hits while diverging completely on what it charges to put something in the cache in the first place, and the write side is the one nobody puts in a comparison table.
Moving from K2.7 to K3 changes your bill by somewhere between 3.75x and 15.8x, and which one depends entirely on your output ratio
K3 input is $3.00 against k2.7-code’s $0.19, a factor of 15.8x. K3 output is $15.00 against $4.00, a factor of 3.75x (our arithmetic). Those two numbers are more than four times apart, which means there is no single multiplier for “upgrading to K3”.
This matters more than it looks, because coding agents sit at the extreme end of the input-heavy distribution. A workload that reads a large repository context and emits a small patch is almost all input, so it lands near 15.8x. A workload that generates long files from short instructions lands near 3.75x. The same model upgrade can quadruple one team’s bill and quindecuple another’s, and the price page cannot tell them apart because the variable is in their code, not in the rate card.
The five-minute cache tier interacts with this directly and favourably: it is the input side that explodes on K3, and the input side is exactly what caching addresses at no premium. An input-heavy agent moving to K3 without caching faces something near 15.8x; the same agent with a warm five-minute cache pays $0.30 on the cached portion, which is 1.6x k2.7-code’s uncached input rather than 15.8x (our arithmetic). Caching is not a tuning detail on this upgrade path. It is the difference between two completely different decisions.
As always with cross-vendor figures, the tokenizer caveat applies before you compare any of this to Anthropic or OpenAI pricing: Anthropic has stated that Claude 4.7 and later count roughly 30% more tokens for the same text, so per-token list prices across vendors are not directly comparable in either direction. The K2-to-K3 ratios above are within one vendor and one tokenizer, so they are clean. The moment you carry them across a vendor boundary they are not.
A correction to this page: we quoted a sentence that Anthropic has now removed
This page has stated, in four places, that Anthropic had explicitly cancelled a previously scheduled increase to $3 and $15 per million for Sonnet. That was accurate: the sentence was on the official pricing documentation, and it was still there when we read the page on 23 September 2026.
As of our reading on 24 September 2026, that sentence is no longer on the page. The rate table has also been restructured into four highlighted rows plus a section headed “Additional models”.
Every price is unchanged. Sonnet 5 is $2 input and $10 output per million, cached input $0.20. Opus 5.5 is $4 and $20, cached input $0.20, with the 0.05x base-input footnote intact. The 1.1x regional inference multiplier, the long-context provision and the tokenizer note are all still published. Nothing we have told you about what Anthropic charges has become wrong today.
What has become wrong is weaker and more specific: we told you the increase had been cancelled, on the authority of a sentence you can no longer go and check. We are not withdrawing the claim, because it was true when published and the vendor said it. We are attaching this note to it, and we are not editing the earlier paragraphs to pretend we never wrote them.
We are explicitly not telling you that a price rise is coming. We do not know why the sentence was removed. A cancellation note that has served its purpose is a routine thing to delete during a page redesign, and this page was redesigned on the same day. That explanation and the alarming one fit the evidence equally well, and the evidence is one deleted sentence. Anyone publishing a confident reading of this today is reading tea leaves, and if we did it we would be doing the precise thing this site was built to argue against: putting a number-shaped guess where a vendor statement used to be.
What you should do is unaffected by which explanation is right, which is a good sign that it is the correct advice: budget against $2 and $10, because that is what is published and what you will be billed. If your model has a line for a possible increase to $3 and $15, that line was always speculative and it still is; today it simply lost the vendor sentence that had been suppressing it.
The sixth column that decides your bill: the ones that used to be there
This page has been keeping a running list of things that determine what you pay and do not appear as a column on any price list. So far: eligibility, usage pattern, tokenizer, denominator, and timezone. Today adds a sixth, and it is of a different kind from the other five.
The first five are hidden columns — real variables that the table omits. The sixth is a removed row: something the page used to say, that is now gone, and whose absence leaves no mark.
The structural point is that a pricing page is two documents wearing one URL. One of them is a table of numbers, and it is maintained like a table of numbers: customers check it, discrepancies get reported, changes tend to get announced. The other is prose — the commitments, the exceptions, the reassurances, the “this will not change” sentences — and nobody diffs prose. Numbers get changelogs. Sentences get deleted.
Every vendor on this page has prose commitments that a procurement decision might be resting on: promotional rates described as lasting “at least through” a date, deprecation timelines, rate-stability assurances, free-tier availability “subject to rollout”. None of those live in a table. All of them can be revised by someone editing a paragraph, and you will not get a notification, because there is nothing in the publishing model of a documentation page that treats deleting a sentence as an event.
So the practical instruction is: archive the paragraphs, not just the tables. When a vendor sentence is load-bearing for a budget or a contract, save it with the date you read it. It costs ten minutes once and it is the only version of that sentence that will still exist if the vendor changes its mind. We have been recording vendor prose with read-dates on this site for exactly this reason, which is the only reason we can tell you today what the page said yesterday.
It also changes how you should read every “vendor confirms X” article, including ours. A confirmation is a snapshot, not a state. The useful question is never “did they say it” but “is it still on the page”, and only the second one has an expiry date attached.
What to do this week
- If you run anything on Kimi K3, turn on five-minute caching everywhere it could conceivably apply. It costs the same as not caching. This is the rare optimisation with no downside case to evaluate.
- Before moving a workload from K2.7 to K3, look up your input-to-output ratio — it is in your logs, and it decides whether this upgrade multiplies your bill by under four or by nearly sixteen.
- Budget Anthropic at $2 and $10. That is the published number and it did not change today.
- Spend ten minutes archiving vendor prose. Promotional end dates, deprecation schedules, rate assurances: save them with the date you read them. Today is the demonstration of why.
For how a fourth vendor’s arrival has left the four documented Claude Code back ends billing in four mutually inconvertible units — prompts, token allowances, metered tokens and now concurrent agents — see our comparison of the GLM coding plan against Claude Code. For why Anthropic’s cached-input price can no longer be derived from its input price, and why that breaks cost spreadsheets silently rather than loudly, see our Codex vs Claude Code comparison. And because everything above turns on how much context you are re-reading each turn, our guide to the Claude Code context window covers where that number actually comes from.
All prices are vendor list prices read on 24 September 2026. Figures marked as our arithmetic are our own calculations on published numbers. Vendor benchmark claims are not used anywhere in this comparison. Where a vendor does not publish a figure we say so rather than estimating it.