MiniMax priced M3.1 Flash at $0.60 per million output tokens on October 19, but the figure it led with was a different one: overall agent-task usage costs 70% below its previous model. When the vendor treats the gap between list price and job cost as the main selling point, the rate card has stopped working as a price.
That is what this week's releases had in common. Labs now compete on how much a finished task costs, not on what a token costs. They have four ways to move that number. They can train the model to emit fewer tokens. They can shrink the hardware a deployment needs. They can swap open-ended generation for cheap constrained decisions. And they can bundle the tools an agent calls around each task. None of these shows up in a per-million-token table, and so the table can no longer tell a buyer what a workload will cost.
Two similar stickers, two different bills
Inception's Mercury 3 lists standard pricing of $0.20 per million input tokens and $0.70 per million output tokens, cut in half during a launch discount. MiniMax's M3.1 Flash lists $0.15 input and $0.60 output. On a comparison spreadsheet these two models land in the same row.
The spreadsheet assumes a token is a fixed unit of work, and for agent workloads it is not. What a task costs depends on how many tokens the model writes before it finishes, how often it fails and retries, how many tool calls it makes along the way, and how much hardware has to stay up to serve it. Two models with near-identical token prices can therefore differ several-fold in cost per accepted result. A model that writes half as much and retries less is cheaper even at a higher list price. A model that is cheap per token but rambles, loops or needs a human to clean up is more expensive than it looks.
None of this is new to anyone who has run agents in production. What is new is that vendors have started engineering for it directly and pricing around it.
Lever one: train the model to stop talking sooner
Reflection's Beam is a 501-billion-parameter model with 23 billion active per token, and the company says reinforcement learning trained it to complete tasks with fewer tokens. That claim deserves to be read literally. Reflection is not saying its tokens are cheaper. It is saying you will buy fewer of them. The release came with Apache 2.0-licensed deployment software, and Dell and HPE will install the model on customer hardware. Here the efficiency pitch is bundled with a delivery channel rather than a price cut. [L2] Per the AI Market Watch index, Reflection AI has raised $4.63B in total funding, though the index tracks about 5,000 companies and is coverage, not a census. A lab with that much capital and no need to lead on price is free to compete on token thrift instead.
DeepSeek's V4.1-Flash-1017 makes the same move in a more pointed way: the company says the model cuts task duration, output length and token costs, and its training included optimizations for DeepSeek Harness. Getting the full improvement requires Harness version 0.2.1-rc.1 or later. Outside coverage summarizes the release as raising coding and agentic benchmark scores while cutting task time and output length.
The harness requirement matters more than the benchmark gain. A model trained for one particular scaffold delivers its advertised efficiency only inside that scaffold. A buyer who runs it through their own orchestration layer may see more tokens per task than the vendor's demo did, and that gap shows up nowhere on the price table.
Lever two: shrink the deployment
Ant Group's Ling-3.1-flash has about 560 billion total parameters, activates about 25 billion per token, and uses a mixed-precision approach that cuts model-weight memory from roughly 534GB to 292GB. In the team's reported Hopper GPU configuration, that halves the deployment from eight GPUs to four.
For self-hosted open-weight models, this is the cost lever that counts. A sparse model with few active parameters still needs all of its weights in memory, so the replica footprint, not the active-parameter count, sets the floor on what serving costs. Halving the GPUs per replica halves the fixed hardware a team has to reserve before it serves a single request. Reflection's version of the same claim is that quantized Beam runs on eight-GPU servers. Both labs are selling the size of the box the model fits in.
The caveat sits in the source itself. Ant's memory reduction is a deployment result and comes with no evidence of equal task quality, throughput or latency across configurations, especially at the advertised one-million-token context. A four-GPU replica that needs more retries does not save money.
Lever three: replace generation with a cheap decision
TypeSafe AI's Jev reached 35% of paid teams on Vercel's AI gateway within two weeks of launch, nearly twice the share of runner-up Sonnet 5.5. The precise figure was 35.3% of paid teams on Vercel AI Gateway. Jev picks from predetermined outputs, an approach the report describes as cheaper and faster than alternatives such as Sonnet for high-volume classification.
This is the most extreme version of the thesis. When the output space is a fixed label set, output-token cost almost disappears as a variable. What remains is a decision and how accurate it is. Vercel itself replaced GPT-6 Luna with Jev for harmful-command classification. That is a gateway operator choosing a model by what the decision costs, not by what a token costs.
Mercury 3 reaches a similar result through architecture: Inception reports 1,068 tokens per second on NVIDIA GPUs and claims it runs four to eight times faster than the models it benchmarks against. Speed matters to task cost because agent loops pay for wall-clock time in idle infrastructure and blocked workflows. But speed per token is still not speed per task. Early user Octen AI reports a median generation time of 0.9 seconds against a median total response time of 2.2 seconds. More than half the latency a user feels is spent outside generation, and no throughput figure captures it.
The headline numbers have moved
The clearest evidence of the shift is what vendors now put in the first line of a release. MiniMax's own announcement says that for agentic tasks, overall usage cost is 70% lower than its predecessor, with token prices listed underneath as supporting detail. The company pairs that with a claim of nearly three times faster online inference and company-reported scores of 73.7% on DeepSWE v1.1 and 61.7 on OSWorld V2.
DeepSeek's release notes follow the same order: task duration and output length first, token cost as the outcome of those. Neither lab led with a per-token cut. Both led with a per-task saving measured against their own previous model, inside their own environment.
That framing is honest about what buyers actually pay for. It is also unfalsifiable from outside until someone runs the workload. A per-token price can be checked against an invoice. A per-task saving is a claim about a distribution of tasks the vendor picked.
Lever four: charge for the work around the task
Alongside V4.1-Flash-1017, DeepSeek opened Search and Fetch APIs, priced at RMB 5 per 1,000 successful requests, with free access until November 1. Failed requests, empty search results and timeouts are not charged.
The billing design is the interesting part. Charging only for successful requests prices the tool by outcome, which is the same unit the model release argues on. It also moves spend from the token line to a tool line. An agent doing research or coding now pays DeepSeek for the model's reasoning and for the retrieval that feeds it. If the model gets cheaper per task because it writes less, some of that saving can come back to the vendor as tool calls.
That is the pricing-power mechanism The Price Floor Was Never the Moat argued for: margin comes from where you hold pricing power, not from how low your list price is. This week shows a route to that power that never touches the token price. Change the unit of comparison to cost per task, train the model to run best inside your harness, and sell the tools the harness calls. The token price can stay flat or even fall while revenue per task holds or rises. A buyer comparing rate cards would see none of it.
The compression precedent
DeepSeek has done this before at a different layer. Its earlier capability-compression arc reset what the market believed frontier-level capability should cost, and competitors' prices moved in response without any of them adopting the same architecture. Efficiency claims from a credible lab work as pricing signals before they work as engineering facts.
The current claim has the same shape but a different unit. Last time the argument was capability per training dollar. This time it is accepted results per serving dollar, and the lab is building the measuring instrument, its own harness, alongside the model. [L2] DeepSeek's attention share has grown along with this: the AI Market Watch pipeline logged 206 items matching "DeepSeek" in the last 180 days against 46 in the prior 180, a name-matched count over pipeline-ingested sources only. A lab with that much visibility sets the terms other vendors get compared on.
Buyers will have to measure the task themselves
The practical consequence is that procurement has to move to the unit vendors already argue in. Buyers and gateways will route and contract on cost per accepted result for their own workloads, measured with the vendor's harness and tools included, because that is the only comparison that accounts for output length, retries, tool charges and hardware footprint together.
Gateways are well placed to do this, and they have limits. Vercel's data can undercount OpenAI and Anthropic usage through their direct APIs, and Jev's share of teams says nothing about its share of spending or workload volume. A gateway can see which model a team picks. Unless it also sees whether the result was accepted, it is still routing on proxies.
The measurement has to include the harness, which is the uncomfortable part. If a model's efficiency depends on a vendor-specific scaffold, an evaluation run in a neutral harness understates it, and one run in the vendor's harness ties the buyer to that harness. Both approaches are defensible, and they will give different answers.
Open-sourcing the engine, keeping the bundle
DeepSeek also open-sourced the framework behind its production inference service, which The Information describes as a high-margin operation. The release came with no quantified efficiency gains or margin figures.
That looks like it cuts against the bundling thesis, but it fits. Serving efficiency is the lever easiest to copy: once the framework is public, any operator can try to reproduce the per-replica economics. What cannot be copied by downloading a repository is a model trained for a specific harness, combined with retrieval priced per successful call. As efficiency becomes common, the differentiation moves to the bundle. Giving away the engine makes the bundle the only place left to compete.
What could break this
Every per-task saving cited here is company-reported. MiniMax's 70% figure compares the new model to its own predecessor, not to competitors, and its benchmarks do not establish success rates or supervision needs in customer workflows. DeepSeek's gains come from company evaluations and demonstrations. The report on Beam includes no independent evaluation showing a lower cost per successful task. If independent measurement finds that shorter outputs come with more retries or more human correction, per-task pricing becomes a marketing frame laid over unchanged economics, and buyers will go back to the token tables because those can at least be audited.
Timing creates churn as well. DeepSeek's retrieval APIs are free only until November 1, and Mercury 2 and 2.5 customers have until November 15 to migrate. Cost-per-task numbers measured during free windows and launch discounts will not hold at paid rates.
Notes. The open question is who will publish cost per accepted result on shared workloads, harness included, before vendors' own per-task figures become the de facto benchmark. Gateways have the traffic to do it. None has shown it can see whether a result was accepted.
