**Steven Forth** is a principle at Ibbaka and valueIQ. Connect on LinkedIn

TL;DR (Too Long; Didn’t Read)

Credits are emerging as the dominant way to price generative AI in B2B SaaS because they flex to many use cases, evolve with rapid feature releases, and connect specific actions to both value and cost.

The core design choice is granularity: cost-based models price many discrete actions (often tokens) to tightly track compute and third‑party expenses, while value-based models group actions into higher-level outcomes along the customer’s value path.
A value-first approach prices only the actions that truly create customer outcomes (for example, completing a deal or downloading a value-based sales deck), avoiding charges for exploratory or administrative interactions that don’t directly drive value.
Effective calibration pegs credits and price levels to expected usage, willingness to pay, and competitive benchmarks, then refines them with real user behaviour and feedback in the market.
For multi-product or multi-agent portfolios, keeping a single price per credit and allowing credits to be fungible simplifies buying and enables cross-sell, even if it means underpricing some higher-value use cases.
Guardrails are essential: identify high-cost actions (such as generation-intensive workflows or third-party presentation rendering) and make them explicit credit events to prevent margin erosion from heavy or abusive usage.

Credit pricing models are emerging as the most common way to price generative AI applications. They have a number of advantages over pricing based on specific pricing metrics.

Credit-based pricing is attractive when …

A wide variety of use cases are supported, and it is not clear which users will rely on which use case
New functionality is being brought to market quickly
Actions can be connected to value
There are high costs associated with some actions, and lower costs for others

Before we go further, what is a credit-based pricing model?

Credit-Based Pricing Definition: A credit-based pricing model is a pricing system where users purchase a bucket of credits in advance, which are then consumed as they execute actions or receive results from a product or AI agent. Each action a user takes has a predefined credit cost, allowing for alignment between the value delivered to the customer and the price paid for that value.

There are many things to consider when designing a credit-based pricing model.

Some of the key issues are:

Unit design - what is the unit of credit
Entitlement management
Credit pooling and rollover
Credit gifting
Credit scaling
Hybrid pricing with credit models

See A guide to the design of credit-based pricing for AI agents

One needs to begin with unit design, and this is where the question of the granularity of pricing models comes up.

Unit design - credit granularity

Unit design is the part of the credit model design that addresses how many different actions should be priced. There is no general consensus here. Your design will depend on why you are using credit-based pricing and what your buyers are willing to accept.

Credits are more granular when the goal is to track costs, it is less granular when the goal is to track value.

Cost-based pricing tends to be more granular

Many credit-based pricing models are designed to align price with costs. Compute costs are a significant component of variable costs for generative AI applications. They are generally measured in tokens used (input tokens, output tokens, in some cases reasoning tokens), and some credit-based pricing models are even referred to as token-based pricing (especially by the foundation models themselves).

When one’s primary goal is to track costs, it makes sense to get granular and to price every credit consumed.

This is how everything from foundation models to vibe coding is priced. And cost-based approaches often flow through to the applications built on or with these models. But this is not the only, or the best approach.

Value-based pricing aligns credits with the actions that deliver value

When the credit-based pricing is value-based rather than cost-based, the trend is to define and price fewer actions. Rather than charge credits for every prompt sent to the LLM (Large Language Model), the cost-based approach only charges for actions that are associated with value.

Not every action contributes to value. Some actions are purely administrative, others are taken only when things go wrong, and many interactions with chatbots and agents are close to random. That is not a bad thing. We are often in explore mode when using AIs, even with AI agents, and if we have to pay for every exploration, we will explore less, and probably get less value. The pricing model should not discourage those things that will lead to value down the road.

The other reason to aggregate many actions together into one thing that gets charged is that value is generally the result of multiple actions and not just one. This series of actions is often referred to as a value path.

Value Path Definition: A 'value path' is a series or sequence of steps or actions taken by a user (or several users) that results in value for the customer or end-user. The concept is central to understanding how businesses, products, or services deliver value, and is used to design customer journeys, pricing models, and value delivery mechanisms.

A true value-based approach to credit pricing design will only charge for value path completion.

Let’s look at a concrete example from the valueIQ.ai Sales Coach. This agent is used to generate a Tom Nagle EVE (Economic Value Estimation) style value model and then to use this model to organize sales conversations. It helps sales teams focus the buying conversation on value.

