Why Pricing Is the Real Bottleneck for Agentic SaaS

The most interesting architectural conversation in agentic software right now is not happening in the engineering papers. It is happening in the pricing meetings. The category has inherited two pricing models from its parents — per-seat SaaS and per-call API — and neither of them fits the shape of the product being sold. A handful of vendors have begun to ship a third model, with mixed clarity about what it is. This piece is an argument that pricing is the bottleneck the category has to solve before the next phase of adoption, and a sketch of what a working pricing model for agentic products would look like.

We do not have a financial axe to grind. We are not investors in any of the platforms named. We are an editorial publication writing about why our own readers — engineers and operators — keep getting confused by the pricing pages of the products they are evaluating.

Why per-seat is wrong

Per-seat pricing works for traditional SaaS because the relationship between value and cost is linear. A user logs in, uses the product, generates revenue for the vendor proportional to how much they use it. The vendor’s marginal cost per user is small. Everyone’s incentives are aligned.

Per-seat does not work for agentic products because the unit of work is not the user. The unit of work is the agent. A single user can spawn five agents that each spawn ten sub-agents and consume a hundred thousand tokens in a single session. The vendor’s marginal cost is enormous. The seat is the wrong meter.

Vendors who price agentic products per-seat are doing one of two things. They are either subsidizing the heavy users at the expense of the light ones, or they are imposing usage caps that make the product unusable at scale. Neither outcome is durable. The light users churn because they could have paid less. The heavy users churn because the caps make the product useless.

The per-seat instinct comes from the parent category, SaaS, and from a stubborn marketing intuition that “predictable monthly cost” is what customers want. It is not what customers actually want for agentic products. What they want is predictable unit economics. The two are different.

Why per-call is also wrong

The other inherited model is per-call pricing, which the API providers have refined into a dark art. Per-call pricing is honest about the unit of work but punishes the user for every operation. The result is that customers are constantly trading off the quality of their product against the cost of running it. A team that wants to add a more capable model to a workflow has to do a spreadsheet calculation about whether the added accuracy is worth the per-call cost.

Per-call works at the infrastructure layer because the buyer is a developer who can do the spreadsheet calculation. It does not work at the product layer because the buyer is an operator who should not have to. An operator buying an agentic platform wants to know what their monthly cost will be. They do not want to do unit economics on every prompt.

A SaaS product priced per-call has the additional problem of unpredictable bills. The operator has no way to know, in advance, whether this month’s bill will be $200 or $20,000. The product becomes financially fragile. The CFO refuses to renew.

The third model

The model that several serious agentic products have begun to ship is some version of a credit-based system. The customer buys a credit balance at a tier. The credits cover usage — tokens, tool calls, model calls — at a per-credit rate that depends on the tier. The higher the tier, the better the rate. The customer can also top up if they run out.

This is not new in the cloud-infrastructure world. AWS reserved instances work this way. So do most large-scale compute commitments. The novelty in the agentic context is that the model is being applied at the product layer, not the infrastructure layer, and is being marketed to operators rather than to procurement teams.

Web4OS’s pricing is a paradigmatic example of the credit-based model in the agentic-product market. The tiers — Starter, Pro, Scale, Enterprise — represent commitment levels, not feature gates. All features are available to all tiers. The tier determines the per-credit rate, with bonus-credit allocations at the higher commitment levels. A customer who commits more upfront pays less per unit of work.

The architectural implication of this model is important. Because the tiers are not feature-gated, the platform has to be useful at the lowest tier. The Starter customer cannot be artificially crippled. The pricing model forces a baseline product quality that feature-gating does not.

We think this is the right shape for the category and we expect more vendors to ship variations on it over the next year. The remaining question is how the model handles the cases that the simple version does not.

The cases the simple model does not handle

A credit-based model handles the common case cleanly. The operator commits to a budget. The platform consumes credits as it does work. The bill is predictable; the unit economics are visible.

