Pricing models and meters

There are two ways to charge for something, and most products use both. Flat — a fixed amount per period. The customer pays 20 € a month and gets what the tier includes. Nothing is counted. Metered — the amount depends on what they used. 0.35 € per hour of machine time, 2 € per million tokens, 0.04 € per SMS. Something has to be counted, and that something is a meter. A tier can mix them freely: a flat base fee, three features that are simply on or off, one allowance that stops dead when it runs out, and one that keeps serving and charges for the excess.

What a meter measures

A meter counts one thing, for one customer, over a period.

The unit — minute, token, message, gigabyte. Count in the smallest unit you bill: minutes, not hours. Counts are whole numbers, which is what makes concurrent consumption safe, so a fractional hour has nowhere to go. Same discipline as storing money in cents.
The period — daily, weekly, monthly, or the customer’s billing cycle. This is when the count goes back to zero.
What it’s counted by — by default, one pool per customer. It can also split per machine, per project or per seat; see below.

You declare the unit and the period on the feature. Each tier then decides how much is included and what happens past it. Your backend does the counting with one call:

await kerne.consume('cutter_minutes', { customer: customerId, delta: 60 });

That checks the allowance and commits the increment in one atomic step, so concurrent requests can’t both slip past a limit. See consume().

The rate

A rate is an amount and the quantity it buys — “0.35 EUR per 60 minutes”, not “0.0058 EUR per minute”. Kerne keeps both halves, because 0.35 divided by 60 has no exact decimal and a flattened rate is unrecognisable as the offer you sell. Past that, two questions. Their answers are independent, and between them they cover every shape you can build.

Does a partly-used quantity count in full?

1,500 units at 5.00 EUR per 1,000:

You charge	You invoice
for every 1,000 started	10.00 EUR — the second thousand counts whole
for the exact usage	7.50 EUR — the exact fraction

Does the rate change as usage grows?

Add a tier — “past 10,000 units, 4.00 EUR per 1,000” — then say what a tier applies to. A customer who used 20,000 pays:

Each tier is priced	You invoice
on its own slice	90.00 EUR — the first 10,000 stay at their own rate
at whatever rate the total reaches	80.00 EUR — the reached rate reprices the lot

Nothing here assumes the rate falls as usage grows. Volume discounts and congestion pricing are both real offers; a tier just says what applies past a point, in either direction.

The two questions combine. “0.35 EUR per 60 minutes, every started hour whole, dropping to 0.28 EUR past 150 hours” is one rate — Kerne does the quantity arithmetic before the provider sees a number, which is what lets a sold-by quantity and a tier schedule coexist. Stripe cannot express that pairing on its own.

Per machine, per project, per seat

By default a meter pools everything into one counter per customer. Often that’s right — they’re billed for total consumption, and which machine produced it is their business. Sometimes it isn’t. Dimensions split one meter into several counters under the same customer:

await kerne.consume('cutter_minutes', {
  customer: customerId,
  dimension: 'cutter_42', // ← this
  delta: 60,
});

Declare what the feature is counted by (minute per cutter), then each tier chooses what that means — and the allowance and the spending cap choose independently:

Setting	Shared	Per slice
Allowance	One pool: 200 hours total, whoever burns them	200 hours per cutter; A running out doesn’t touch B
Spending cap	”Your bill never exceeds 120 € a period"	"Each cutter costs you at most 120 €” — ten cutters can bill ten times it

Per-slice caps are the ones people forget exist, and usually the better default: it’s how you sell 1,000 credits per user with a 20 € ceiling per user, or 100 GB per project at 50 € per project. Attribution works either way — even on a shared pool, every event records which slice it came from.

Why the cap doesn’t block

A spending cap is a ceiling in money, and it does not stop anything.

Money and access are separate

Hitting a spending cap means you stop charging. The customer notices nothing — their machines keep running, their API keeps answering.

Blocking is its own setting

If you genuinely want consumption to stop, that’s a ceiling in units, sitting one rung below on the same rule, and empty by default.

The reason is simple: a spending cap is a promise you made about your invoice. Turning it into an outage would punish the customer for a promise you made to reassure them.

What you see

The Usage billing screen shows every subscriber on a metered entitlement: consumed, billable, already charged, and room left under the cap. Two states are worth watching for:

Capped — still consuming, no longer charged. Working as designed, but you want to know.
Not billing — the provider is refusing this entitlement’s usage (its price was archived, its meter turned off). Access still works, revenue is silently zero.

Things that will bite you

A cap counts whole quantities, it does not divide

A 120 € cap at 0.35 € per started hour doesn’t buy 342.8 hours. It buys 342 whole hours: the 343rd would count whole and invoice 120.05 €. Kerne computes it the way the invoice will.

The cap resets on the feature's period, not on the invoice

A 120 € cap means 120 € per renewal period — the one set on the feature, not the one you bill on. Usage is invoiced monthly, so the two only line up when the feature renews on the billing cycle. A weekly feature can carry roughly 4 × 120 € onto one invoice; a daily one, 30 ×.None of those is wrong. But if you meant “their bill never exceeds 120 €”, renew on the billing cycle.

Changing a rate means replacing it

A price is immutable on its amount at the provider, so “change the rate” is always “create another and point this entitlement at it”. The meter is reused, not recreated, so consumption history stays whole.Customers already subscribed keep the rate they signed up on. Changing their plan brings them onto the current one.

An allowance that carries over can't also be billed

If unused allowance rolled into next period, last period’s consumption would be billable again. Kerne refuses the pair rather than storing it. Same for an unlimited allowance with a rate attached: nothing would ever be billable.

Repricing everything can make a bigger bill smaller

If tiers are priced at whatever rate the total reaches, crossing one can lower the total: at 5 € then 4 € per 1,000, ten thousand units cost 50 € and ten thousand and one cost 44 €. That’s the pricing working as designed; the editor says so when you pick such a tier.

Set one up end to end

A metered feature from blank to invoice line.

Designing your pricing

Which shape fits what you sell.

Get started

Core concepts

Users & sign-in

Reference

Pricing models and meters

What a meter measures

The rate

Does a partly-used quantity count in full?

Does the rate change as usage grows?

Per machine, per project, per seat

Why the cap doesn’t block

Money and access are separate

Blocking is its own setting

What you see

Things that will bite you

Next

Set one up end to end

Designing your pricing

​What a meter measures

​The rate

​Does a partly-used quantity count in full?

​Does the rate change as usage grows?

​Per machine, per project, per seat

​Why the cap doesn’t block

Money and access are separate

Blocking is its own setting

​What you see

​Things that will bite you

​Next

Set one up end to end

Designing your pricing

What a meter measures

The rate

Does a partly-used quantity count in full?

Does the rate change as usage grows?

Per machine, per project, per seat

Why the cap doesn’t block

What you see

Things that will bite you

Next