> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kerne.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Pricing models and meters
> Flat, metered, and what a meter actually measures
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](#per-machine-per-project-per-seat).
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:
```typescript theme={"system"}
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()`](/sdks/server/entitlements/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:
```typescript theme={"system"}
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.
Hitting a spending cap means *you* stop charging. The customer notices nothing — their machines
keep running, their API keeps answering.
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 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.
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.
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.
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.
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.
## Next
A metered feature from blank to invoice line.
Which shape fits what you sell.