Glossary
Credits
Credits are a prepaid unit a vendor deducts as you use a product, bundling the underlying consumption into a round number that is easier to buy and harder to compare.
In plain terms
You buy a quantity of something the vendor invented and spend it as you work. It is easier to purchase than a meter reading and easier to budget than an open-ended bill, which is why it is popular. The difficulty is that the unit is defined by whoever is selling it, so two products quoting the same number of credits for the same money may be offering quite different amounts of work.
Why it matters
Because it is the layer at which most AI purchasing comparisons are actually made, and it is the layer least suited to it. A buyer holding two quotes reads two numbers, and the numbers are in different currencies without saying so. That is rarely deliberate concealment; abstraction is a genuine convenience for the vendor's own billing. The consequence is the same either way, which is that the comparison people think they are making is not the one they are making.
How it works
The vendor defines the unit, so it carries no external meaning. One product may deduct a credit for a message, another for a thousand words, another for a whole task however long it runs. None of those is wrong and none of them is comparable to the others without a conversion nobody publishes, which is why two credit prices sitting side by side tell you very little.
Consumption per credit usually varies inside a single product too. A quick request and a long deliberation on a large document rarely cost the same, so a plan quoting a number of credits is quoting a ceiling on activity rather than a quantity of work. The practical question is how many of your actual tasks fit, not how many credits you get.
Expiry is where the model differs most from a meter, and it is the term people skip. Ask whether unused credits roll over and for how long, because where they lapse at the end of a period the unused portion is money the vendor keeps, and that makes buying ahead a different decision from buying more. The answer is a specific line in the terms and it is worth having before the quantity is negotiated.
Ask what each feature deducts, because one balance can be drawn on at very different rates. An image, a long document analysis and a short question may all come out of the same pool while consuming wildly different amounts underneath, which is what makes a balance hard to forecast from experience. Where that is so, a team's burn rate can change sharply without anybody changing how they work, simply by using a different part of the product.
Ask what happens when the balance empties, and get the answer while nothing is urgent. The possibilities are that the product stops, that it continues and invoices, or that it falls back to a slower or smaller option. Each is defensible and they are very different experiences, so which one you have is worth establishing rather than discovering.
The model exists partly because the underlying cost is genuinely variable. A vendor absorbing that variance needs a unit that is stable enough to sell, and credits are how that is done. Reading them as an accounting convenience rather than as an obfuscation makes the questions easier to ask and usually gets better answers.
The comparison that works is expressed in your own tasks. Take twenty representative pieces of work, ask each vendor what they would consume, and compare that against price. It converts two incomparable units into one number that means something to you, and it is a question good vendors answer readily.
Two quotes, same number
Seen in the wild
Ask what one credit deducts for a short question against a long document analysis, and notice whether the answer is a single figure.
ChatGPTCompare a credit-based plan against a product that charges per request, where the underlying unit is visible rather than bundled.
OpenRouterWatch how quickly a balance moves when a metered step runs inside an automation over every incoming record.
MakeAsk what each feature deducts from a shared balance before forecasting a burn rate from experience.
Notion AI
Common misconceptions
People assume
More credits for the same money is the better deal.
In fact
Only if a credit means the same thing in both products, which it usually does not. The unit is defined by the seller, so the quantity is not a comparison until it has been converted into work you recognise. Comparing the numbers directly is the single commonest error in AI purchasing.
People assume
Credits make spending predictable.
In fact
They cap it, which is a different property. Predictability would mean knowing how much work a balance buys, and that varies with what you ask for. A credit plan bounds the worst case for the period and leaves the amount of work genuinely uncertain, which is worth having and is not the same thing.
People assume
Unused credits are simply savings.
In fact
Frequently they expire, which converts unused capacity into money kept by the vendor. Whether they roll over and for how long is a specific term to read rather than assume, and it changes whether buying a larger bundle up front is prudent or expensive.
Telling them apart
Credits vs Token pricing
Credits
A vendor-defined bundle. Easy to buy, hard to compare between products.
The underlying unit itself. Harder to forecast, and directly comparable.
Ask whether the unit means anything outside this vendor. If not, it is a credit.
Questions
- How do we compare two credit-based quotes?
- Not directly. Take twenty representative pieces of your own work and ask each vendor what they would consume, then compare that against price. It converts two vendor-defined units into one figure that means something to you, and how readily a vendor answers is itself informative.
- What should we ask before buying a bundle?
- What one credit deducts for your commonest task and for your heaviest one, whether they expire and when, whether different features draw at different rates, and what happens when the balance empties. Those four answers turn a quantity into something you can forecast against.
- Why do vendors use them at all?
- Because the underlying cost genuinely varies and a sellable plan needs a stable unit. Somebody has to absorb the difference between a short question and a long deliberation, and bundling is how that is done. Treating it as an accounting convenience rather than a trick tends to produce better conversations.
- Why did our balance drop faster than expected?
- Usually because the mix of work changed rather than the volume. A heavier feature, longer documents or a more capable model can all draw at a higher rate from the same pool, so a team can burn through a balance without feeling it is doing more. Asking for a breakdown by feature is the fastest diagnosis.
Key takeaways
- The vendor defines the unit, so credit counts are not comparable between products.
- A credit plan caps spending; it does not tell you how much work you have bought.
- Expiry turns unused capacity into money kept by the vendor, so read that term.
- Different features often draw on one pool at very different rates.
- Compare in your own tasks: ask each vendor what twenty real pieces of work would consume.
Tools that use this
- ChatGPT
Asking what one credit covers for a short question against a long analysis.
- OpenRouter
The contrast: a visible underlying unit rather than a bundled one.
- Make
How fast a balance moves once a metered step runs on every record.
Last checked July 2026