Credit-based pricing means the customer buys a balance of credits in advance and the product draws it down as work gets done, with each kind of work costing a set number of credits. It is now one of the most common ways to price AI products. The mechanism is simple. Whether it is fair to the customer depends on five choices that most guides list as options: when the customer pays, whether features are gated, whether the rate moves, what happens to unused credits, and what a credit is explained in.
We price Aimdoc in prepaid credits, and we made all five choices in August 2026 when we moved off flat plans. This post is what we chose and why, from the vendor's side of the table. It is written for software companies deciding how to price AI that does work for their customers.
The short version of what we learned: when the AI does the work, the customer cannot predict how much work a request will take, so credit-based pricing is only honest if the customer sets the ceiling, the rate never moves under them, and a credit is explained in units of work they recognize. The question we hear most on calls is not "how much is a credit?" It is "what will this cost for a customer like mine?" A credit model that cannot answer that reads as a black box, and buyers say so.
What the credit pricing guides agree on
The pages that rank for this topic are consistent, and mostly right. Schematic's explainer defines a credit as "a unit of activity inside the product" and walks through the design steps: define what one credit represents, map each action to a credit cost, package credits into subscriptions or prepaid balances, decide on overages, and set rollover or expiry rules. OpenMeter's glossary calls it "the self-service version of pre-purchased commitments," and notes both its strength (it "establishes hard spending limits for customers") and its main risk: "Running out of credits can cause outages."
Steven Forth's review of credit pricing design patterns, published in February 2026, looked at 63 companies and found credit and token metrics behind about 40% of their pricing metrics. "Nothing else is close," he writes. Only 9 of the 63 offered rollover, and hard caps were the default.
The objections are also well mapped. Ibbaka's five objections to credit based pricing lists complexity, lack of predictability, buyer unfamiliarity, revenue recognition, and the charge that credits are cost-plus in disguise, quoting Mark Stiving: "Most credit-based pricing is a fancy form of cost-plus pricing."
What these pages mostly assume is that the customer decides how credits get spent. Schematic says it directly: "customers decide how many credits to spend depending on the task." That holds when a person clicks a button that costs three credits. It holds less well when an AI agent decides how many steps a job takes.
Why AI work makes credits harder to read
Anthropic's engineering team reported, in how it built its multi-agent research system, that "agents typically use about 4× more tokens than chat interactions," and "multi-agent systems use about 15× more tokens than chats." On their research benchmark, "token usage by itself explains 80% of the variance" in performance.
Put those together and the problem is plain. The same request can take very different amounts of work depending on how the agent is designed and how hard the case is. A customer who asks for one thing cannot know in advance whether it is a small job or a large one. The vendor knows more than the customer does about what the work will cost, which is the opposite of the situation credit models were designed for.
Cursor learned what happens when that gap is handled badly. In its post clarifying its pricing, the company explained it had "moved from request-based pricing to $20 of included usage on Pro," admitted the changes "were not communicated clearly, and we take full responsibility," and offered to "refund any unexpected charges" from the previous three weeks. The model was reasonable. The customer could not see what a unit meant until the bill arrived.
The five choices we made, and why
When we moved Aimdoc to credits, the trigger was usage. Our first in-product deployments showed that the best sign of value was customers using the AI a lot, and that a few long sessions on top models cost far more than a typical one. A flat plan made heavy use our problem. A per-action price would have made it a surprise for the customer. Prepaid credits with a ceiling the customer controls sat between the two. Here is how we set it up.
1. Prepaid, not billed in arrears. Customers choose a monthly amount and get that many credits up front. It behaves like a subscription: the customer knows the bill before the month starts, can move the amount up or down, and buys a top-up if they run hot. On our pricing page, upgrades apply immediately and downgrades take effect at renewal. We chose this because the surprise bill is the one thing a buyer of AI work fears most, and billing after the fact is how surprise bills happen.
2. Usage-gated, not feature-gated. Every capability is on every plan. Heavier work, like voice, uses more credits. There is no "upgrade to unlock email" step. We chose this because a feature gate makes the customer decide whether a capability is worth it before they have seen it work, and with AI they cannot know that in advance. A usage gate lets them turn it on, watch the meter, and turn it off.
3. A fixed rate, with bonus credits instead of discounts. The per-credit rate does not drop at higher amounts. Larger commitments get bonus credits instead, from 5% at $500 a month to 20% at $5,000 and above. A credit means the same thing on every plan, so a customer comparing last month to this month, or one team to another, is comparing like with like.
Credits per $100 on Aimdoc's Scale plan, computed from the amounts on aimdoc.ai/pricing (for example, $500 buys 52,500 credits and $5,000 buys 600,000).
4. Monthly credits expire; top-ups do not. Unused monthly credits do not roll over. One-time top-up packs never expire. That puts us with the majority in Forth's sample. Our reasoning: the monthly amount is capacity for a month of work, like a subscription. A top-up is money the customer paid for specific credits, so it should last until it is used.
5. Credits explained as units of work, not tokens. Our pricing page says credits pay for the AI's work: conversations, setting up new customers, and ongoing work on every job it owns. We do not ask customers to reason about tokens or model prices, because they do not buy tokens. They buy work.
Where we are still honest about the gap
The fifth choice is the one buyers push on, and they are right to.
A software company evaluating us this week asked us to explain credits at scale, and said outright that they know AI credits can be a black box. Then they did what every good buyer does. They skipped the credit math and asked for a monthly price for a customer of a given size. That is the real question, and a credit model that can only answer in credits has not answered it.
Our pricing page lists amounts, not a fixed number of credits per job. What it offers instead is an in-app usage meter that shows where credits went. That is the right tool after the fact. Before the fact, the honest answer is to start small, run the real work for a few weeks, and size the monthly amount from what the meter shows. We would rather say that than publish a per-job number that only holds for the average customer.
When credit-based pricing is the wrong choice
Credits are not right for everything. Two cases come up often.
The work is deterministic. A product leader at a large software company made this point to us in August, and we agree with it. If the same question gets asked again and again with almost no reasoning involved, running it through an AI and spending credits each time is waste. Build it as a tool, and it costs close to nothing. Credits fit work that needs judgment and varies in size. They are a poor fit for work that should have been a feature.
Your customer is buying a result. Credits are how a software company pays for the AI's work. They are usually the wrong thing to pass straight through to your own customers. A customer who wants "every new hire through onboarding" does not want a credit balance. They want the job done for a predictable price. That is your price, set by you, usually a subscription for the job through your own Stripe account, while credits stay underneath as your cost of doing the work. We cover the other side of this choice in usage-based vs outcome-based pricing, and the risk each model leaves with the buyer in AI agent pricing models, compared by who pays when it fails.
A short checklist
If you are adding credits to an AI product, settle these before you publish a price:
- Who sets the ceiling? If it is not the customer, expect surprise bills and refunds.
- Does a credit mean the same thing on every plan? If discounts change the rate, every comparison gets harder.
- What happens at zero? OpenMeter's warning about outages is real. Decide whether work stops, slows, or finishes first.
- What does a credit buy, in your customer's words? Conversations, setups, a month of work on a job. Not tokens.
- Which work should not use credits at all? Repetitive, deterministic tasks belong in the product as tools.
- What are you selling on top? If your customers want a result, price the result yourself and keep credits as your cost.
FAQ
What is credit-based pricing?
A model where customers buy credits in advance and spend them as the product does work, with each kind of work costing a set number of credits. It caps the bill at what the customer bought.
Is credit-based pricing the same as usage-based pricing?
It is a form of usage-based pricing that is paid up front. The customer pays before the work instead of after it, which makes the bill predictable but shifts the question to how fast credits run down.
Should unused credits roll over?
Most products in Forth's sample do not allow it. We do not roll over monthly credits, because they are a month of capacity, but purchased top-ups never expire.
How does Aimdoc use credits?
Software companies prepay credits for the AI's work on their customers' behalf, set the budget, and see usage on a meter. Aimdoc never charges per outcome or per resolution. What a company charges its own customers for a service is its own price, through its own Stripe account.
Aimdoc delivers real work for your customers, metered in prepaid credits with a ceiling you set. See pricing and how to sell the work as a service, or start free.