You can't buy much in software today without running into credits. And with AI now inside almost every product, that's not changing. Credits are becoming the default monetization primitive for the AI era.

With credits, buyers commit a budget upfront, vendors collect cash before delivery, and incentives on both sides align around activation and value rather than transaction volume. Our analysis of our own customers is that the difference between credit pricing that works and credit pricing that feels like a trap almost always comes down to two questions buyers need answered before they feel confident:

1. How many credits do I need?

2. How am I tracking against them?

A lot of products answer neither. This post walks through how to answer both, and what has to be built first before either of them works.

Why credits work (when designed well)

Credits sit between subscriptions and pure pay-per-use, and they take the best from both.

A flat subscription is predictable but blunt. You pay a fixed fee and hope usage fits the bucket. That model powered the first wave of SaaS growth. Pure usage-based pricing is precise but anxiety-inducing. Every action costs something, and you're constantly watching the meter. You know the feeling if you've been in a taxi watching the fare tick up. You also know it if you've opened an AWS bill expecting one number and found another.

Credits offer a third path.

Because the buyer pre-purchased, the vendor's incentive shifts from "charge per transaction" to "make sure the buyer activates and gets value from what they already bought." That's a healthier dynamic for both sides.

Video game studios discovered what happens when you skip this design work: players stopped buying because the cost of the next action was always unknown. The fix wasn't cheaper microtransactions. It was making cost predictable before buyers committed. The same principle applies to B2B, especially once AI features are involved.

When to use credits (and when not to)

Credits aren't the right model for every product. They work best when you have high and variable compute costs, multiple actions or agents with different value profiles, or a product portfolio that needs a coherent pricing spine. They work poorly when variable costs are low, you have a single-use-case product, or different agents serve buyers with very different value perceptions (also check out Design choices in credit based pricing by Steven Forth).

The value model: build this first

Before you touch a calculator or a wallet, your credit prices need to connect to the value you deliver. This is what Steven Forth, who has written extensively on credit design, calls the most consequential upstream decision: unit design anchored to a value model.

If 1 credit costs $0.01 but produces $10 of value for the buyer, the mechanics can work fine while the pricing is structurally wrong. Buyers who feel they're getting less than they paid for will churn regardless of how transparent your wallet is.

Three questions to answer before setting credit prices

What actions do credits unlock? List every action a credit can trigger: document processed, API call made, workflow run, report generated. If you can't list them, your buyers certainly can't estimate what they need.

What's the measurable business outcome of each action? A meeting booked, a document drafted, an analyst hour saved. The goal is to connect a credit unit to a real-world result, not to an infrastructure cost like a token or an API call.

At what price does the buyer feel they're getting 5–10x value? Price per credit should reflect delivered value, not cost of compute. If the math gets you to $0.02 per credit but buyers are recovering $1.00 of value per credit, you're leaving money on the table and undervaluing your own product.

When the value model is right, the calculator becomes a sales tool. "For $200 of credits, companies like yours typically recover $2,000 in analyst time" is a different conversation from "500-credit pack, $200." The first sells itself. The second leaves the buyer doing their own math.

The credit calculator: confidence before commitment

Most pricing pages show you a credit tier and leave you to figure out whether it's enough. The ones that convert better show you a calculator.

A credit calculator is a pre-purchase tool. Before a buyer puts in a card, they should be able to estimate how many credits their use case requires and get a number they can reason about, not guess at. That means mapping real-world consumption to credit units, specifically:

• "If you process 50 documents per day, you'll use approximately X credits per month"

• "A team of 10 running 5 workflows per week burns through a 500-credit pack in about 6 weeks"

• "Projects like yours typically run 200–400 credits, depending on complexity"

Static vs. predictive calculators

Most companies build static calculators: you input your expected usage, it outputs a credit estimate. That's a solid start.

Companies with real usage data can go further. A predictive calculator pulls from observed consumption patterns across your customer base: "Customers in your segment with your use case average X credits per month." That requires data you won't have on day one, but it's worth building toward.

Connect the calculator to checkout

A well-designed calculator feeds directly into quote-to-cash. The estimate a buyer builds should connect to the package they purchase, with no gap between the number they modeled and the number in their cart. When a calculator does that, it stops being a UX courtesy and becomes a pre-sales conversion tool.

The credit wallet: visibility after purchase

Once someone has credits, they need to know how many they've used, how many remain, when they'll run out at their current pace, and when to top up before they're surprised by a hard stop. A balance counter isn't enough.

What a well-designed wallet includes

Usage breakdown by action. "You've used 180 credits" is better than nothing. "90 went to document analysis, 60 to exports, 30 to API calls" tells them something useful. Buyers understand their own patterns when they can see them broken out by what they actually did.

Pooling and rollover rules made visible. Can the power user on your team draw from a shared pool? Do unused credits carry to next month? These are policy and pricing design decisions, but surfacing them in the wallet makes them feel like features rather than fine print. Invisible policies feel like traps.

Alerts and guardrails before the wall. A notification at 20% remaining is the difference between a buyer who plans a top-up and a buyer who hits zero mid-task and files a support ticket. Set the threshold, send the alert, or pause consumption until they top up.

The post-purchase experience determines renewal

Together, these features move the buyer's relationship with credits from uncertain to managed. That's the product experience worth building, and the one that determines whether a buyer renews.

Do note that all credits should eventually expire for compliant revenue recognition. You have to make a policy legible and fair, but they have to expire. For example, a grace period (say, 5 days after a billing cycle ends) is a reasonable middle ground between hard expiry and indefinite rollover.

The full arc: from purchase to renewal

Before purchase: A calculator that maps the buyer's actual use case to estimated consumption. Specific, personalized where possible, honest about ranges. Feeds directly to checkout so the buyer purchases what they modeled.

At purchase: Credit packs in clear increments with the calculator's output pre-filled. The buyer knows what they're buying because they just modelled it.

During use: A wallet showing burn rate, breakdown by action, team pooling rules, and remaining balance. Alerts before zero.

At renewal: Usage history plus a line from credits consumed to value created. The renewal conversation becomes "do you want to top up or upgrade?" instead of "what did I even get for this?"

Why this is also good for you as the vendor

You collect cash upfront. You recognize revenue when credits are sold, not consumed. You carry float. And your incentive structure changes: instead of optimizing for transaction volume, you focus on activation, making sure buyers extract enough value from what they already bought to want more.

That's a more defensible position than chasing per-use revenue. The wallet, the calculator, the alerts, the value model: these aren't product polish. They're the architecture that makes credits compound over time into a real expansion motion.

Here's what to do today

If you're pricing AI features, start here and in this order:

1. Map credit actions to real-world usage. List every action credits unlock and estimate typical consumption per role or use case. Know what 100 credits means in a buyer's actual day before you publish a pricing page.

2. Build a value model. For each major action, estimate the business outcome it produces. Set your credit price so the buyer is getting obvious value. Aim for roughly 7x ROI on what they spend. If you can't articulate the outcome, you're not ready to price it.

3. Build the calculator. It forces you to articulate your usage mapping and gives you a conversion tool immediately. Connect it to checkout so the output populates the cart.

4. Build the wallet. Usage breakdown by action, pooling rules, rollover policy, alerts at 20% remaining. This is what determines whether a buyer renews.

5. Connect spend to outcomes at renewal. Use the wallet data to show the buyer what they got. "You processed 3,400 documents and recovered an estimated 40 hours of analyst time" is the renewal email that works. If you can show second-order value (deals closed, time saved downstream), even better.

Credits that buyers can predict are credits that buyers keep buying.