A Guide to the Design of Credit-Based Pricing for AI Agents

One of the fastest-growing pricing models for AI and AI agents is credit-based pricing — 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 — noting that credit-based models are uniquely suited to accommodate the complexity of agent usage. Customers see a relatively straightforward pool of usage; vendors can adapt credit pricing to monetize newer, higher-value actions, navigate evolving LLM costs, and nudge customer behavior in a way that's win-win.

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

The basic structure of a credit model is conceptually simple: a user takes an action, the action has a value and a cost, and the user pays for the action with credits. But the design of those underlying components — and the policies around them — is where complexity lives.

These models are often combined with other pricing models to create hybrid credit architectures: 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, bandwidth tokens. And credits can be put into packages with different rights and rollover rules.

Sounds simple, but there are a number of gotchas and basic rules to the design of credit-based pricing systems that it's worth understanding as a buyer and as a vendor.

We used our 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 — identifying the primary and secondary pricing metric on pricing pages.

Per-user pricing may be the most common, but all 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 four reasons for this.

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 — and this does seem to be happening. But at the same time, token consumption is growing exponentially, driven by the growing complexity of agents and especially by 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. Our testing finds that this internal token consumption accounts for anywhere from 50% to 90% of total tokens — and the trend is up. The easiest way to make sure agents are covering their costs is to map credit consumption and price to token use and cost. Most of today's credit-based pricing models are sophisticated versions of cost-based pricing.

Cost management is just one reason for the move to credit-based models. These models make it easy for buyers who aren't sure what they'll use to commit to a bucket and then fill it selectively. Some companies are bringing large numbers of agents to market — Pricefx has more than 120 (see Agent strategies at the major pricing software vendors), 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.

One result of the agent economy is the unbundling of functionality to the granular level at which agents can take meaningful action. Good agents do one thing exceptionally well and can talk with other agents to get larger things done. This unbundling and rebundling of functionality breaks conventional pricing models. Credit-based pricing is the solution — see Jakob Nielsen: No more user interface?

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 per se. It is the result of poorly designed models that fail to bring together the interests of buyer and vendor.

Good credit model design integrates five key aspects. Price is defined as credits purchased (committed to).

This is a rapidly developing field, and new ideas and best practices emerge every month. The things to consider in credit model design are: unit design, entitlement management, credit pooling and rollover, credit gifting, credit scaling, and hybrid pricing combinations.

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

The first task is to figure out the lowest common denominator: the smallest action that creates value, and 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. Actions will be charged some number of credits — try to avoid charging fractions of a credit.

Can any credit be used by any user for any action? The answer is 'yes' for a fully fungible design. There may be situations where you want to limit certain users to certain actions — common in hybrid pricing with different user types. This can create complications and adoption barriers, so in general: avoid it. Your billing system needs to handle assignment, consumption, and reporting of credits before you finalize any design. Have a frank conversation with your billing vendor first; it may be necessary to change vendors.

In most cases, not all users will exhaust their credits in the allotted period. This requires policies for pooling and rollover.

Most usage follows the 80:20 rule: 20% of users will consume 80% of credits. Plan for this. Open pooling — where credits can be freely transferred between users — is emerging as the standard as it supports the core value proposition of fungibility.

For rollover, the trend is to align the length of the rollover period with the length of the commitment. Monthly commitment: credits roll over for one month. Quarterly plan: one quarter of rollover. Annual commitment: unused credits carry forward one year. Rolled-over credits should not accumulate — they can only roll over once, then expire. At some point, all credits must expire. Credits that never expire are a disaster for revenue recognition.

A recent trend allows users to gift credits to other users or new users. A model in which buying 100 credits gets you 10 more to gift to new users encourages user communities and viral adoption. Credit gifting is a growth hack that many AI agent companies will use as they fight for recognition.

Should the price per credit go down with volume? In general, the answer is no. Value per credit tends to go up — not down — with scale, and in agentic AI, costs generally don't decrease as token consumption increases. In practice, large buyers often have pricing power and expect some discount. A modest discount may be unavoidable. But underlying costs are real, so there needs to be a hard ceiling on any scale discounts.

Credit pricing models are often combined with other pricing metrics. 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 alongside the credit model.

Here are the key steps in designing a credit-based pricing model. This is an initial sketch — more detailed design work for each step follows from the principles above.

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.