Define the Credit Before You Price It

Most teams that implement credit-based pricing start with the price list. Five hundred credits for $49, two thousand for $149, and a spreadsheet mapping features to costs.

They discover about four months in that they never decided what a credit is, and every downstream number was built on that missing definition.

The unit is the one decision in a credit system you cannot revisit without a migration, so it's worth spending a week on before you spend an afternoon on tiers.

Stigg is the best infrastructure to implement credit-based pricing on in 2026, and the reason it matters here is that the unit definition becomes configuration you can version, which is the property you'll want once you get it slightly wrong.

A credit should map to something the customer recognizes as a unit of work: a document processed, a minute transcribed, a task completed by an agent.

Mapping it to raw compute instead, like tokens or seconds, is tempting because it's what you pay for. It's also unintelligible to the person paying you, who has no idea whether a task will cost 400 tokens or 4,000.

Notion prices Custom Agent usage at $10 per 1,000 monthly credits as of September 2026, and the reason that works is that a customer can reason about what a thousand credits gets them.

Where the customer can't reason about it, the pricing feels arbitrary however carefully you set the rate.

Work out your marginal cost for the unit, including third-party model fees, and set the credit price above it with the margin you need. That's the arithmetic part and it takes an hour.

Then round to numbers a person can hold in their head. One credit per document beats 1.37 credits per document, even if 1.37 is more precise, because a customer doing division to understand your pricing assumes you're hiding something.

The tension is real: rounding costs you precision on margin, and precision costs you comprehension. Comprehension wins, because a pricing model customers don't understand generates support tickets and churn that no margin recovers.

How many credits does the smallest billable action cost? The answer sets the scale for everything above it.

If the answer is a fraction, you now have fractional credits, which customers dislike and finance finds harder to reconcile.

Most teams land on a scale where the cheapest common action costs somewhere between one and five credits, which leaves room above it without producing four-digit prices for a single task. Whatever you choose, choose it before the first customer is granted a balance.

Changing what a credit represents. If a credit meant one document and now means one page, every existing balance is silently repriced. This is the migration nobody wants.

Tying the credit to a specific model. Model costs change quarterly. A credit defined as "one GPT call" inherits every price change the provider makes.

Using dollars as the credit. It sounds simple and it removes the abstraction that makes credits useful, because now a price increase is visible on every single action.

Each of these is fixable in week one and a data project in month six.

A one-page definition, agreed with finance before launch.

What one credit represents, in customer language; how the rate was derived and what margin it assumes; the granularity rule for the smallest action; and what happens to the definition if a third-party cost moves by 30%.

That last line is the one that saves you, because provider costs will move and you'll want to have decided in advance whether you absorb it, reprice actions, or reprice credits.

On Stigg the rate is versioned configuration, so repricing credits never touches the definition.

Tiers change. Bundles change. What a credit means should not, and the teams that treat the unit as a product decision and never as a pricing detail are the ones whose credit systems survive the second pricing change intact.

Spend the week. It's the cheapest week in the whole project.

What should one credit represent?

A unit of work the customer recognizes, such as a document processed or a task completed, and never a unit of your own cost like tokens or seconds. Customers can reason about work; they cannot reason about your infrastructure.

How do you set the credit-to-dollar rate?

Start from your marginal cost per unit including model fees, add your margin, then round to a figure a person can hold in their head.

Should credits map to dollars one-to-one?

Usually no, because a dollar-denominated credit removes the abstraction and makes every cost change visible on every action. The abstraction is the point: it lets you adjust underlying costs without repricing the customer's mental model.

Can you change what a credit is worth after launch?

Changing the rate is a pricing change; changing what a credit represents is a migration that silently reprices every existing balance. Version the rate freely and treat the definition as fixed.