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

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

The opportunity with credit-based pricing is to align value with actions and charge for the actions that create value.

TL:DR

What Are Credit-Based Pricing Models

  • Definition: Users buy a bucket of credits that they consume as they execute actions or get results from AI agents

  • Prevalence: 13% of AI agent companies use credit-based pricing as a primary metric, but momentum is growing rapidly

  • Per-user pricing still dominates at 35%, but credit models are becoming the trend

Why Companies Are Switching to Credits

  • Cost alignment: Better match pricing with actual token consumption and operational costs

  • Flexible adoption: Buyers can commit to credits without knowing exact usage patterns upfront

  • Granular pricing: Allows charging for specific valuable actions rather than broad access

  • Predictability: When designed well, it provides predictable costs for both buyers and vendors

Key Design Principles

  • Value: Ensure credits align with economic value delivered to customers

  • Cost: Map credit consumption to actual delivery costs (especially token usage)

  • Transparency: Provide clear visibility into credit consumption and remaining balances

  • Predictability: Help buyers understand credit requirements in advance

  • Fungibility: Allow credits to be moved between users, actions, and time periods

Critical Design Elements

  • Unit design: Define what one credit enables and align with the smallest valuable action

  • Entitlement management: Determine who can use credits for what actions

  • Credit pooling: Allow sharing credits across team members (80/20 rule applies)

  • Rollover policies: Handle unused credits (typically aligned with commitment period)

  • Credit gifting: Enable users to transfer credits to encourage viral adoption

Common Hybrid Models

  • Tiered subscriptions + credits: Like Cursor, Perplexity AI, Lovable AI

  • Per-feature + credits: Like Netlify, combining infrastructure credits with feature pricing

  • Output-based credits: Like Copy.ai, charging based on content generation

Design Gotchas

  • Scaling: Generally avoid volume discounts since AI costs don't decrease with scale

  • Expiration: All credits must eventually expire for proper revenue recognition

  • Cost management: Internal token consumption can be 50-90% of total usage

  • Billing complexity: Ensure billing systems can handle credit assignment and tracking

Step-by-Step Implementation

  1. Create a granular value model for different agent actions

  2. Develop a cost model tracking token consumption per action

  3. Find the lowest common denominator for the credit unit

  4. Assign credit costs to all actions

  5. Design packages for common use cases (include enough for 3+ attempts)

  6. Enable additional credit purchases

  7. Consider hybrid pricing combinations

  8. Define policies for scaling, rollover, pooling, and change management


Key Insights from Smaller Companies

Simplified Credit Models: Smaller companies often use simpler 1-credit-per-interaction models (like Lovable) rather than complex token calculations.

Developer Tool Challenges: Companies like V0 and Cursor faced significant user backlash when transitioning from unlimited to credit-based models, highlighting the importance of change management.

Rapid Growth Enablement: Credit-based models allow startups like Cursor and Perplexity to scale quickly while maintaining unit economics.

Transparent Pricing: Successful smaller companies emphasize pricing transparency and predictability over complex tiered structures.

Market Validation: The widespread adoption of hybrid credit models by smaller companies validates this approach as standard practice, reducing buyer education requirements.

Hybrid credit-based pricing is becoming the default approach across AI companies of all sizes, from early-stage startups to unicorns, as they balance growth, profitability, and customer value delivery.


One of the fastest-growing pricing models for AI and AI agents is credit-based pricing. You know, when you buy a bucket of credits that you consume as you execute actions or get results.

Kyle Poyar called this out in a post on Sept. 3, 2025 Why everyone’s switching to AI credits in which he says that:

Credit-based models are uniquely suited to accommodate this complexity. Customers see a pool of usage that feels relatively straightforward (“50 credits per month”). Vendors, meanwhile, can easily adapt credit pricing to monetize newer, higher-value actions, navigate evolving LLM costs, and nudge customer behavior in a way that’s win-win.

Credit-based models also allow companies to include some AI usage “for free” for existing customers or in free plans, and they let customers decide exactly how they want to use those credits.

Snowflake is one of the classic examples of credit-based pricing. Basically, you buy credits and use them to pay for services. Snowflake offers its levels of service and four levels of pricing. The price credits are fenced by the types of service you can use to buy with the credit, where the credits can be used, and other variables.