The valueIQ sales coach calls many subagents and has a chat interface. One deal can consume 100s of tokens depending on the complexity of the value model, the depth of the conversation and how many sales presentations are generated. Beta testing suggests a 12X range in token consumption from deal to deal.

valueIQ uses a credit-based pricing model.

To design this model, we had to answer three questions:

What actions should consume credits
How many credits for each action
Should the price per credit for valueIQ Sales Coach align with the pricing of credits for other valueIQ agents?

What actions should consume credits?

This question provoked a lot of internal debate.

Should we charge for generating a value model?

No. The value model by itself does not create value.

Should we charge per prompt in the coaching chat?

No. We want people to interact, and prompts could be a result of frustration and other non-value-adding conversations.

Should we charge for calls to external databases?

No. Just getting the data is no guarantee of value.

The key actions that align with value are (i) creating a deal and (ii) downloading a sales presentation. And those are the actions that consume credits.

How many credits for each action?

Here, we calibrated against two things. The number of deals we expect a typical user to create each month and the price of competitive alternatives. Our own value model shows that we create about 5X the value of the competitive alternatives (the main value drivers being probability of winning the deal and the average contract value). This is the power that a value model brings to the sales process, and valueIQ is the only agent capable of generating a value model.

We tested per-credit pricing based on the 5X claim but ran into market resistance. People were skeptical of the claims for a new agent without a track record. So we dialled this back to about 2X the price of our nearest competitive alternative

We also had to calibrate the number of credits used to create a deal with the number of credits used to generate a value-based sales deck. This also caused a lot of debate. Should we weigh this on the deal or on the presentations? One could argue (and some did) that the sales presentation was the end result, what would lead to the sale, and that was what we should charge for.

But we looked at what users are actually doing and interviewed them about how they are getting value. It was the value model and the conversations with the sales coach that really engaged people and that they valued. The sales presentations are a nice-to-have. After exploring a lot of different approaches, we ended up charging 400 credits to create a deal and 20 credits to download a presentation. We assume that on average each deal will have three presentations, so the ratio of deals to presentations is 400 to 60 or 20 to 3.

Once we knew the value, the competitive alternatives, willingness to pay, and the ratio of credits for each action, it was easy to calculate the initial price. But …

Alignment with other valueIQ agents

valueIQ is taking a family of agents to market. In parallel to the Sales Coach, we are launching a Pricing Analyst. We went through a similar thought process for the Pricing Analyst, but there was a gotcha here. We want the price per credit to be the same across all of our agents. Down the road, we plan to have credits fungible so that they can be used across all of our agents. This triggered another round of calibration. It took a lot of math and exploration to find the right balance across these two agents (there are actually four agents planned, a Deal Pricing agent and a Pricing Model Design agent will be added at some point in 2026. This did lead to some compromises. We are likely underpricing the Pricing Analyst agent credits relative to willingness to pay. We think, though, that the simplicity of having one price per credit across all agents makes up for this.

Did costs come into this?

What about costs? There are significant compute costs that come with an agent like valueIQ Sales Coach. The value and price are high enough that this is not a big issue, but it did motivate the decision to charge credits each time a sales presentation is downloaded. We use a third-party application for the presentation design, so there is an incremental cost for each download. We wanted to protect ourselves from a user who decided to generate and download a large number of presentations.

Conclusions and lessons learned

Designing the granularity of credit-based pricing models for generative AI applications is a balancing act between cost alignment, buyer behaviour, and value delivery. Align your credit pricing units not just to track costs but to prioritize and charge for the actions that truly drive value to the customer (V2C). This means focusing on value paths — sequences of actions that culminate in measurable outcomes — rather than charging for every single interaction, which can stifle exploration and reduce overall value realization.

To implement this effectively:

Start with clear definitions of which user actions capture value and merit credit consumption.
Calibrate credit amounts against market alternatives and willingness to pay, adjusting based on real user feedback and behaviour.
Consider the long-term vision for credit fungibility across product families to maintain simplicity for customers while balancing unit economics.
Protect against cost exposures from high-consumption behaviours by intelligently setting credit prices for costly actions, especially with third-party integrations.

By taking a value-first approach to credit pricing unit design, you’ll better align pricing with both your economic realities and the value your customers receive, enabling scalable success in the rapidly evolving AI-powered SaaS landscape. Start reviewing your pricing models through this lens today to unlock growth while fostering customer satisfaction and loyalty.

Navigating the new pricing environment brought by AI agents? Contact us @ info@ibbaka.com

How granular should credit pricing models get?