Modern Pricing & UBB
February 26, 2026 credits

Designing a Credit Economy: Rates, Tiers, and the Refresh Cycle

Credits are the most popular pricing mechanism in AI and usage-based software right now, which means most companies are deploying them without having thought through the design. The result: credit systems that create customer confusion, arbitrary exchange rates that need quarterly re-papering, and pooling decisions made casually that become major negotiation points at enterprise renewal.

A credit economy has five design dimensions, and you need to make deliberate choices on each one before you ship.

1. The Credit-to-Value Mapping

The first decision is the exchange rate: how many credits does one unit of product value cost? This isn't just a math problem — it's a communication problem. The credit rate determines whether your pricing feels intuitive or opaque.

There are two schools of design. The first keeps the mapping transparent: 1 credit = 1 API call, or 1 credit = 1,000 tokens, or 1 credit = 1 report generated. Clean, auditable, directly tied to a product action. Customers can predict their spend without a calculator.

The second uses abstracted credits: 1 credit = "some amount of processing" with the conversion table buried in documentation. This gives you flexibility to reprice individual operations without changing the nominal credit price — but it creates customer suspicion when the effective rate of credits-per-value changes silently. Orb's architecture guidance is explicit: if you're going to use abstracted credits, publish a conversion table and keep it current. Opaque credit economies generate support tickets and billing disputes.

For AI products specifically, the challenge is that compute costs change frequently and dramatically. A credit that bought 1M tokens in 2023 might buy 10M tokens in 2025 as model costs fall. How you handle this is a deliberate choice: pass savings to customers (builds loyalty, reduces effective price), keep the nominal credit value stable (simpler accounting), or adjust the nominal value periodically (confusing but maximally flexible).

2. Tiered Credit Prices: Volume Discounts

Credits should get cheaper as customers buy more. This is not charity — it's the mechanism that drives annual commits over month-to-month purchases and rewards your best customers with better economics. Standard tier structure:

The discount thresholds should be anchored to your actual cost structure. If you have meaningful economies of scale in delivering your product — and most SaaS businesses do — the volume discount can be generous because your margin at scale is higher than at starter levels. If you don't have scale economics, be careful about how deep the discounts go.

3. Monthly vs. Annual Refresh Cycles

The refresh cycle determines when credits reset. Monthly refresh creates a "use it or lose it" dynamic per month — good for driving regular engagement, potentially frustrating for customers with uneven usage patterns. Annual refresh creates a longer runway — better for customers, requires rollover/expiry policy decisions, creates larger balance sheet liability.

Metronome's documentation identifies a third option that many companies overlook: rolling credits that don't reset on a calendar but expire based on purchase date. Credits purchased on March 15 expire on March 15 of the following year, regardless of billing cycle. This is operationally more complex but eliminates the end-of-period rush-to-spend behavior that monthly credits create, which often results in low-quality usage that drives support volume.

Best practice for most B2B products: annual credit allocation with rolling expiry (credits expire 12-24 months from purchase) and a quarterly true-up to reconcile consumption against allocation. This gives customers maximum flexibility while maintaining balance sheet predictability for your Finance team.

4. The Pooling Decision: Per-Seat vs. Org-Wide

Does each user on the account have their own credit allocation, or does the entire organization draw from a shared pool? This is the decision with the most significant enterprise negotiation implications, and it gets made casually more often than it should.

Per-seat credit allocation is simpler to administer — each user gets X credits per month, overage is per user, and Finance can allocate costs back to departments clearly. The downside: it creates artificial internal friction when some teams use credits heavily and others don't. The marketing team has credits left over; the engineering team is running low. No transfers allowed. This is a product complaint waiting to happen.

Org-wide pooling is operationally more complex but creates a much better customer experience. Heavy users and light users balance each other out automatically. One enterprise credit allocation serves the whole organization, which is how every enterprise customer will expect it to work when you're selling to the CTO. The challenge is chargebacks: if IT wants to allocate credit costs back to departments, they need your usage reporting to show per-user consumption clearly.

The recommendation for enterprise products: org-wide pooling by default, with per-user consumption reporting available via API or dashboard. This gives the customer the flexibility they expect and the transparency their Finance team needs without creating artificial allocation friction.

5. The Currency Design Choice

One underrated decision: should your credits be denominated in dollars or in abstract units? Dollar-denominated credits are trivially transparent — $100 in credits = $100 of product. Abstract credits (tokens, points, compute units) let you change the effective price without changing the nominal rate, which is useful as your cost structure evolves. The tradeoff is exactly that: transparency vs. flexibility. Enterprise customers almost universally prefer dollar-denominated credits because their procurement and Finance teams need to reconcile against budget lines in dollars, not in abstract units that require a conversion table.

There's no universally right answer here. But the wrong answer is to pick abstract credits for developer-facing APIs and dollar credits for enterprise deals and discover at renewal that your pricing is internally inconsistent across customer segments.

Sources

← Credit Systems · All posts