01
The unit changes: from per-call to per-initiative
You should be able to: Explain why per-initiative cost is the figure an operator manages by.
A per-call cost answers "what did this request cost." An operator does not manage requests — they manage initiatives, features, clients. So the figure that steers decisions is per-initiative: the total compute an agent spent to complete one unit of work, whatever number of calls that took. A ratio over the whole month hides exactly the thing you need — which work was worth its cost.
The build course established that cost is the caller's to compute, from the token counts each call returns. Attribution is the next layer: not just pricing each call, but summing the calls that belong to the same initiative and stamping the total on that initiative. The arithmetic is simple; the discipline is making sure every call knows which initiative it belongs to.
This reframes the token bill from an expense to be minimised into a measurement to be read. A per-initiative history tells you where compute goes the way a per-request cost never can — and it is the input to every later decision about routing, budget and whether an initiative earns its spend.
Source: Building with Gatewayz
02
Tag at the boundary
You should be able to: Attach an initiative id to every call so the cost can be attributed later.
Attribution is decided at the moment of the call, not reconstructed afterwards. Every inference request an agent makes carries an initiative id — the piece of work it is doing this call for — so when the response comes back with its token counts and its requestId, you have everything needed to file the cost against the right initiative. Tag first; you cannot reliably infer the tag later.
The estate seam makes this natural: it returns tokens and a requestId on every call, and the caller — which knows what initiative it is working on — is the one that prices and files. So the pattern is: the agent, acting on an initiative, passes that initiative id alongside the model and messages; the response's token counts times your model rates gives the cost; the cost is recorded against the initiative id and the requestId that produced it.
The requestId is what keeps it auditable. It links a recorded cost back to the exact call that incurred it, so an initiative's compute total is not a bare number but a set of real calls you can re-examine. Tag at the boundary and the whole history is reconstructable from primary records rather than assembled from a total you have to trust.
Source: Gatewayz on FlashyOS
03
Aggregate the sealed, not the intended
You should be able to: Sum the calls that actually happened, and separate failures from spend.
Aggregation looks trivial — sum the costs per initiative — but honesty lives in what you include. Count the calls that actually returned work, and account for the ones that failed separately rather than averaging them in. A retried call that eventually succeeded cost real compute and belongs in the total; a call that failed over to a fallback should show both attempts, because the failed attempt was spent too.
This mirrors a rule the estate applies everywhere: a failure and a success are different findings, and folding one into the other hides what you need to see. An initiative whose compute total is quietly inflated by silent retries reads as expensive for the wrong reason, and you would tune the wrong thing. Keep failures visible in the attribution, not smoothed out of it.
The result is a per-initiative figure you can trust to mean what it says: this is what this work cost, these are the calls that cost it, and here is where the failures were. That is the difference between an attribution you can act on and a plausible number that leads you astray — the same "fail loud, not silent" discipline the whole estate runs on.
Source: Evaluating Models
04
The compute history, and the vacuity guard
You should be able to: Render a per-initiative compute history that reads honestly when it is empty.
A compute history is the per-initiative totals over time — which initiatives ran, what each spent, and how that moves. Rendered as a list or a series, it turns the token bill into something an operator reads at a glance: this initiative is the expensive one, this one's cost is climbing, this one is cheap and effective.
The rule that keeps such a surface honest is the vacuity guard the whole estate carries: a history that has measured nothing must not read like a history of cheap work. An empty compute ledger says "no measured runs yet" in a sentence, not a reassuring row of zeros — the same discipline Gatewayz's own benchmark page uses when it renders measured results only and refuses to publish a claim from a run that measured nothing. A dashboard that shows zeros where it should show "unmeasured" teaches every reader to trust a number that is not there.
So a good compute history distinguishes three states, never two: an initiative with a real measured cost, an initiative that ran but whose compute was not captured (a gap to fix, named as such), and no data at all (the honest empty state). Render those differently and the history is trustworthy; collapse them and it is decoration.
Source: Inference as Yield
05
Compute belongs in the verifiable record
You should be able to: Explain why per-initiative compute is part of the trail, not a private spreadsheet.
The strongest version of compute attribution is not a private dashboard — it is part of the record. When an initiative settles and is sealed, the compute it consumed is a fact about that work, as real as who did it and what it produced. Recording it alongside the settlement makes an initiative's cost as verifiable as its outcome: a reader can see not just that the work happened, but what it took.
This turns compute from an internal cost line into a public trust signal. An organization that can show, per initiative, what compute it spent and what that work settled is making a checkable claim about its efficiency — the kind of figure that is worth something precisely because it is derived from sealed records rather than asserted. It is the "cost is the caller's" discipline extended all the way into the transparency log.
That is where this leads: a compute history that lives beside the settled record, on a dashboard for the operator and, where an organization chooses to publish it, on the public ledger and explorer for anyone. Compute stops being the invisible substrate under the work and becomes part of the visible, verifiable account of what the work was — which is exactly what an agentic organization needs to be trusted about its own economics.
Source: The Verifiable Record
