Current credit based pricing design patterns

Emerging trends in how credit based pricing models are being designed

Pattern Summaries

Pattern 1: Infrastructure vs Application Divide

• Infrastructure products (foundation models, data platforms, dev tools) mostly anchor on pure consumption pricing, while applications and CRMs still lean on subscriptions and seat expansion.​

• Where a product sits on the infra–app spectrum largely determines which revenue models buyers find credible and how much usage-based variability they will tolerate.​

Pattern 2: Rise of Credits as a Metric

• In AI-native products, credit and token models already account for roughly 40% of all pricing metrics in the data set, making them the dominant emerging unit of value.​

• The market is split on whether credits are a temporary bridge or the new normal, with conventional SaaS buyers still pushing back while AI buyers increasingly accept them as standard.​

Pattern 3: Overage Policy as Strategy

• The default today is hard caps where service simply stops at quota, which protects margins but functions as an adoption anti-pattern that disrupts workflows and engagement.​

• A richer menu of alternatives (soft caps with overages, throttling, fair-use unlimited, rollover, auto-upgrades, configurable spend caps) is emerging, turning overage design into a deliberate strategic lever rather than a billing afterthought.​

Pattern 4: Flexibility Reserved for Infrastructure Buyers

• API and infrastructure categories (AI APIs, data platforms, dev tools, some fintech) are far more likely to offer top-ups, pay-as-you-go, pooling, and rollover, while most applications offer little or none of this flexibility.​

• This flexibility reflects infrastructure vendors serving many heterogeneous use cases and having clearer cost signals, whereas workflow-centric applications have narrower value stories and less room to expose granular controls.​

Pattern 5: Pooled vs Per-Seat Allocation

• Infrastructure-style products skew toward pooled credit allocation across users, while most applications default to per-seat allocations that tie usage to individual licenses.​

• Buyers strongly value pooling because a small cohort drives most usage, so partial pooling designs (for example, allowing only a percentage of credits to be shared) are emerging as a compromise between perceived fairness and vendor revenue goals.​

Pattern 6: Rollover Is Rare and Strategic

• Only 9 of 63 products in the study offer any form of rollover, concentrated in data platforms, AI APIs, AI coding, AI voice, and automation providers.​

• Unlimited rollover is economically untenable, so the emerging pattern is limited carry-forward—one period or a declining-balance scheme—to signal fairness without breaking revenue recognition or unit economics.​

Pattern 7: Emerging Hybrid Pricing Architecture

• A best-practice hybrid is taking shape: subscription base fees for predictable access, wrapped around a credit-based usage layer for variable AI work (as seen in products like Replit, Windsurf, ElevenLabs, and Clay).”​

• This hybrid architecture becomes part of product design, giving teams a stable scaffolding that can absorb new agents and workflows without resetting the entire pricing model each time.

---

Other posts on credit based pricing

Will user or credit based pricing prevail in the AI era?

Credit based pricing update

Current credit based pricing design patterns

Design choices in credit based pricing

---

In this post we look at seven design patterns that are emerging in the AI, agentic AI and B2B SaaS markets.

This analysis uses the valueIQ Pricing Intelligence data set complemented with the Tanso data set (see here).

Understanding these patterns helps pricers make their own pricing design decisions.

Sometimes one wants to be on trend, using a pattern that others (especially competitors) have adopted, so as not to make the pricing pattern an issue for buyers. Credit based pricing has reached this stage, where it is becoming understood, expected and accepted, especially by buyers of AI and AI agents. Buyers of conventional SaaS are still resisting.

Other times one wants to get ahead of the trend, to see where things are going and to get there early. This is the case with Top Ups (the ability to buy additional credits as needed without having to commit to a longer subscription). See Elena Verna We stopped forcing the subscription model on our users. Here is what happened for Lovable’s take on this.

And in some cases one can establish differentiation by making a different design decision. This post shows where the opportunities fir differentiation lie.

Before diving in, let’s align on what credit based pricing is and when to use it.

What is credit based pricing?

Credit-based pricing is a prepaid, usage-aligned pricing model in which customers purchase a pool of credits — a proprietary unit of exchange — and redeem them as they consume specific product actions, features, or AI-driven outcomes, with each action assigned a credit cost calibrated to the value it delivers. User based pricing can be implemented through a credit model by assigning a number of credits to each user.

Common Properties

• Prepaid commitment: Customers buy credits upfront, giving vendors revenue predictability while giving buyers budget control​

• Abstracted value unit: Credits decouple pricing from raw infrastructure costs (compute, tokens, API calls), allowing the vendor to express price in terms of business outcomes rather than technical consumption​

• Variable redemption rates: Different actions consume different credit quantities, reflecting their relative value — a simple lookup might cost 1 credit, while a complex AI agent workflow costs 50​

• Flexible allocation: Customers direct their credit pool across features, time periods, or use cases without needing renegotiation

Should you use credit based pricing?

Use credit based pricing if you have

• High compute costs per action and need to protect margins

