Per-Token Pricing Tests for Generative AI Products
Cheaper models often cost more per completed task than pricier alternatives.
The spread in model pricing right now is wide enough to change which experiments are even worth running. Efficient models run well under $1 per million tokens. Frontier output tokens sit anywhere from $15 to $180 per million, depending on the provider and how much reasoning the task demands. Where a product sits on that spectrum decides the shape of its whole pricing conversation. A product built on cheap models can afford to test generous quotas. One built on frontier reasoning models starts from a much thinner margin, and that difference should show up in the test design from day one, not get discovered halfway through.
The spectrum keeps moving, too. LLM API prices fell by roughly 80% between early 2025 and early 2026. GPT-4o input pricing dropped from $5.00 to $2.50 per million tokens in that span, and o4 Mini now offers input tokens at $0.55 per million. Any price a team set against 2024 cost assumptions is almost certainly wrong today, not because the team miscalculated, but because the ground under it moved.
Some of that movement is scheduled, which at least makes it plannable. Google's Gemini 3.x Flash models (the 3.8, 3.7, and 3.6 Flash variants on its Agent Platform) are priced at $0.75 input and $3.75 output per million tokens through the end of 2026. Standard pricing jumps to $1.50 and $7.50 per million tokens starting January 1, 2027. That's a known cliff, not a surprise, and a pricing test running through the back half of 2026 has to plan around it instead of treating current cost as permanent.
Reasoning effort adds a wrinkle. Turning up reasoning effort on OpenAI or Anthropic models doesn't trigger a separate surcharge; reasoning tokens bill at the same rate as regular output tokens. What changes is volume, so a product offering a "thorough" mode is really just selling more tokens under a friendlier name.
Layered on top of all this is the early emergence of spot-priced API access, where providers bid for usage in real time instead of posting a fixed rate card. That turns a once-stable input cost into something closer to a commodity market, and it means a pricing test built today can get invalidated by an upstream cost shift before the test even finishes running. Treat model cost as weather, not bedrock.
What the cost-efficiency trap reveals about the real unit of analysis
Most teams get this backwards: the cheapest model per token is often not the cheapest way to finish a task. A model that needs more retries, longer prompts to reach the same result, or a human to clean up its output can cost more per completed task than a pricier model that gets there in fewer turns. A dashboard that only shows cost per million tokens hides this completely, because that number says nothing about how many tokens it actually takes to produce something usable.
Agentic workflows make the trap worse, and the mechanism is worth spelling out. A sequential agent resends its full conversation history on every call, because that's how most agent architectures work. Turn one might send a few thousand input tokens. By turn thirty, the model is carrying tens of thousands of tokens of accumulated context on a single request, none of it new information, all of it billed. A model with lower reliability per step generates more retries, more retries mean more accumulated context, and more accumulated context means more corrective output on the next turn. That compounding can erase whatever savings came from picking the cheaper model in the first place.
Cost per successful outcome is the unit that matters here, not cost per token and not cost per API call. A resolved support ticket, a completed draft, an accurate extracted answer: these are what customers actually pay for, and they're what a pricing test should measure against. Framed this way, a pricing test stops answering "what price clears the market" and starts answering what price reflects the value delivered per outcome while still covering what it costs to produce that outcome. Skip that reframe, and a team ends up setting its output-token price against input-token cost assumptions, then finds the margin hole only after signing customers at the wrong rate. That's the expensive way to learn it, and it's an avoidable one.
The hybrid pricing structure that has become the durable default
By 2026, most AI products converged on the same shape, with a subscription bundling a base capability level and an included token quota, an overage price beyond that quota, and an optional volume commit that lowers the marginal rate for customers willing to pre-buy scale. This is not new. Telephony, cloud infrastructure, and CDN providers ran on nearly identical structures for decades, because high variable cost against a fixed price ceiling produces the same math no matter what's being metered underneath.
Hybrid models (subscription plus usage) have been widely observed gaining ground on both pure subscription and pure usage-based approaches across the industry. The shift toward hybrid consumption pricing has accelerated, while pure seat-based pricing has lost ground over the same period. Companies are actively abandoning a model that no longer matches how AI products cost money to run. A team still defending a flat per-seat price in 2026 is defending a structure the rest of the market already left behind, an indefensible position whatever the sales deck says.
Recent examples make the shape concrete. Clay introduced a dual-credit billing system in March 2026 that splits data marketplace costs (Data Credits) from platform workflow usage (Actions) into separate buckets, instead of folding both into one opaque number. HubSpot announced outcome-based pricing for its Breeze AI agents in April 2026. Anthropic lowered its Enterprise seat prices while pushing further into usage-based billing for the underlying consumption.
Credit packs deserve a name of their own here. A customer buys a pack upfront, say $20 worth, and spends it down against consumption. No subscription anxiety attached, revenue lands before usage happens, and a depleted balance becomes a natural, low-friction upsell trigger. Adoption of credit-based models grew through 2025, and a growing share of AI companies have moved toward credits or are actively evaluating them. For most teams, the live question now is how to implement the shape they adopt. It's setting the quota, the overage rate, and the commit discount correctly, and that only happens through testing.
What to vary in a per-token pricing test and why each lever matters
Four levers do most of the work. The input/output ratio comes first: most products pass the upstream asymmetry straight through unchanged, but testing a blended rate against a split rate shows whether a given customer segment cares more about transparency or simplicity.
The included quota size is the second lever, and probably the most consequential one. Set it too high, and heavy users get subsidized at the expense of margin. Set it too low, and customers hit bill shock and churn before they've seen what the product can do. The right number gets found empirically, from the actual distribution of usage, not assumed from a spreadsheet built before launch.
The overage rate is where margin gets made or lost, since it's the price charged on every token past the included quota. Testing this at different multiples of underlying cost reveals price elasticity specifically among the customers who push past their quota, usually a small but economically important group. The fourth lever, the volume commit discount, decides which customers are worth locking in at a lower margin in exchange for revenue certainty, and which will keep paying the standard rate without ever committing to volume.
A few secondary levers interact with all four. Some providers cut the rate as monthly consumption crosses defined thresholds, a lower price for the first tranche and a lower one still after that, and testing this against a flat overage rate shows whether tiering changes behavior or just adds complexity nobody asked for. Prompt caching is another lever worth testing directly: cached input tokens cost a fraction of fresh ones on platforms that support caching, and whether that discount gets passed to the customer, kept as margin, or used to fund a lower headline price is a real decision, not a default. Reasoning-effort tiers work the same way, since a "standard" versus "thorough" response tier can carry different prices without ever touching the underlying per-token rate.
Agent traffic complicates all of this, because context accumulation means token consumption on an agentic task grows substantially with task complexity. Pricing tests for agent products need to model that curve directly instead of assuming usage scales in a straight line. The single most useful early test, before any threshold gets set at all, is mapping the actual distribution of token consumption across the existing customer base. Usage distributions tend to be heavy-tailed, and the included quota should be set against the real usage distribution, not the average, a number almost nobody's actual usage resembles.
Running the test: instrumentation, data collection, and avoiding the mistakes that invalidate results
A pricing test is only as good as the usage data feeding it. If the metering layer batches events at the end of the billing cycle, the team loses visibility into what happened during the month. Without that, there's no way to explain why a customer hit an overage or churned before the cycle even closed.
This matters at a technical level that's easy to underestimate. Every AI API call generates at least two billable events, one for input tokens and one for output tokens, and a platform running high call volumes can throw off hundreds of thousands of billing events per hour. A batch system can't surface those consumption signals fast enough to make a pricing test actionable in real time.
A valid test needs specific things logged, not summarized: per-customer token consumption broken out by input and output separately, not folded into one total; consumption trajectory across the billing period, meaning when in the month a customer approaches its quota, not just whether it eventually crosses it; task-level cost attribution, so the team can see which features or workflows drive disproportionate spend; and retry and error token volume tracked on its own, since tokens burned on failed requests inflate apparent consumption without delivering any value. Left uncorrected, that waste contaminates the cost-per-outcome number the whole test depends on.
A structural lesson worth carrying over: production systems that separate metering, pricing logic, and contract management into distinct layers can change the pricing logic without touching the measurement code underneath. That separation is what lets a team iterate on price without breaking the instrumentation that tells them whether the new price is working.
A handful of mistakes reliably invalidate pricing tests, and they deserve naming instead of softening. Testing a new price against a usage baseline drawn from a different period is one, since API prices dropped roughly 80% in a single year and that baseline reflects a cost structure that no longer exists. Designing around the average customer is another, since the actual distribution of token use is heavy-tailed and a price built for the average fits almost no one. Running the test too short is a third mistake: usage patterns shift as customers learn the product, so a two-week window mostly captures early-adoption behavior rather than anything steady-state. And failing to control for model changes, when providers cut prices and adjust model behavior several times a year, means the test ends up conflating a pricing effect with a capability effect, and no one can say afterward which one actually moved the number.
None of this works if customers can't see their own spend as it happens. Research on consumption-based AI pricing finds that a large majority of IT leaders report unexpected charges under these models, and a test run without real-time usage dashboards and budget alerts will generate churn that looks like price sensitivity on the dashboard but is really just bill shock.
Reading the signals: what usage data tells you about where to move the price
Four patterns tend to show up again and again, and each points toward a specific move. High token consumption concentrated in a small cohort with low churn usually means the included quota sits too high, subsidizing heavy users at everyone else's expense. The fix is testing a lower quota paired with a steeper overage rate, or carving out a dedicated high-volume tier priced against what that cohort actually consumes.
Churn spikes right after customers first hit the overage rate tell a different story: the rate is landing as punitive relative to whatever value the product delivered that month. Worth testing here is either a lower overage rate outright, or a more visible in-product warning that flags customers before they cross the line rather than after. A large share of customers never approaching their included quota at all suggests a mismatch between the quota and the real use case. Either the product is being used more shallowly than it was designed for, or the included amount is generous enough that it never drives consumption revenue. Both readings argue for testing a smaller quota or a cheaper entry tier.
High retry or error token volume relative to successful-task volume is a signal to pause the pricing test altogether. It means cost-per-outcome is inflated by waste, and pricing a broken workflow precisely is worth far less than fixing the workflow first.
The input/output ratio itself doubles as a diagnostic. If a customer's output consumption grows faster than its input consumption over time, that customer is asking for longer and longer responses, a sign that the product's value sits in generation depth, which argues for pricing output tokens at a higher multiple relative to input. Agentic context growth works the same way. When agents accumulate context over many turns, input volume grows non-linearly per task, and for customers running long agent workflows, a per-task or per-outcome price extracts more revenue with less friction than a raw per-token number ever will.
Forecasting difficulty is, at bottom, a retention problem. A large share of CIOs cite cost forecasting as their single biggest challenge in deploying AI, and the pricing structure that tests best for retention tends to be the one customers can actually predict a month ahead of time. Worth testing directly: whether a capped overage option, a flat charge beyond quota instead of unlimited per-token overage, improves renewal among enterprise buyers specifically, since that's the segment most exposed to forecasting risk.
When to consider moving from per-token to outcome-based or hybrid outcome pricing
Teams treat outcome-based pricing as the obvious next step up from per-token, and that instinct is wrong more often than it's right. It works only when the outcome is measurable and consistently attributable to the product itself, such as a resolved support ticket, a completed draft that got reviewed and sent, or a data extraction confirmed accurate. It scales poorly against horizontal infrastructure, where "success" doesn't have one clean definition to price against, and forcing it there just trades one measurement problem for a worse one.
Vertical agent products got here first, for exactly that reason. Sierra, in customer support, charges per resolved ticket. Decagon offers both per-conversation pricing, its more popular option, and per-resolution pricing for support resolution work. Both models work because the outcome is observable and the customer is paying for the resolution itself, not for the number of tokens it took to get there. HubSpot's move to outcome-based pricing for Breeze AI agents in April 2026 is the clearest sign yet that this is moving out of vertical specialist territory and into mainstream SaaS. A team building agents against a measurable outcome should read that as validation, not as a novelty to watch from the sidelines.
Before making that move, a team needs its per-token test data in order first, and two things matter most: a stable average token cost per successful outcome, without which there's no reliable number to price the outcome against, and a clear read on the variance in token cost per outcome. High variance means some outcomes are quietly far more expensive to produce than others, and an outcome price that ignores that variance doesn't solve the problem, it just hides it. It's a margin hole waiting to surface later.
