Credit based pricing update
Trends in credit based pricing patterns
TL; DR (Too Long Didn’t Read Style Summary)
Credit-based pricing may become the default “operating system” for AI-native and agentic products in 2026, absorbing many user-based models rather than just sitting on the side as a billing gimmick.
Do not default to credits; only move to a credit-based model if you have high variable/compute costs per action, multiple agents or actions with different value and cost profiles, and a roadmap of new agents/features that need a coherent, extensible pricing spine.
Avoid credits if your costs are low, you effectively have a single use case, or different agents/products sell to different buyers with different value stories; in these cases, simpler seat/site/use-case pricing will usually win.
If you adopt credits, consider designing a hybrid model: combine credits with per-seat, per-site, or per-use-case packaging (Salesforce Agentforce and Lovable show how to mix and, in Lovable’s case, even dissolve seat-based pricing into shared credits).
Treat credit design as product design: pick a granularity (per action, process/value path, output, or outcome) that maps cleanly to value, build a value model to quantify that value, and set a single price per credit across agents so credits are fully fungible.
Use consumption design levers deliberately: choose an overage pattern (hard cap, soft cap with overage, fair-use “unlimited,” rollover, auto-upgrade, credit pool, throttling, spend caps) that fits your brand and user experience instead of blindly defaulting to hard caps.
Make top-ups, limited rollovers, and pooling intentional: enable top-ups for flexibility, allow bounded rollovers (more generous at higher tiers, never beyond 12 months), and design pooling rules to drive engagement while controlling credit overhang.
Build a simple usage estimator early so customers can predict credit burn and avoid mid-stream credit shocks; use historical cohorts plus key inputs (e.g., number of projects or engagements) to generate forward-looking consumption guidance.
Turn credits into growth levers, not just meters: award habit-forming daily or weekly credits, grant bonus credits for high-value actions (e.g., supplying critical data), reward referrals and sharing of outputs, and experiment with gift credits to seed communities.
One of my predictions for 2026 is that “Credit based pricing becomes the dominant model and absorbs user based pricing (pay for users with credits)”.
This is a bit of an edgy prediction so I will be coming back to it from time to time over the course of the year and updating the community on what I am seeing. The focus will be on adoption trends, emerging best practices and design patterns.
In this post I cover four key themes.
What are people saying about credit based pricing?
Should you consider a credit based pricing model?
Credit based pricing growth hacks
What are the design decisions for credit based pricing?
What are people saying about credit based pricing?
Credit based pricing remains a divisive topic.
For some experts, like Mark Stiving, credit based pricing is not a pricing model but a billing system. See. Credits: The Bridge Between AI Uncertainty and Value Clarity.
Many other people see credit based pricing as a bridge to something else. Pricing and Go-to-Market leaders like Kyle Poyar from Growth Unhinged (personal communication) and Marcos Rivera from Pricing I/O (see below) hold this view.
Others, such as Brandon Hickie at LinkedIn, see credit based pricing as an adaptive framework for future pricing models (see The New Currency: How Credit-Based Pricing Accelerates SaaS Growth).
Meanwhile, adoption of credit based pricing continues to grow.
Rob Litterst writing on Kyle Poyar’s Growth Unhinged is seeing rapid growth in the number of companies adopting credit based pricing models.
Tanso, an emerging player in the payments space, led by Kat Laszlo, has done us all a great service by pulling together some data on how 63 different companies are implementing credit based pricing. See Mechanics Reference.
Whether credit based pricing is a bridge to some new approach to pricing, perhaps outcomes based, or will be the defining framework for pricing going forward is an open question. Share your thoughts in this poll.
Should you consider a credit based pricing model?
Credit based pricing models are flexible, adaptive and can be aligned with value. But they are more complex than other approaches, work is needed to make them predictable, standard patterns and best practices are still emerging. Do not default to credit based pricing. You need a compelling reason to do so.
Most credit based pricing models are actually hybrid models combining credits with some other pricing metric, most frequently per user pricing, but also site based, or use case based approaches.
The exception is API pricing, where true credit based pricing is becoming common.
Salesforce Agentforce is an example of how per user (per seat) and credits can be mixed and matched.
Lovable on the other hand, is dissolving user based pricing by providing credits that can be shared across an unlimited number of users.
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
If you you answered ‘Yes’ to one or more of the questions in either list, and ‘No’ to all the questions in the other list, then your decision is easy.
But if you had a ‘Yes’ answer in the Use credit based pricing list of questions and another ‘Yes’ answer in the Do not use credit based pricing list your decision will be more difficult. Beware of the added complexity of credit based pricing and only. use it when you can build a compelling use case.
Credit based pricing growth hacks
Over the past few months we have seen some very clever growth hacks to use with credit based pricing.
Reward actions you want users to take
Award additional credits when people do something you want to encourage. Lovable is a great example of this. You get 5 daily credits just for visiting Lovable. This gives you a reason, and a reward, for building the habit of coming to the site every day.
This idea can be applied to many actions beyond site visits. If there is some action that you know will lead to successful engagement and good outcomes for the user you may want to incent it with bonus credits. For example, if there is some critical piece of information that the user can provide that will make your agent more effective, consider rewarding that information with credits, but make sure that the users understand why this is in their interest.
Encourage sharing
The best advertising is word of mouth and viral agents will be among the most successful.
Many applications now give credits for introducing new users. This one is a no brainer and many companies are already doing this.
Another approach is to give credits for sharing outputs (this helps more people see how valuable your outputs are). The way some news sites let you share an article is a primitive example of this. One can get much fancier than this though, and create shareable outputs and then give credits for sharing them.
Gift credits are another smart way to build community. Lovable has gift cards available that you can buy and give to people (I bought a Lovable gift card for my son.)
The general idea is to give people credits to reward them for doing what you want them to do and for what is in their own best interest.
Predict usage (build an estimator)
Nothing is more frustrating to a user than running out of credits mid course. Even if you make it easy to top up with additional credits (by up grading a subscription or through a one time purchase) it is still annoying and can disrupt flow. Do your best to make sure this does not happen.
One way to do this with with a simple prediction model that looks at past usage of similar users and then predicts usage based on this. These models are easy to build in your favourite vibe coding app.
The problem here is that the past does not always predict the future and that user’s plans change. I am currently building a prediction model to help pricing consultants estimate their future use of the valueIQ Pricing Intelligence agent. This model will help consultants estimate future credit consumption based on how many pricing engagements they are working on each month.
What are the design decisions for credit based pricing?
The design decisions for credit based pricing models are coming into focus.
The most important decisions are to decide on the granularity of the credits and on how to map credit consumption to value.
Granularity
The finest level of granularity is per token. This may make sense for API access to the big foundation models (Anthropic, Cohere, DeepSeek, Google Gemini, Mistral, OpenAI, SpaceX Grok, etc.) but it is too granular for most of us.
The other levels of granularity to consider are
Per action
Per process or value path (a series of actions that results in something of value to a user)
Per output
Per outcome
Map to Value
Choose the level of granularity that is easiest to map to value. To do this you will need a value model (a system of equations that estimates the value provided to a customer).The valueIQ.ai Value Sales Agent will actually generate a value model for you and customize it for a specific customer.
Set One Price Per Credit
Once you have done this it is fairly easy to set a price per credit. The price per credit should be exactly the same across all of your agents and applications. This makes the credits fungible so that your buyers can mix and match. You can change the price by adjusting how credits are consumed and leave the price per credit alone. This is the key to the great flexibility of credit based pricing systems.
Once you have figured out the granularity of your credits, understand the value per credit, and set a price per credit, you still have design decisions to make.
Overage
What happens when users exceed the credit limits in their plan?
There are many design options. Here is a list with the distribution of choices from the Tanso 63.
Hard Cap Service Halts 43%
Soft Cap with Overage Charge 22%
Unlimited with Fair Use 8%
Rollover and charge to Next Billing Period 6%
Auto Upgrade to Next Tier 6%
Credit Pool with Prepaid Balance 5%
Throttle / Degrade Service 3%
Configurable Spend Caps 3%
Committed Use Discounts 3%
Decision on overages are core the brand image and can have a big impact on the user experience. Hard caps (the most popular design choice at this point) can give a poor user experience. Consider one of the other options.
Top ups
One answer to overage is to permit top ups. This is the purchase of a certain number of credits either for the billing period or for perpetual use (if you choose perpetual be careful of the revenue recognition implications.
Just over 60% of the Tanso 63 allow for top ups and this is emerging as a best practice.
Lovable recently introduced top-ups. Head of Growth Elena Verna described the research behind the decision in a post “We stopped forcing the subscription model on our users. Here is what happened.”
Roll overs
Can users roll over unused credits to the next period?
Only about 14 % of the Tanso 63 allow rollovers.
Roll overs are almost never allowed for free plans. The best practice is to allow some level of roll overs and to become more generous as one goes from tier to tier. But in no case should roll overs be for more than 12 months as this causes severe problems with revenue recognition and your CFO will be very upset.
Pooling
Pooling is the ability of users to share credits.
About 40% of the Tanso 63 allow some form of pooling or credit sharing.
Pooling does not need to be absolute. When Box introduced its AI functionality it allowed up to 20%. of unused credits to be transfered to users who had run up against credit limits.
On the other hand, apps like Lovable and the valueIQ.ai agents allow for unlimited pooling to promote engagement and to reduce credit overhang (unused credits) at the end of the billing period.
Pay as you go
An alternative to a subscription or commitment to buying a certain number of credits per period is the pay as you go model. You buy credits as you use them.
Almost 40% of the Tanso 63 allow this as an option.
Conclusion
Credit‑based pricing is not a thought experiment anymore; it is becoming the operating system for how AI‑native products will be bought and sold. If you are building or scaling an agentic product, now is the moment to decide whether you will treat credits as a bolt‑on billing mechanic, or as the core of how you package value, protect margins, and create room for expansion.
In the next quarter, pick one of the design decisions in this post—granularity, overage handling, rollovers, pooling, or Pay as you Go—and run a concrete experiment with real customers. Build a simple usage estimator, test one or two growth hacks (habit‑forming credits, sharing, or gifting), and pressure‑test whether your current model is a bridge to something better or the foundation you want to scale on.
Then bring your data, questions, and examples back to this community. We will refine these patterns together and, if my prediction is right, define the next generation of SaaS pricing before it solidifies around us.
Bonus: Clustering the Tanso Data
I ran the 63 companies identified by Tanso through a clustering algorithm and came up with the following categories.
Seat subscription with hard feature caps
Seat subscription with “fair-use unlimited”
Usage platforms with soft caps, overage, and Pay as you Go
Credit‑pool hybrids (often with carry/rollover)
Seat‑expansion CRM with auto‑upgrades
1) Seat subscription with hard feature caps
Core pattern: Per‑seat subscription, with a fixed allowance of usage (messages, minutes, searches, credits, pages, etc.) and a hard cap where service stops or is heavily throttled at the limit; no overage billing.
Design intent: Predictable spend for buyers, simple mental model (“X per user per month”), and caps as a price fence to push upgrades rather than monetize every marginal unit.
Common levers: No rollover; PayGo usually “No”; top‑ups mainly when the metric is already framed as “credits” (AI design/video/voice tools).
Examples:
AI productivity/search: ChatGPT Plus, Claude Pro, Kagi, Perplexity, Mem, Otter.ai, You.com.
AI design/video/voice: Adobe Firefly, Canva, Framer, HeyGen, Descript, Murf.ai, Pika, Runway, Synthesia, Uizard.
Automation/ops: Make, n8n (subscription with hard execution caps), Zapier.
2) Seat subscription with “fair‑use unlimited”
Core pattern: Per‑seat subscription where usage is described as “unlimited” but governed by a fair‑use policy, so usage is not a primary billing driver but a guardrail against abuse.
Design intent: Anchor value in user access and collaboration, minimize friction from meters, and keep packaging simple; usage is monitored but not monetized linearly.
Common levers: No overage, no top‑ups, no rollover; upgrades are based on feature sets or seat counts, not usage levels.
Examples:
Collaboration/productivity: Figma, Notion AI, Grammarly, Tabnine, Sourcegraph Cody (for some plans), often GitHub Copilot’s positioning.
CRM seat access component: mirrors broader SaaS patterns where “unlimited” is scoped by plan and policy rather than hard counters.
3) Usage platforms with soft caps, overage, and Pay as you Go
Core pattern: Primary revenue from usage‑based billing (tokens, compute credits, queries, transactions, messages), with soft caps, clear per‑unit rates, and ongoing PayGo—usage continues past any nominal limit and is billed as overage.
Design intent: Align price tightly to consumption and cost structure, support high elasticity, and enable “land small, scale usage” motions; often paired with volume discounts and enterprise commitments.
Common levers:
PayGo = Yes; explicit per‑unit pricing.
Overage = Yes; soft caps plus alerts.
Budget/spend caps and alerts to control bill shock; commitment discounts and minimums for larger customers.
Examples:
AI APIs: AI21 Labs, Amazon Bedrock, Anthropic (Claude API), Azure OpenAI, Cohere, Fireworks AI, Google Gemini API, Groq, Mistral AI, OpenAI, Together AI, Twilio.
Data/Dev/infra: BigQuery, Databricks, Snowflake, MongoDB Atlas, Stripe, Supabase, Vercel, Replicate, Hugging Face.
4) Credit‑pool hybrids (often with carry/rollover)
Core pattern: Customers buy a pool of credits (sometimes tied to a base subscription or commitment), shared across a team or organization; credits are burned down with usage and may carry over across periods or have longer validity.
Design intent: Combine subscription predictability with usage flexibility; make large pre‑purchases palatable by avoiding “use it or lose it,” and let teams share capacity dynamically.
Common levers:
Rollover or long‑lived credits;
Top‑ups mid‑cycle;
Often pooled across seats or workspaces.
Examples (from your list):
Data/infra with commitments that effectively act as credit pools: Snowflake, Databricks, BigQuery.
AI/API or app products explicitly offering rollover credits/pools: Clay, ElevenLabs, Replit, Windsurf (Codeium), Anthropic (credit pool / prepaid), OpenAI prepaid balances.
5) Seat‑expansion CRM with auto‑upgrades
Core pattern: Revenue driven by number of seats and/or records/contacts, with tiered plans; hitting plan limits automatically pushes the customer to a higher tier rather than charging usage overage.
Design intent: Make expansion intuitive (more users, more contacts → higher tier), keep billing simple for business buyers, and use tiers as the main value/monetization axis.
Common levers:
Auto‑upgrade to next tier when object limits are exceeded.
No PayGo, no top‑ups, no rollover; usage controls are framed as tier boundaries instead of metered charges.
Examples:
CRM: HubSpot, Salesforce, Pipedrive, Zoho CRM.
Some patterns echo into other seat‑expansion‑driven tools where plan tiers gate usage/features rather than per‑unit billing.