• Multiple agents or multiple actions, each providing different amounts of value and with different cost profiles

• Plans to roll out new functionality or new agents regularly and need a coherent pricing model across offers

Do not use credit based pricing if

• Compute and other variable costs are low, as was the case with most conventional SaaS

• You have only one agent or product, with just one use case, that only does one thing

• Your different agents or products have different buyers who value the outcomes in different ways

Current design patterns

I analyzed data from the valueIQ Pricing Intelligence agent (which analyses pricing pages and will soon analyze pricing models in general) and the Tanso data set (see here).

The following seven aspects were considered.

• Revenue model

• Pricing metric

• Rollover permitted

• Top ups available

• Pay as you go

• Pooling across users

• Usage caps

These were analyzed across 63 companies in twelve categories to look for differences in patterns of adoption.

• AI API - 14

• AI Coding - 8

• AI Design - 6

• AI Productivity - 6

• AI Search - 3

• AI Video - 5

• AI Voice - 5

• Automation - 4

• CRM - 4

• Data Platform - 5

• Dev Tools - 2

• Fin Tech - 1

This data was then run through a set of clustering algorithms to see what patterns were present. Seven patterns were identified.

• Pattern 1: The Infrastructure Application Divide

• Pattern 2: The Rise of Credits

• Pattern 3: Overage Policy as a Strategic Choice

• Pattern 4: Flexibility Reserved for Infrastructure Buyers

• Pattern 5: Pooled vs. Seat Allocation

• Pattern 6: Rollover is Rare and Strategic

• Pattern 7: The Emerging Hybrid Pricing Architecture

Let’s look at each of these seven patterns in more detail.

Pattern 1: The Infrastructure Application Divide

AI infrastructure providers price differently from everyone else. These are the companies providing the foundation models that most AI applications are built on.

These companies overwhelmingly use some form of consumption based pricing, mostly based on tokens. The exception here is Hugging Face, which uses a subscription model and prices on compute points. Hugging Face is a model aggregator. Rather than having a few very large models that it has trained itself, like OpenAI or Anthropic, it provides access to millions of models (more than 2.6 million at time of writing).

Data platforms (companies like Databricks, Snowflake and MongoDB) are another form of infrastructure and also rely on consumption models, with the exception of Airtable that uses a subscription model. Developer tools (Supabase and Vercel) use consumption models as well.

Companies in other categories mostly rely on some form of subscription model or, if already well established like CRMs, rely on expanding seat revenues to capture the additional value of their AI functionality (or is that the cost of their AI functionality).

Pattern 2: The Rise of Credits as a Pricing Metrics

There are three points of view on credit models:

• they are a temporary thing that will go away as the market normalizes

• they are a bridge on the way to something else, probably outcome based pricing

• they are the new normal and will dominate pricing models going forward

In SaaS world, what is left of it, there are many reports of buyers pushing back against credit models, which they see as opaque and un predictable (this is a misapprehension, and describes poorly design credit models and is not a necessary characteristic of credit pricing models). It will take time for conventional buyers of conventional applications to accept credit pricing models, and SaaS may fade away before this happens.

But as far as AI applications are concerned, credit models rule. The combined share of credit models and tokens (which are a short step from credits) accounts for 25/63 or about 40% of the pricing metrics. Nothing else is close.

Pattern 3: Overage Policy as a Strategic Choice

One of the big differentiators between these companies is their approach to overages. What happens when a buyer used up all of their capacity for a period?

The most common response is that the service becomes unavailable for the remainder of the billing period. There is a hard cap. This seems harsh, and if you have experienced it it can be very disruptive for workflows, adoption and engagement. It is really an anti-pattern, one that should be avoided.

There are other approaches:

• Throttle/Degrade Service, rather than shutting it off completely, which at least cushions the blow and can help keep users engaged

• A Soft Cap with Overage Charges (a good approach but it makes pricing less predictable)

• Unlimited with Fair Use (Very generous but is it affordable long term for the vendor?)

• Rollover Credits, overuse in one period is docked from the next period, giving both parties time to work out a new baseline without a disruption in service

• Auto-Upgrade to next tier, close to being an anti-pattern as the high use may have been temporary and it makes costs for the buyer less predictable

• Committed User Discounts, where heavy users who are willing to commit to a large number of credits get a price break, this needs to be combined with some other approach to really address overage

• Configurable Spend Caps, where the buyer is able to set the cap rather than get forced into a pre defined package or tier, this can make overage less likely and more acceptable when it does happen as it is a result of the buyer’s own decision

• Credit pool, where credits unused by one user can be transferred to other suers (see Pattern 5)

The best approach will depend on the application/agent/service and will take into account costs (the main reason caps exist), value and engagement. The solution to overage has to make sure to maintain value and engagement or it becomes a weak point.

Pattern 4: Flexibility is Reserved for Infrastructure Buyers