Snowflake pricing page on Sept. 1, 2025.

Basic structure of credit-based pricing

The basic structure of a credit model is pretty simple.

  • The user takes an action

  • The action has a value and a cost

  • The user pays for the action with credits

The basic structure of credit pricing systems, Ibbaka Sept. 7, 2025

These models are often combined with other pricing models to create hybrid credit models: credits can be assigned to users or teams or used across the entire organization. There can be different types of credits (input tokens and output tokens, storage tokens, and bandwidth tokens). The credits can be put into packages with different rights.

Credits can be packaged into tiered pricing systems, Ibbaka Sept. 7, 2025

Sounds simple, but there are a number of gotchas and basic rules to the design of credit based pricing systems that it is useful to understand as a buyer and as a vendor.

Prevalence of Credit Based Models

Ibbaka used its Pricing Analysis Agent to analyse pricing models of agents listed in the AI Agents Ecosystem. Pricing models for 800 agents were extracted and analyzed on Sept. 6, 2025. We identified the primary pricing metric and secondary pricing metric on pricing pages.

Primary pricing metrics (rounded)

  • Per User 35%

  • Per agent 10%

  • Per action 9%

  • Per outcome 3%

  • Per credit 13% but trending up

  • Contact sales 30% (no pricing page or pricing page says contact sales)

Many (about 50%) of these companies have additional pricing metrics buried in their pages. Hybrid pricing is the most common pricing model, but this is not very informative, as the question is a hybrid of what? Ibbaka will publish more analysis as the Pricing Analyst Agent matures, and this agent will eventually be offered through valueIQ.ai.

Note, even in fall 2025, for AI Agents, Per User is the single most common pricing metric by a large margin.

Why Credit-Based Models are Being Adopted

Per user pricing metrics may be the most common, but the momentum is with credit-based pricing. All of the APIs for foundation models use credit-based pricing, and all of the hugely popular vibe coding apps have credit-based pricing (Bolt, Cursor, Lovable, Replit V0).

There are three reasons for this:

  • Better align price with cost

  • Flexible adoption

  • More granular pricing

  • Predictability

The opportunity with credit-based pricing is to align action with value and to charge for the actions that create value.

Align price with cost

Cost remains a real concern for agent vendors. There was hope that token prices would follow some version of Moore’s law and decline rapidly. This seems to be happening. But at the same time, token consumption is growing exponentially. This is driven in part by the growing complexity of agents, but more so by the reliance on inference for advanced functionality. Inference consumes not just input and output tokens but tokens at intermediate steps, where the model is generating and consuming tokens on its own. Ibbaka’s testing finds that this internal token consumption accounts for anywhere from 50% to 90% of total tokens, and the trend is up.

There is pressure on business teams to make sure that agents are covering their costs as they are used. The easiest way to do this is to map credit consumption and price to token use and cost. Most of today’s credit-based pricing models are fancy versions of cost-based pricing.

Flexible adoption

Cost management is just one reason people are moving to credit-based models. These models make it easy for buyers who are not sure what they will use to commit to a bucket of agents and then fill that bucket selectively.

Some companies are bringing a lot of agents to market. The pricing software vendor Pricefx has more than 120 (see Agent strategies at the major pricing software vendors), revenue intelligence platform Gong has at least 20 (see Agent strategies at revenue intelligence platforms). Buyers are not sure which agents they will use and how often. Credit systems give them flexibility with commitment, and commitment leads to predictability.

Granular pricing

One result of the agent economy is the unbundling of functionality to the granular level at which agents can take meaningful action. A CRM or ERP is not an action, but unbundled, they are a collection of agents and all of the user-facing functionality, plus much of the integration can be delivered by agents. Most users will never use most of the functionality, and by focusing on the key actions, their meaning and effect, agent vendors believe they can deliver more value than the underlying application, which becomes a fancy (often expensive) database. See Jakob Nielsen: No more user interface?

Good agents do one thing exceptionally well and are able to talk with other agents to get larger things done. This unbundling and then rebundling of functionality breaks conventional pricing models. Credit-based pricing is the solution.

Predictability

One common criticism of credit-based models is that the amount to be paid and the revenues are unpredictable. This is not a characteristic of credit-based pricing models. It is the result of poorly designed models that fail to bring together the interests of the buyer and vendor.

