Metering usage, end to end

One register, not a number in a settings file#

A limit is a promise in both directions: the workspace is held to it, and the business is protected by it. A limit that is advertised but never checked keeps neither promise, and that is exactly what went wrong here once — enforcement lived in two unrelated mechanisms with nothing tying either back to what the plan advertised, so a limit could be added and silently never wired to anything.

The register is the fix. Every dimension declares how it is enforced, in which module and function, or states honestly that the feature it governs is not reachable yet. A test walks the register and fails when a reachable dimension has no enforcement site, which is the part that stops the drift happening again.

The three kinds of dimension#

Daily counter

A per-day allowance, reserved atomically before the work happens: outbound email, inbound mail ingested, WhatsApp by category, model calls made on the workspace's behalf.

Resource ceiling

A limit on how many of something may exist at once rather than per day — connected mailboxes, and the split between personal and business-domain mailbox slots.

Tracked only

Counted for reporting and never used to refuse. Inbound customer messages are the case that matters: they cost nothing at the provider, and dropping one to enforce a quota would discard a real customer's message to protect nothing.

Stage by stage#

1. Trigger — any metered event begins: a send, a batch of mail arriving, a model call made on the workspace's behalf, a WhatsApp message going out.
2. User or external event — the event may be a person's (approving a draft) or the engine's (a scheduled drain). Metering does not care which; both spend the same allowance.
3. Authentication and workspace resolution — the workspace is settled before anything is counted. Reserving one workspace's allowance against another's plan is refused outright rather than trusted, because that is a tenant boundary crossed by a typo.
4. Ingest or request — the caller asks for a reservation of a named dimension and an amount, inside its own transaction.
5. Canonical record — today's usage row for that workspace, dimension and UTC date. A conditional update increments it, and that statement is what makes the limit hold when several requests race.
6. Reasoning — deliberately none. What a call cost is arithmetic over what a provider reported, never a model's estimate of itself.
7. Knowledge, memory and rules — untouched. Metering counts events; it does not learn from them.
8. Autonomy and approval — separate and upstream. Autonomy decides whether the action is allowed to happen at all; metering decides only whether there is allowance left to do it with.
9. Action through a provider — only after the reservation and the idempotency record are durable. Provider work before a reservation is how you get a message sent and not counted.
10. Result — the event proceeds, or a coded refusal comes back with the plan reason on it. A reservation for work that then fails is released rather than left spent.
11. Relationship, timeline and memory — the underlying event writes its own records; metering adds nothing to them.
12. Audit, usage and Needs You — the ledger is what the account screen, the digest and the per-call profiler all read; a refusal is recorded as a decision with its reason.

Ordering is the whole discipline#

Reserve, make the reservation durable, then call the provider. Reversing those two steps produces the only genuinely bad outcome available here: a message that reached a recipient and was never counted, or was counted twice because a retry could not tell it had already run. The reservation and the idempotency record land together for exactly that reason.

When the work fails after a successful reservation, the reservation is released rather than abandoned. Otherwise a provider outage would spend a workspace's whole day on messages nobody received — a limit doing damage instead of the job it exists for.

What the ledger is used for#

• The account and plan screens: what has been used today against what the plan allows, per dimension rather than as one blended number.
• Refusal messages that name a reason rather than failing vaguely — a person can tell an allowance apart from an outage.
• The per-call voice profiler, which reports what was measured and says plainly what was not, instead of estimating the gap.
• Deciding whether a plan fits: the shape of the usage is more useful than the total, which is why WhatsApp is metered by the provider's own categories rather than as one allowance.

Voice is the dimension with the most surprising arithmetic. A live call is billed on audio tokens, which are charged at a different rate from text on both sides of the conversation, so metering is split by modality rather than totalled. A call that reports no tokens at all is still charged from its own duration — never at zero — and every session a call held is merged into one figure, because a mid-call restart used to bill only the survivor.

Questions#

Related#

• Usage and allowances
• Entitlements and runtime choice
• Enforcing an allowance, end to end
• The daily email allowance
• What a call costs
• The AI budget guard, end to end