Key Takeaways

• Credit-based pricing separates the price list from the cost base. Salesforce prices one Agentforce action at 20 Flex Credits and sells credits at $500 per 100,000, so the action bills at $0.10 whichever model runs it.

• The credit rate is the lever, not the credit price. A vendor reprices an action by changing how many credits it consumes.

• Per-action rates let credits price outcomes. HubSpot's customer agent spends 50 credits, $0.50, only when it resolves a conversation without a human.

• The model doesn't ship without an exhaustion policy. HubSpot makes Pay-as-You-Go the default overage setting and lets admins cap or pause any credit-spending feature.

Why do teams pick credits over per-unit pricing?

Teams pick credits because one prepaid balance prices actions whose real costs differ by an order of magnitude, with no separate rate card for each. Salesforce sold Agentforce at $2 per conversation before Flex Credits; the credit replaced that single unit with a rate per action, and record updates, workflow runs, and case resolutions now draw down one pool.

What the indirection buys the vendor:

• One unit across a widening product. New features get a credit rate on launch day instead of a new SKU.

• Cash before consumption. Credit packs collect revenue upfront, which is why Salesforce sells 100,000-credit blocks rather than metering to an invoice.

• A comparable number in the plan table. Buyers weigh 5,000 credits against 500, though AI credits carry no fixed value between products.

Customers pay for that with a weaker line between what they ran and what they owe. Credit-based pricing explained, and when it beats a per-unit rate works through the choice at length.

What does running a credit model cost you?

Credits cost you obligations that per-unit metering never creates, and each one is engineering work. The balance has to be correct at read time rather than invoice time, because customers spend against the number your UI shows them.

Two of these bit harder than I expected: support volume rises because customers can't predict a task's credit cost before running it, and the close gets messier because a prepaid balance is an obligation you still owe. If you're pricing that build against buying it, book a demo and we'll model the ledger and exhaustion rules against your own actions.

Related terms

Each of these settles one decision the credit model forces on you.

• AI credits covers the unit itself and how vendors set its conversion rate.

• Credit burn-down handles the deduction mechanic behind a falling balance.

• Credit rollover answers whether an unspent credit survives the period.

• Credits share an invoice with a subscription fee under a hybrid pricing model.

• Consumption-based pricing bills the per-unit rate that credits abstract over.

• Block pricing prepays units directly, with no credit layer between.

FAQ

How is credit-based pricing different from usage-based pricing?

Credit-based pricing is one way to implement usage-based pricing, with a vendor-defined unit and prepayment in front of it. Plain usage-based pricing bills the metered unit in arrears, so the invoice shows requests or tokens rather than a balance.

How much should one credit cost?

Pick a round number and put the pricing work into the credit rate per action. HubSpot and Salesforce both landed on a cent per credit, which makes a 50-credit resolution read as $0.50 and a 20-credit action as $0.10.

What happens when a customer runs out of credits?

Whatever you decided in advance, which is why the policy is a launch requirement and not a later fix. HubSpot charges for each credit used past the monthly limit by default, then resets the account to its original allowance.