The opportunity with credit-based pricing is to align value with actions and to charge for the actions that create value.

Design Goals for Credit-Based Models

The design of credit-based pricing models includes some new aspects that pricing designers are not always familiar with. A good design integrates five key aspects to pricing.

Credit based pricing is an integrative system based on five design goals: Value, Cost, Transparency, Predictability, Fungibility. Ibbaka, September 7, 2025.

Price is defined as credits purchased (committed to).

  • Value - the economic value of the solution

  • Cost - the cost of delivering the system

  • Transparency - visibility into the number of credits consumed, remaining, that will be consumed by each action (before the action is taken), that can be shared or rolled over

  • Predictability - the number of credits required (to succeed in the use case) and committed to can be understood in advance

  • Fungibility - credits can easily be moved from one action (or agent) to another, between users, across time periods

Value x Cost: Make sure the Value > Price > Cost is maintained across scale

Value x Transparency: Communicate the value of actions and explain why a credit is priced as it is

Value x Predictability: Be able to predict the value of actions. This can be hard, but it is the key to long-term success: build prediction models for value

Value x Fungibility: A credit should be roughly the same value no matter how it is used

Cost x Transparency: Make all the rules that impact the cost of a credit clear to a buyer

Cost x Predictability: Provide tools that will help buyers know how many credits they will need and how much these will cost (the easiest way to do this is to map to use cases and let the buyer tell you how many times they are likely to execute on that use case)

Cost x Fungibility: Vendors need to have flexible implementations that allow them to move compute where it is needed

Transparency x Predictability: Provide forward-looking visibility into how credits will be consumed so customers can anticipate usage

Transparency x Fungibility: Ensure customers can easily see how credits are moved across users, actions, or time periods, creating confidence in the fairness of transfer rules and avoiding hidden restrictions or even a lack of visibility rights

Fungibility x Cost: Balance the flexibility of credits with the vendor’s operational efficiency. While credits must be interchangeable to the customer, the provider needs to design back-end systems that manage costs intelligently, ensuring that fungibility does not erode margins or create arbitrage opportunities

The Design of Credit-Based Pricing Models

This is a rapidly developing field, and new ideas and best practices emerge every month. The ideas here are no more than an initial sketch. Ibbaka plans to prepare a Credit Model Design Cookbook in the near future. Check out the resource section or sign up to the log to get notified.

The things to consider in credit model design are:

  1. Unit design

  2. Entitlement management

  3. Credit pooling and rollover

  4. Credit gifting

  5. Credit scaling

  6. Hybrid pricing with credit models

Unit Design - aligning value and cost with price (or ‘getting granular’)

This is the foundation of credit-based pricing. It is also the most difficult part of the design. It needs to answer three questions.

  1. What does a credit let you do?

  2. How much value does the action of consuming a credit deliver to the buyer?

  3. How much does it cost the vendor to execute the action (generally, this asks how many tokens on average will be consumed)

The first thing to do is to figure out the lowest common denominator. What is the smallest action that creates value? What is the smallest action that has a variable cost?

If the unit of value is larger than the unit of cost (probable), use the smallest unit

If the unit of value is smaller than the unit of cost (unlikely for an AI agent), use the unit of cost to decide what is included in the minimum credit (this is likely some multiple of tokens).

Actions will be charged some number of tokens (try to avoid what Lovable sometimes does, which is to charge fractions of a token).

Entitlement Management - who gets what

Can any token be used by any user for any action?

The answer will be ‘yes’ for any fully fungible design.

There may be situations where you want to limit certain types of users to certain types of action. This is common in hybrid pricing where there are different types of users. It can turn into a complication and a barrier to adoption, so in general, avoid this.

Quite often, different users will buy or be assigned different numbers of credits. One’s billing system needs to be able to handle the assignment, consumption, and reporting of credits (how many have been consumed, how many remain, how many are available for crediting or rollover). Have a frank conversation with your billing system before you design your credit-based pricing system, and make sure you both understand what is possible. It may be necessary to change vendors.

Credit Pooling (can credits be shared?) rollover (what happens when credits aren’t used up)

In most cases, not all users will use their credits in the allotted time period. This means you need to have policies for pooling and rollover.

