AI Monetization: Why Price Became Part of UX

Imagine you are working on an AI feature for a SaaS product. The user types a prompt, gets a result, and it is not quite what they wanted. They change the prompt, run it again, and again. On the fourth attempt the result is finally good.

From a product design point of view we see a problem: it took the user four attempts to finish one task. From the business point of view, the company paid for four generations and only one of them created value. Now imagine that each attempt also spends credits from their subscription. They are paying not only for the result but for the system's failed attempts.

So who should pay for those attempts? Should the user know what a generation costs before running it? How do we keep the company from losing money on heavy AI use without making people afraid of every button?

I think this is where one of the most interesting problems in product design right now begins. AI features change SaaS economics: every request, generation or agent run can add cost. A traditional subscription is not always enough, so companies are experimenting with credits, limits, usage-based and outcome-based pricing. And each of those models shapes behaviour: how often people use the product, how willing they are to pay, how much they trust it.

“

AI monetization is not just a way to send an invoice. It is a set of rules that shapes user behaviour and goes straight into the economics of the product.

Which is why designers should take part in building it, rather than styling a pricing page that has already been decided.

AI changed the products, and the price of every interaction

In traditional SaaS, one more action from a user often has a small marginal cost. In AI products it is different: generations, large contexts, heavier models and autonomous agent runs all consume resources. According to ICONIQ's State of AI 2026, the average gross margin of AI products in their sample was 45% for 2025, with 53% forecast for 2026. For traditional SaaS, Bessemer puts the benchmark at roughly 80–90%. These are different samples and different business models, so the comparison shows the scale of the challenge, not a universal law.

And falling token prices do not guarantee a cheaper feature. Cheaper models make longer prompts, more verification passes and more complex agent chains possible. A company has to count not the price of one API call but the cost of a finished task. Product decisions feed straight into that: whether a result can be refined without a full regeneration, whether an expensive model runs by default, whether the user knows what is adding to the bill.

What is the user actually paying for?

The first question I would put to a team before they build a credit balance: what unit of value is the person buying? Tokens and API calls are convenient units for accounting for infrastructure. But nobody comes to a product for 100,000 tokens. They want to build a deck, find a bug, process documents, resolve a customer ticket or run a workflow.

That difference matters, because the unit you charge for shapes behaviour. If someone pays per generation, every retry eats their balance. If they pay for a successful outcome, the company's interests and the customer's move closer together: it is now in the product's interest to finish the job in fewer attempts. Intercom Fin, for instance, charges per resolved conversation, and Salesforce Agentforce meters individual agent actions through Flex Credits.

Outcome-based pricing does not suit everyone, though. “Document generated” does not mean the document is good; “agent action completed” does not mean the person got what they needed. So the designer, together with product, engineering and the business, has to decide what counts as the end of the journey, how quality is measured, and which failures the system should absorb at its own expense.

The psychology of credits: when the price stops meaning anything

Credits look like a simple answer. One pack can cover several AI features, even though generating an image, analysing a document and running an agent cost very different amounts. But what does 2,000 credits mean to a user? Is that a lot? How many actual tasks is it? Does the price change with the model, or with the number of attempts?

This is not only information architecture, it is behavioural economics. Work on the pain of paying, mental accounting and the preference for flat rates helps explain why people dislike an uncertain bill. In Raghubir and Srivastava's experiments (2008), less transparent payment methods were associated with higher spending, and clear cost information weakened the effect. That research is not about AI credits, but the mechanism is useful for thinking about product UX.

When an action costs “150 credits”, the user may not feel its real price. When we show “150 credits ≈ $1.50”, the balance afterwards and roughly how many results are left, they get more control. At the same time there is no need to put a confirmation in front of every cheap action: too much attention to payment creates friction. Match the level of transparency to the size of the risk.

“

Credits can simplify paying. They should not hide what something actually costs.

Designing monetization that does not break the experience

Here the designer's work starts with the journey, not with the pricing page. Cost has to be legible at the point where someone decides to start, continue or stop. For an expensive generation or an agent run it helps to show an estimate before the action, in units people understand: money, credits, and roughly how many results. If an exact price is impossible, an honest range with a ceiling beats invented precision.

Afterwards the product should help them understand what it actually cost, especially when that differs from the estimate: the agent spent extra on verification, or the generation needed a larger model. That builds predictable use rather than leaving someone to guess why the balance moved.