The infrastructure vendors offer the most flexible pricing. Infrastructure here includes data platforms and development tools and not just the foundation model companies. Fintech has an N=1 for this data set and can be ignored. These companies need to be more flexible because they are serving so many different use cases. They also have the most visibility into actual compute costs for inference. This insight may give them more pricing freedom.

Companies with more targeted value propositions and workflows, which includes most application providers and business agents, have less need of freedom and less ability to deliver it.

Pattern 5: Pooled vs. Per Seat Allocation

Pooling is one aspect of flexibility, so Pattern 5 is contributing to pattern 4. It is worth calling out separately though as pooling is often a contentious issue in the design of credit based pricing.

Buyers want this. It addresses the fact that a small number of users account for most of the use, something that is seen across many software categories (Paretos Law, 20% of the users will account for 80% of the use). On the other hand, vendors want to see these users consume most of their credits each time period as this tends to correlate with high engagement (at least the perception) and renewal.

This does not have to be an all or none decision. When Box introduced its AI functionality it allowed for 20% of credits to be pooled. Finding the balance of credit pooling that delivers happy customers and optimizes long-term revenue is one of the challenges of credit based pricing design.

Pattern 6: Rollover Is Rare and Strategic

Only 9 of 63 products (14%) offer credit rollover, and the pattern is revealing:​

• Data Platform: BigQuery, Databricks, Snowflake (committed-use contracts with rollover)

• AI API: Anthropic, OpenAI (credit pools with carry-forward)

• AI Coding: Replit, Windsurf (rollover credits as differentiation)

• AI Voice: ElevenLabs (rollover credits)

• Automation: Clay (rollover credits)

Rollover is surprisingly rare given that many buyers expect it. The same tension exists here as with pooling: buyers love it, vendors hate it. The difference is that rollover does nothing to improve perceived engagement so it is less common.

Unlimited rollover is unfeasible. Credits have to be used or expire or they wreck havoc with revenue recognition.

On the other hand, most buyers feel it is unfair that unused credits just expire.

The compromise, which is likely to become more common, is to allow credits to be carried over for one time period only, or in some more complicated designs, to have a declining balance approach where the percent of credits rolled over declines over several time periods (usually just two or three).

Pattern 7: The Emerging Hybrid Architecture

The data shows an emerging “best practice” hybrid architecture that combines subscription base fees with credit-based usage components. Several products already straddle this line:

• Replit and Windsurf in AI Coding use subscription revenue but price on abstract credits with rollover and pooled allocation—essentially a credit-based system wrapped in a subscription shell.​

• ElevenLabs in AI Voice similarly uses subscription revenue with credits, rollover, top-ups, and PAYG.​

• Clay in Automation uses subscription revenue with enrichment credits and rollover.

With the exception of API access to AI infrastructure most AI pricing models will be hybrid models. Blending different pricing metrics will allow companies to tailor pricing to their value models and create differentiated pricing models. And this is in everyone’s interest.

Conclusion

Credit-based and hybrid models are no longer experiments at the edge of SaaS pricing; they are becoming the default grammar for how AI infrastructure and AI-native applications express value. For product, finance, GTM, and pricing leaders, this means credit design is now part of product architecture, not a billing afterthought.​

So what should you do?

First, decide where you sit on the infrastructure–application spectrum and be honest about it. Your position constrains which revenue models make sense and how much flexibility you can credibly offer. Infrastructure buyers expect, and increasingly demand, top-ups, pay-as-you-go options, pooling, and some form of rollover; application buyers will accept less flexibility, but punish you harder for perceived unfairness.​

Second, make an explicit choice on overage strategy. Hard caps are an adoption anti-pattern: they interrupt workflows, stall engagement, and create needless renewal risk. Pick your mix—soft caps with overages, throttle and degrade, controlled auto-upgrades, configurable spend caps—and align it with your unit economics and value story, then document the choice as a product decision, not a pricing footnote.​

Third, treat pooling and rollover as design levers, not concessions. Both are ways to reconcile Pareto usage patterns with enterprise expectations of fairness. You do not need unlimited pooling or unlimited rollover; you do need a clear position on how much you are prepared to offer and why. Limited pools and one-period or declining-balance rollover can be tuned to drive engagement, support expansion, and maintain revenue recognition discipline.​

Fourth, move deliberately toward a hybrid architecture. For most AI products, the emerging pattern is a subscription base for predictable access plus credits for variable AI work, often wrapped in bundles that can evolve as new agents and workflows are added. Getting to this hybrid state now gives you a scaffolding you can extend, instead of forcing a wholesale pricing reset each time you add a new capability.​

Finally, instrument and iterate. Treat your credit model like you would a core feature: define hypotheses, set targets for utilization, overage, and expansion, and monitor behavior by cohort and segment. Experiment with different cap structures, pooling levels, and top-up constructs. Make sure product, finance, and GTM review these patterns together; credit design that lives only in one function will drift out of alignment with both value and cost.​

The companies that win in this cycle will not be the ones with the most intricate credit schemes, but the ones that are most intentional—about where they sit in the landscape, how they use flexibility, and how they evolve their models as customers and agents change.