Most usage follows the 80:20 rule (also known as the Pareto principle). Twenty percent of the users will consume eighty percent of the credits. Plan for this.

Will you allow credits to be transferred from one user to another? Will this be automatic or managed? At what point in the billing cycle does this happen?

Open pooling is emerging as the standard as it supports the key value proposition of fungibility.

Rollover refers to taking credits not used in one period and then applying them to the next period. If an organization purchases 100 credits per month and only uses 80, what happens to the remaining 20 credits?

One possibility is that they disappear. Use it or lose it. Many buyers see this as punitive and not in line with fungibility. Most credit plans allow for some rollover, though not always 100%.

The questions to answer are:

  1. What percent of credits are rolled over?

  2. How long can they then be rolled over for?

There is a trend to aligning the length of the rollover period to the length of the commitment. If a buyer only commits for a month, the credits only roll over for a month; if they buy a quarterly plan, the credits roll over for a quarter, and if they make an annual commitment, any unused credits can be used in the following year.

Rolled over credits should not accumulate (there is no compounding here). Credits can only be rolled over once, and then they expire.

At some point, all credits must expire. Credits that do not expire are a disaster for revenue recognition and should not be possible.

Credit Gifting - can one user transfer their credits to another

One recent trend is to allow users to make the decision on who gets to use their credits, and to make it possible to gift credits to other users or new users. One can design a model in which when one buys 100 credits, one gets another ten that can be gifted to new users. This is meant to encourage user communities and viral adoption.

Credit gifting is a growth hack that many AI agent companies will use as they fight for recognition and adoption.

Credit Scaling - how does the price per credit change with scale?

One contentious issue in the design of credit models is whether the price per credit should go down with volume. If I buy more credits, should the price per credit decline?

In general, the answer is no. Value per credit tends to go up, not down, with scale, and in agenticAI, costs generally do not go down as the number of tokens consumed goes up.

In reality, large buyers often have pricing power and expect some sort of scale discount. A modest discount may be unavoidable. But the underlying costs are real, so there needs to be a hard ceiling on any scale discounts.

Hybrid Pricing with the credit-based model

Credit pricing models are often combined with other pricing metrics. The most common? You guessed it, per user. But many other possibilities exist. One is looking for a combination of pricing metrics that best aligns price with value and ensures that costs are covered. When some significant part of value is driven by something other than direct agent use, it makes sense to have one or two additional pricing metrics (hopefully no more than two, plus the credit model).

Some examples…

  • Cursor: Tiered User Subscriptions + Usage Credits

  • Perplexity AI: Tiered User Subscriptions + API Credits

  • Lovable AI: Tiered User Subscriptions + Credit Allocation

  • Netlify: Per Feature Pricing + Credit-Based Infrastructure

  • Copy.ai: Output-Based Credits

Step-by-Step Guide to Credit-Based Pricing

Here are the key steps in designing a credit-based pricing model

  1. Generate a value model (the model has to be granular enough to capture the value of the different actions taken by the agent)

  2. Have a cost model (know how many tokens each action consumes)

  3. Find the lowest common denominator for the value and costs, which becomes the unit credit

  4. Assign credit counts for all actions and anything else that creates value and generates costs

  5. Design packages for common use cases, make sure there are enough credits in the package to execute the use case at least once, but more commonly at least three times (give the user the opportunity to learn and to get hooked)

  6. Provide a way to buy additional credits (often one buys multiples of credits)

  7. Consider hybrid pricing (credits can be combined with other pricing metrics to create more predictable pricing that better tracks cost and value - not all costs are driven by token consumption)

  8. Decide on key policies

    1. Scaling -Are there discounts for the consumption of large numbers of credits? (watch your costs)

    2. Rollover - What happens to unused credits? They must expire at some point or you will mess up accounting and revenue recognition.

    3. Pooling and transfer - Can credits be pooled or transferred from one user to another? What are the mechanisms that make this possible?

    4. Adjustments and change management - You will end up changing your design. What rules will you impose on yourself and share with your customers on how you can change the design?

Later this month, we will provide a concrete example of the design of a credit-based pricing model.

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

Previous
Previous

Four perspectives on credit based pricing for AI agents

Next
Next

Competition for data control will push API prices higher