Usage & billing
What Kisenon meters, the free allowance, and how the console shows it.
Kisenon meters what you actually use and rolls it up per organization. Today the console shows your usage; it does not yet charge for it — see Alpha status below.
What we meter
The control plane samples three dimensions per project and aggregates them per organization:
| Dimension | Unit | How it's metered |
|---|---|---|
| Compute | CU-hours | Recomputed every minute from each endpoint's server-side runtime (Postgres now()), bucketed by the hour and weighted by compute size. |
| Storage | GB-months | Polled every 5 minutes from the storage layer's per-project size. |
| Branches | branch-months | Sampled once a day at 02:00 UTC per project. |
Compute is the one that moves: an endpoint that suspends on idle stops accruing CU-hours the moment it stops, so a project that sleeps most of the day costs a fraction of one that runs flat out. Storage and branch counts are stable within their sampling windows, so a coarser cadence is fine.
The samples roll up into a single per-organization view of compute, storage, and branch usage for the current billing cycle — the numbers the billing page renders.
The free tier
The alpha free tier is enforced as a project-count cap per
organization. When the cap is enabled, an organization with no payment
method on file is held to a fixed number of projects; once it's reached,
creating another project returns free_allowance_exhausted (HTTP 403).
Organizations with a payment method on file are uncapped. The exact cap
is a deployment setting rather than a hard-coded number, so it can be
tuned as the alpha evolves.
As a cycle's metered usage climbs, the console shows an escalating
banner above the main content at three thresholds — the same 80 / 95 / 100 percentages the control plane records in its per-cycle notification
log:
- 80% — a yellow notice: "You've used over 80% of your free tier this period."
- 95% — an amber warning to add a payment method before service is interrupted.
- 100% — a red exhausted state: compute may be paused until a payment method is added.
Each banner is dismissible for the session and links to Add a payment method.
The org billing page
Every organization has a billing page at /orgs/{id}/billing, reachable
from the org's nav. When usage data is available it renders, per
dimension, a used / allowance bar (green below 80%, amber 80–95%, red
at/above 95%) plus an optional projected end-of-period marker, a
projected-invoice line, and the current plan and payment method.
Alpha status
Billing is not yet live. There is no payment method to add, no invoice to pay, and no checkout flow:
- The metered samples above are collected and stored, and the console
surfaces them, but the control plane's billing endpoint
(
/v1/billing/customer) is not wired in the alpha. - Because that endpoint returns nothing today, the usage banner always renders as nothing (0% used) and the billing page degrades to a "Coming soon" placeholder rather than throwing.
- Payment processing is Stripe Test-Mode scaffolding only. The Stripe customer field, the billing NOTIFY trigger, and the owner/billing portal route are all reserved stubs — no real cards, no real invoices.
When billing lands, these surfaces light up with no rewrite: the banner and the billing page already read from the same endpoint, so they begin showing real numbers the moment it returns data.
Related
- Organizations — the unit usage rolls up to.
- Endpoints — suspend-on-idle is what keeps CU-hours down.
- Alpha status — what is and isn't enabled yet.