Credit-Based Billing: Examples & Companies

1 company in the corpus Updated stub analysis
Definition

Credit-Based Billing is a billing unit where customers pre-purchase or are allocated a pool of credits that deplete as they use the product, often at variable rates per feature.

Also known as: Credit Pool Pricing , Prepaid Credits , Token Credits

What is it

Credit-Based Billing is a pricing model where customers spend a pool of credits across multiple product features, with each feature consuming credits at its own rate.

Credits act as an abstraction layer between the customer and the underlying cost driver. Instead of seeing “0.0001¢ per token” or “$0.0003 per function invocation,” the customer sees “you have 5,000 credits this month.” The vendor can change underlying economics — swap a cheaper model in, change a feature’s credit cost, add a new feature — without renegotiating contracts. The buyer can budget in one number instead of N.

The model is now standard across AI products. Cursor ties $1 of credits to $1 of underlying API cost — the most transparent variant in the category. Vercel uses credits as a flexible spending mechanism across its AI products (v0) while billing infrastructure on per-dimension meters. Other AI tools — Replit, Cline, Codeium — have converged on credit pools as the standard packaging.


How it works

The two key design decisions in any credit system are: (1) what defines a credit, and (2) how credits replenish.

DimensionTransparent variantOpaque variant
Credit definition$1 credit = $1 of underlying API cost (Cursor)Arbitrary credit unit, vendor-defined consumption rates per feature
Credit allocationIncluded in plan dollar amount (Pro $20 → $20 credits)Bundled with seat fee, opaque ratio
ReplenishmentMonthly reset on billing dateRollover, expiry, or burn-down models
OverageOpt-in additional credit purchase OR auto-bill at posted rateHard cap at zero; features fail until next reset

Unit math (Cursor’s transparent model): $20 Pro plan → 20 credits → ~500 GPT-5.1 Codex requests (at $1.25 input / $10 output per million tokens, average request ~10K tokens). Same $20 credits → ~45 Claude 4 Opus requests at $15/$75 per million. A 10x spread across frontier models.

The opaque variant is more common in enterprise SaaS. Notion AI’s “credits” are not tied to any underlying API rate; Salesforce Einstein “credits” likewise. The opacity is deliberate — it lets the vendor change underlying costs without exposing them.


Companies using this

Two companies in the current corpus use credit-based billing: Cursor with its transparent $1-credit-equals-$1-API-cost model, and Vercel which mixes credit-style packaging on v0 with per-dimension billing on infrastructure.


Patterns observed


Counterexamples & variants

The strongest critique of credit-based billing is that it can hide cost-per-feature from the customer. A user spending 80% of their credits on one expensive feature won’t realise it until they look at the per-feature breakdown — if the vendor even shows one. Cursor added per-model spending visibility after the June 2025 incident; competitors with no such breakdown remain bill-shock-prone.

Variant worth noting: credits-without-pool. Some vendors charge per-credit without including a baseline pool — every credit is paid usage. This is functionally identical to pure-usage pricing with a credit denomination — it’s a marketing choice, not a structural one. The corpus classifies these as pure-usage, not credits.


What this means for buyers vs vendors

For buyers

Demand transparency on credit consumption rates per feature. A pricing page that lists credit cost per feature is structurally honest; one that shows only “credits per month included” is structurally opaque. In procurement, ask for the worst-case-per-feature credit rate and run it against your projected usage.

For vendors

Credits are the right packaging when (1) you have multiple features with different cost drivers, (2) underlying costs may shift over the contract period, or (3) the buyer’s mental model is “budget per month” rather than “cents per request.” If those don’t hold, credits add complexity without buyer benefit — stick to direct per-unit billing on the dominant cost driver. See our usage invoicing guide for the surrounding infrastructure choices.

Company Product Pricing modelBilling unitsFree tier Verified
Cursor (Anysphere)AI code editor
hybridseat-plus-usage
creditstokensseats
Yes2026-05-23

FAQ

What is credit-based billing?

Credit-based billing is a pricing model where customers receive or pre-purchase a pool of credits, which deplete as they use the product. Different features may consume credits at different rates, but the customer always sees one unified balance.

Are credits the same as tokens?

No. Tokens are the underlying unit LLM providers charge for. Credits are an abstraction layer that lets a vendor expose multiple features at different rates without forcing the customer to learn each one. Cursor's $1 credit = $1 of underlying API cost is unusually transparent; most credit systems decouple the credit from any specific dollar amount.

Why do vendors use credits instead of just billing per-feature?

Three reasons: (1) credits let the vendor change underlying economics — say, swap models — without renegotiating contracts; (2) credits provide a clean prepay UX for the buyer; (3) credits move the customer's mental model from 'cents per token' to 'budget per month,' which reduces friction.

What are the downsides of credit-based billing?

Credits can obscure unit economics — the customer can't easily tell which feature is expensive. They also create bill-shock risk if the vendor changes credit consumption rates without notice. Cursor's June 2025 silent re-pricing is the canonical cautionary tale.

Related guides & calculators

Back to corpus