TolavoUsage records
The record you bill from.
Usage pricing only works if something was recording the runs before the month you want to charge for. Most people find that out afterwards.
What makes a count defensible
Five properties, and what each one is protecting you from.
Each of these is a mechanism rather than a policy — something the record does on its own, whether or not anybody remembers it that month. That is the whole difference between a number you can defend and a number you can only repeat.
Where the count is explained to the client →Each recorded run counted once
A run is metered against a unique pair of the run and the thing being counted, so reading the same run again cannot count it twice. A retried run request, or a repeated delivery to your inbound webhook, whether it reports a success or a failure, counts once when it repeats its Idempotency-Key; without a key, two requests are two runs. This is the property that survives a client checking your arithmetic.
Priced at the rate your client accepted
Runs above the included number are priced at the rate in the agreement your client accepted, which the proposal showed them beside the price before they accepted. Changing your plan’s price changes what you offer next and never reprices an agreement already accepted; repricing one is the single fastest way to lose a client who was otherwise happy. Usage with no accepted agreement behind it is priced from the plan’s terms.
Attributed to the client it ran for
Runs are recorded per deployment, so a busy month and a failure both belong to somebody in particular rather than to the system in general.
Recorded before you need it
The record is a side effect of the run, not something you remember to switch on. The reason this matters is that the alternative — realising in week four that nothing was logging — cannot be fixed retroactively by anybody.
A finished run cannot be rewritten
Which is the only reason a run count is a fact rather than an assertion. If the record could be edited afterwards it would not be evidence, and everyone in the conversation knows it.
The distinction
A run and an outcome are not the same event.
Tolavo records the two separately, and a run counts towards an outcome only if it meets the definition in force before it ran: yours, or until you publish one, the built-in one. The built-in one checks only that the run succeeded — for a call Tolavo makes, that your system answered with a 2xx — which shows it answered, not that the answer was right. Activity is not value, and a number that treats them as one is a number a client eventually stops trusting.
A run
The system was called and it finished.
An outcome
It met the definition in force when it ran. Under the built-in definition that only means the run succeeded; whether it did the thing you said it would do is what a definition you write has to check.
The difference
A run that completed and achieved nothing is still a run. Under the built-in definition it also counts as an outcome, because that definition checks only that the run succeeded; a definition you write is what tells the two apart. Billing as though every run were an outcome is how a client stops believing the numbers.
A run that failed
It finished, so it is a run and it is recorded. What it is not is billable: the meter you bill from counts only runs that succeeded, and a failure is written into the record as excluded, carrying the reason it was excluded, rather than quietly dropped. A run that timed out counts as a run and as neither a success nor a failure — the work may or may not have happened, and recording it as either would be a claim.
Where it goes wrong
Four counting traps, whatever you build with.
- One request is not one run. A system that calls three tools during a single conversation can record three billable executions, not one — check what your own platform counts before you quote a per-run price.
- A retry looks like new work. Delivery is unordered and providers retry; anything that counts naively counts the same work twice, and always in your favour, which is exactly why a client will not accept it.
- A green run is not a result. The complaint people describe most often is not an error — it is the execution that finished, reported success, and did nothing anybody wanted.
- Nothing recorded, nothing billable. Usage you did not record is usage you cannot charge for, and no amount of goodwill reconstructs it after the fact.
Where the line is
What Tolavo does not do here.
- Tolavo does not send the invoice. It keeps the record; the invoice is yours, on your own rail, and your client pays you directly.
- Tolavo never collects, holds or routes your client’s money, takes no cut, and has no mechanism that could.
- Outcomes are counted only from runs Tolavo recorded, against the definition in force before they ran: yours, or the built-in one until you publish your own. It does not reach into a system it was never called by and decide what worked.