Credit-Based Billing: Examples & Companies

What is it

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.

Credits act as an abstraction layer between the customer and the underlying cost driver. Instead of seeing “0.0001¢ per token” or “$0.05 per minute of video,” the customer sees “you have 625 credits this month.” The vendor can change underlying economics — swap a cheaper model in, adjust a feature’s credit cost, add a new feature — without renegotiating contracts. The buyer budgets in one number instead of N, which is the whole point on a product that spans several features with wildly different unit costs.

It is now the single most common billing unit in the corpus: 123 in-corpus companies meter at least part of their product in credits — ahead of both tokens and seats. The pattern is strongest where one product spans features with very different costs. Runway bundles monthly credits (a Standard seat includes 625 credits/mo) across video, image and audio generation, and Recraft pools credits across image and vector generation on Basic ($12/mo) and Pro ($20/mo).

Credits are not a pricing model in their own right — they are a unit that sits on top of subscription, freemium, or hybrid models. On the corpus, credit metering pairs most often with a subscription or seat base (GitHub Copilot, Glean), turning the credit into the variable, usage-sensitive half of an otherwise fixed plan. The deeper mechanics of pool sizing, rollover and expiry are covered in our prepaid credits models guide.

How it works

The two key design decisions in any credit system are: (1) what defines a credit, and (2) how credits replenish. A credit can be pegged to a dollar of real cost, pegged to a fixed dollar of overage, or left as an arbitrary vendor-defined unit whose per-feature consumption rates are set independently.

Unit math (Cursor’s transparent model): the $20 Pro plan grants $20 of credits, drawn down at real API rates. Because a Claude 4 Opus request ($15 input / $75 output per million tokens) costs roughly 10× a comparable request on a cheaper frontier model, the same $20 buys far more of the cheap model than the expensive one. That 10× spread is precisely why the credit — not the token — is what the buyer sees on the plan card.

Unit math (GitHub Copilot’s overage model): a Business seat is $19/user/mo and includes 1,900 pooled AI credits. Once the pool is exhausted, additional usage bills at $0.01/credit. So a team that burns 500 credits over its included pool pays an extra $5 that month — a clean, disclosed marginal rate layered on top of a flat seat.

Most corpus credit systems sit toward the opaque end. Suno (Pro $10/mo, Premier $30/mo), Runway and Recraft’s Studio credits are not tied to a published per-unit API rate, which lets the vendor change underlying model costs without exposing them. Clay runs a dual-meter variant — Actions capacity plus Data Credits usage (Launch $185/mo, Growth $495/mo) — where the credit tracks external data-enrichment spend. Glean runs the enterprise variant: pooled “FlexCredits” sitting alongside per-seat Enterprise access.

Companies using this

123 companies in the current corpus meter at least partly in credits, concentrated in generative-media tools (Suno, Runway, Recraft, Midjourney, Ideogram, Descript, ElevenLabs, Synthesia, HeyGen, Gamma), AI coding (Cursor, GitHub Copilot, Windsurf, Codeium), GTM/data platforms (Clay, Apollo.io), and enterprise search and platform products (Glean, Writer, Mistral AI). The table below lists how each company defines and prices a credit.

Patterns observed

• Credits unify pricing across multi-feature surfaces. The tools that lean hardest on credits — Runway, Descript, Synthesia, ElevenLabs — all span features with very different unit costs (a minute of avatar video vs a second of voice dubbing vs a still image). One currency is the only sane way to present them on a single plan. Where a product has just one cost driver, credits rarely appear.

• Credits are the variable half of a fixed base, not a replacement for it. In B2B, credit metering almost always rides on top of a seat or subscription rather than displacing it. Glean layers FlexCredits over per-user Enterprise seats; Writer and Apollo.io both pair seats with credits. The credit carries the usage-sensitive spend while the seat anchors the contract.

• Transparent credits create competitive pressure for opaque ones. Once one vendor pegs credits to real cost, the markup question becomes public for the whole category, and competitors running arbitrary credits have to either disclose their ratio or compete on something other than transparency.

• The cutover to credits is itself a recurring event. Maturing generative-media products tend to migrate onto a unified credit pool rather than launch with one — Recraft, HeyGen and Synthesia each restructured older per-feature or flat plans onto credits. Credit centralisation is where these products land, not where they start.

• Rollover and expiry are the quiet differentiators. Two credit plans at the same headline price behave very differently depending on replenishment rules. Runway’s Max tier (9,500 credits) rolls credits over; a plan that resets to zero monthly is materially worse for spiky users at the same nominal grant. Buyers who ignore this over-index on the credit count and under-price the reset policy.

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 will not realise it until they inspect the per-feature breakdown — if the vendor even shows one. Cursor added per-model spending visibility only after the June 2025 incident, when a silent re-pricing of its credit pool caused public bill-shock; competitors with no equivalent breakdown remain exposed to the same failure mode.

The clearest counterexamples are the pure-token API players that deliberately don’t use credits: Mistral AI’s raw API and other LLM providers publish per-token rates because their developer buyers want to model cost precisely, and a credit abstraction would actively get in the way. Where the buyer’s job is cost engineering, the token beats the credit.

Two variants are worth naming. First, credits-without-a-pool, where every credit is paid usage with no included baseline — functionally identical to pure-usage pricing with a credit denomination; the corpus classifies those as pure-usage, not credits. Second, the dual-meter credit, seen at Clay, where “Actions” capacity and “Data Credits” are separate meters on the same plan — a reminder that “credits” is not one mechanism but a family of them, and that a company can run two independent credit-like meters at once. Recraft shows a third split: subscription credits for the Studio product and a separate per-image API where $1 buys 1,000 units, so the same brand prices the same underlying capability two different ways for two different buyers.

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 mix — a plan that looks generous on cheap features can evaporate on one expensive one. Then check the replenishment rules: whether unused credits roll over or reset to zero, and whether overage is a hard cap or an auto-billed marginal rate. Where a vendor pegs the credit to real cost you can model spend directly; where it doesn’t, treat the credit count as a soft number and budget conservatively. Our prepaid credits models guide walks through the pool-sizing math, and the Cursor pricing calculator lets you pressure-test a credit-pool plan against real 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, the way pure-token API vendors do. If you do adopt credits, decide early whether to peg them to real cost: transparency buys trust and reduces bill-shock risk, while an arbitrary credit (Suno, Runway) buys flexibility to change model economics silently — at the cost of the re-pricing backlash a silent change invites. Ship per-feature and per-model spend visibility before you need it, not after an incident. For the surrounding billing infrastructure — metering, aggregation, invoice generation — see our usage invoicing guide and the introduction to usage-based pricing.

Explore this theme in the knowledge graph →