Billing

Billing meters what a run costs. The platform’s single unit is AU (1 AU = €1.00, tracked internally in micro-AU at 6-decimal precision); each circle has a wallet, and a metered operation debits from it when it runs. This page is the runtime’s reference entry to that metering; the concept that teaches the model is billing-au.

The wallet is intrinsic to the circle

Every circle carries a wallet — the billing boundary that holds its AU balance (and, in the same conceptual envelope, its credentials and secrets). “Wallet” is the documentation name for that per-circle billing/secret boundary, not a single database object. The point that matters for billing is that the balance belongs to the circle and to nothing else: billing is scoped to the same airtight boundary as everything else, so a circle’s balance is its own, never shared across the wall.

Pricing is a cascade of dimensions

Two ideas make pricing precise rather than a flat cost-per-call:

• Cascade. Price resolves per operation from pricing.yaml files, root → category → element; the narrowest scope that declares a rate wins. Those YAML files flow through codegen into generated resolver tables — the same YAML→build-all.sh→generated lockstep as every other element behaviour, so physics never writes pricing per element type.
• Dimensions. An element bills on the dimensions it declares (per invocation, per input/output token, per running second). One operation can produce several debit lines at once — a compute action might bill per-invocation and per-second; an agent turn bills input and output tokens together. Operations with no matching rule resolve to zero — reads, lists, updates, and deletes are free. The metered surfaces are the ones consuming real resources: invocations, agent inference, storage, database compute, and outbound telecom. Note that elements are not entirely free to hold: a small universal charge applies to element creation (per_creation) and to each element’s daily existence (per_day_existence), independent of whether you ever invoke it.

What happens at the edge of the balance

Whether an over-budget run is blocked depends on the circle’s plan. Plans set a hard_wall flag: the freemium tier hard-walls — an operation that would cost more than the wallet holds returns HTTP 402 with code insufficient_balance (match on the code, not the message). The paid tiers (starter, scaler, pro, enterprise) run with hard_wall: false, so they may go briefly negative rather than block, and settle up against the balance. Debits take a per-circle lock, so under concurrency the balance moves consistently — on a hard-walled plan exactly one over-budget run drains the balance and the rest get the 402. Before a run, the cost surfaces as a cost chip whose prominence scales with the amount, and costs above a policy threshold route through an approval gate. A read-only estimate endpoint resolves the same cost without writing to the ledger, so a client can preview a charge first.

This page quotes no rate table on purpose — the authoritative numbers live in the YAML cascade and surface on a Pricing section on each metered element’s page, cascade-resolved from the same source the runtime bills against. (Elements whose cascade resolves to no priced operations omit the section rather than show an empty one.)

Related

• Concept: billing-au — the full model (the teaching home)
• Pillar: Runtime — a run is the unit that gets debited
• Each metered element page carries a Pricing section (cascade-resolved per-op cost)