The difference between an alert and a limit matters just as much. A warning at 80% of budget does not mean spending stops at 100%. People need clear modes: notify me, ask permission to go over, fall back to a cheaper mode automatically, or stop expensive operations. And the system has to say plainly which rule is in force right now.

What happens when the balance hits zero? The bad version interrupts a complex task halfway and shows an error. The better one warns in advance, lets the work be saved, explains what the free or cheaper mode can still do, and offers a top-up without forcing it. If the user has already published something, say separately whether it keeps working once credits run out.

In B2B products, remember the payer and the user are often different people. The employee wants to finish the task; the administrator wants to know what the team is spending, who is spending most, whether a budget can be set and how extra resources get approved. So the product needs more than a balance indicator and an Upgrade button: it needs its own journeys for control, reporting and permissions.

All of this can be tested at prototype stage. Give people a task: estimate what three generations will cost, set a monthly budget, and work out what happens when the limit is reached. If they cannot answer without a hint, a visually clean billing UI has not solved the problem yet.

How design can lower AI costs

The most interesting part, to me, begins where we stop treating monetization as a payment screen. If someone regenerates a whole document over and over to change one paragraph, that is a usability problem, a quality problem and a cost problem at once. Being able to edit in place, keep versions, clarify the brief first, or run a cheaper model for simple operations can change the economics of the journey.

It matters not to confuse the cost of a call with the cost of a success. Say Model A costs $0.20 per attempt and succeeds on 80% of independent attempts. The expected cost of a successful result is then $0.20 / 0.80 = $0.25. Model B is cheaper at $0.15 per attempt, but succeeds only half the time, so the expected cost of success is $0.15 / 0.50 = $0.30. We cut the price of a single call by 25% and ended up with a more expensive successful result. This is a simplified model that assumes independent attempts and a fixed probability of success; a real system has to be measured on its actual journeys.

That is why I would have design teams watch more than the number of generations or the level of AI use: the share of retries, time to a useful result, how much of the output gets edited, and the cost of a task actually finished. These are the measures where design and unit economics stop being separate things.

How to tell whether the monetization works

Even if people buy credits, that does not mean we built a good system. A high top-up rate can mean strong demand, or that the base plan is badly short. A lot of AI calls can mean engagement, or endless attempts to fix a result. And revenue from overages is not necessarily compatible with long-term trust.

So I would look at several groups of measures together:

Segments deserve their own look. Someone running 20 requests a month and someone running hundreds of agent operations can be on the same plan with completely different costs. An illustrative example: at $0.13 per task, 20 tasks cost $2.60, 400 cost $52, and 2,000 cost $260 in variable AI spend alone. These are not any company's real rates; they explain why an average can hide the risk.

Before scaling a model I would test a few ordinary journeys: does the person understand what they are paying for; can they predict the spend; do they know how to stop going over budget; do they think being charged for failed attempts is fair? Conversion data needs these behavioural and qualitative signals alongside it. And as far as possible, test a price change and an interface change separately; otherwise the cause of the result is hard to read.

Which monetization model should you choose?

There is no single right answer. The model has to account for how value is created, how predictable the cost is, and how easily a customer can judge their own usage. Growth Unhinged, surveying over 240 companies, reported that the share of hybrid models rose from 27% to 41% in the year to 2025. That is a significant trend, but not a reason to pick hybrid for every product.

As a practical start for many SaaS features, consider a small included amount of AI use, clear rules for how it is spent, and an obvious path to paying for more. But that is a hypothesis to test against real segments, willingness to pay and actual costs, not a template to apply.

What this changes for a product designer

I do not think a designer should set the price per token or own the financial model. But they should be in the conversation long before the task arrives as “draw the credit balance”. A designer is the one who can ask the questions that tie behaviour to economics: what does the user call a result, how do they perceive the cost, why do they keep regenerating, what happens at the limit, and is the charge clear without anyone explaining it.

In AI products, designing an interaction increasingly means designing the conditions under which value appears and gets paid for. How we shape the journey affects the success rate, the number of model calls, the margin, loyalty, and whether the person wants to keep going.

“

Good AI design does not optimise the number of generations. It optimises the value of each successful result, for the user and for the business.

Perhaps the next conversation about an AI feature should not start with which model to wire up or how many credits to hand out a month, but with something simpler: what job are we helping someone finish, what does it cost, and why would they pay for it? Only then is it worth deciding whether we need credits at all.