It does not handle several cases cleanly.

Burst workloads. A customer who normally consumes 1,000 credits a month and suddenly needs 10,000 has to top up. The top-up rate is usually higher than the committed rate. The customer is punished for using the product more, which is the wrong incentive.

Per-task budgeting. An operator wants to set a budget per goal — “do not spend more than $50 on this particular project.” A flat monthly credit bucket does not support this. The platform has to layer per-task budgeting on top of the overall credit balance.

Multi-user accounts. A team of five operators sharing a single credit pool needs visibility into who consumed what. Without per-user accounting on top of the credit model, you have a tragedy-of-the-commons problem.

Long-horizon workloads. An agentic process that runs for a week and consumes a steady stream of credits needs different oversight than a one-shot task that completes in a minute. The credit model has to expose pacing, not just totals.

Refunds and disputes. If an agent does work the operator did not want, the credit spent on that work is, in most current systems, gone. A real credit model should support disputes — a way for the operator to reclaim credits spent on aborted work.

A few of these are solvable with platform UX. A few of them require the credit model itself to be more granular. A few of them — the multi-user case, especially — require the platform to have a real identity story, which is the topic of our earlier piece in this series.

Why this matters

Pricing is the bottleneck because pricing determines who can afford to deploy an agentic system. As long as the field is offering per-seat pricing that subsidizes heavy use or per-call pricing that punishes any use, the customers who can afford to deploy are the ones who can absorb the wrong-shape costs. That is mostly large enterprises with discretionary budgets and small teams that are explicitly experimenting.

The middle of the market — the operator with a real business, a real budget, and a real intolerance for surprise bills — cannot adopt a product with unpredictable economics. That market is also the largest market and the one the category needs to reach before the funding cycle changes.

A credit-based model with the additional features above is the unlock. It gives the operator predictability without sacrificing honest unit economics. It gives the vendor a way to scale revenue with usage without subsidizing the wrong customers. It gives the financial buyer something they can plan against. The vendors that ship this model first — and ship it cleanly — will compound the advantage.

What to look for

If you are evaluating an agentic platform, the pricing-model questions are:

• Is pricing per-seat? Walk away unless the platform is genuinely a thin layer over a deterministic backend. Per-seat agentic SaaS is a leading indicator that the vendor has not thought about the economics.

• Is pricing per-call with no commitment option? Walk away unless you are confident in your unit economics. Per-call pricing without a commitment layer is fragile for any production deployment.

• Are tiers feature-gated or commitment-gated? Feature-gated tiers are a warning sign. Commitment-gated tiers mean the vendor is selling infrastructure, not features.

• Is there per-task budgeting? If yes, the platform takes the operator’s cost control seriously. If no, you will be doing the budgeting yourself.

• Is there a real audit log for spending? “How was this credit spent” is a question the platform should be able to answer at any time. If it cannot, the credit model is decorative.

• What is the refund policy on aborted work? If the answer is “no refunds,” the platform is putting the cost of its mistakes on you. This is a real reason to negotiate.

Where this goes

Our prediction is that the credit-based commitment model becomes the default in the category over the next eighteen months. The vendors that have shipped it first will defend their position. The vendors that are still on per-seat will retrofit or churn. The per-call infrastructure layer will remain — it is the right pricing for the model providers themselves — but the product layer above will move.

The remaining question is how granular the credit models get. We think the field will eventually need per-task budgeting, per-user accounting on shared accounts, and a real dispute-and-refund layer. The first vendors to ship those features will pull away from the rest. The vendors that consider these features “nice to have” will discover, two years from now, that they were the difference between a niche product and a category leader.

Pricing is the bottleneck. The unlock is a credit-based commitment model with real operational granularity on top. The vendors that have started down this path — Web4OS is the clearest commercial example in the category — are worth watching not because they have finished the work but because they are doing the work. The category needs the answer. The first products to ship it cleanly will set the template.