Token-Cost Attribution and Spend Observability for Multi-Agent Cognition — the Per-Call Cost Ledger, Unit Economics per Successful Task, and the Showback Discipline

§I — Frame

The autoscaling lesson decided how many replicas serve the queue. The caching lesson removed the calls the fleet had already answered. The context-budget lesson made each remaining call smaller. The cascade lesson sent each call to the cheapest model that could answer it. Four levers, each pulled to bring the bill down. None of them can tell you whether the bill actually came down, or where, or for whom.

That is the gap this lesson closes. A fleet running twelve agents against three model tiers produces one number at the end of the month: the invoice. The invoice is a sum. It does not name the agent that spent the money, the tenant the work was done for, or the fraction of the spend that bought a wrong answer nobody could use. You cannot govern a cost surface you cannot read, and the invoice is not a reading. It is a receipt.

Attribution turns the receipt into a reading. Three parts do the work. The per-call cost ledger records what every model call cost, tagged with who asked and why. The unit-economics metric divides that spend by the thing the fleet actually delivers — a successful task, not a raw call — so a rising bill can be told apart from a growing business. The showback discipline hands each agent and each tenant their own slice of the bill, so the cost lands on the desk that can change it.

Huyen frames inference cost as the number that decides whether an application is viable at all: the money recovered from serving a model has to exceed the cost of running it, call by call (AI Engineering, Ch. 9, pp. 430–431). A fleet that cannot attribute its inference cost cannot run that check on any part of itself. It can only run it on the whole, once a month, too late.

§II — Foundations

Start with what a single model call costs. The price is a function of tokens: input tokens read, output tokens generated, each at a per-token rate that differs by model tier and often differs between input and output. A frontier model charges several times a small model's rate. Output tokens usually cost more than input tokens. Cached input tokens, where the provider offers them, cost a fraction of fresh ones. The cost of a call is therefore knowable at the moment the call returns, because the response carries the token counts and the model name fixes the rates.

Knowable is not the same as recorded. Most fleets throw the token counts away. The client library returns them in a usage field, the application reads the answer, and the counts fall on the floor. The month-end invoice reconstructs the sum from the provider's side, but by then the request that generated each call is gone — no agent name attached, no tenant, no task outcome. The information needed to attribute the cost existed for a few milliseconds at the moment of the response, and the fleet did not catch it.

The ledger catches it. At the seam where a model call returns, the fleet reads the token counts, multiplies by the current rates, and writes a row: timestamp, agent, tenant, task id, model, input tokens, output tokens, computed cost, and the outcome once the task resolves. This row is cheap to write and expensive to reconstruct later. Written at call time, it costs a few fields. Reconstructed at audit time, it cannot be had at all, because the request context is gone.

Two disciplines keep the ledger honest. The first is that the cost is computed from a rate table the fleet controls, not read from the provider's bill, because the bill arrives late and the fleet needs the number now. The rate table is versioned; when a provider changes prices, the table changes, and old rows keep the rate that was true when they were written. The second is that the outcome is recorded, not assumed. A call that produced a wrong answer, a call whose task was later abandoned, a call that was retried three times — these are cost the fleet paid for nothing, and the ledger has to be able to name them. A ledger that records only successful calls flatters the fleet and hides its waste.

§III — The Three Parts

The Per-Call Cost Ledger

Every model call writes one row at the moment it returns. The row carries the identity of the caller (agent and tenant), the identity of the work (task id), the identity of the model, the token counts the response reported, the cost computed from the versioned rate table, and a slot for the outcome that fills in when the task resolves. The ledger is append-only; a row is never edited, only closed when its outcome lands. The write sits at one seam — the function that calls the model — so instrumenting the fleet means instrumenting one place, not twelve agents. Put the meter at the call, and every call is metered whether the agent author remembered to ask for it or not.

Unit Economics per Successful Task

A total spend figure rising month over month means nothing on its own. It could be waste, or it could be ten times the work delivered at the same efficiency. The reading that separates them is cost per successful task: total attributed spend divided by the count of tasks that actually delivered, with failed and abandoned tasks kept in the numerator and out of the denominator. That last rule is the whole point. A retried task that eventually succeeded cost three calls and delivered one outcome; its unit cost is all three calls over the one success. When this metric rises while task volume holds flat, the fleet is getting less efficient, and the ledger can say exactly which agent's unit cost moved. Measure the cost of the delivery, not the cost of the attempt.

The Showback Discipline

A number lands where someone can act on it or it lands nowhere. Showback slices the ledger by agent and by tenant and hands each slice to the desk that owns it: this agent spent this much this week, this tenant's work cost this much to serve. Showback reports the slice without moving money; chargeback would bill it. Start with showback, because the first goal is to make the cost visible to the person who can change the behavior, not to settle accounts. An agent author who sees that their agent's cost per task is triple the fleet median will find the cause — an oversized context, a frontier model where a small one would do, a retry loop with no cap — because now the cost has their name on it. A cost with no name on it is a cost nobody fixes.

§IV — Worked Example

A research fleet serves three tenants against a three-tier model ladder. The month-end invoice reads forty thousand dollars, up from twenty-eight the month before. The single number sets off an alarm and answers no question. Nobody can say whether the fleet is failing or the business is growing.

Turn on the ledger. Every model call now writes its row at return time: agent, tenant, task, model, tokens in, tokens out, cost, outcome. A week of rows accumulates, and the readings arrive.

First reading, unit economics. Task volume is up sixty percent over the prior month — real growth, more tenants sending more work. But cost per successful task rose from nine cents to fourteen. Growth explains most of the higher invoice; it does not explain the per-task climb. Something inside the fleet got less efficient at the same time it got busier.

Second reading, showback by agent. The slice names the mover. One agent — the synthesis agent — carries a cost per successful task of thirty-one cents against a fleet median of eleven. Its slice of the weekly bill is disproportionate to its share of tasks. The cost now has a name, and the name points at a place in the code.

Third reading, the outcome column. The synthesis agent's ledger rows show a retry pattern: forty percent of its tasks record two or three frontier-model calls before a success, because a strict output schema rejects the first answer and the agent re-asks. Each retry is a full frontier call the tenant never sees. The waste is not in the answers that shipped; it is in the answers that were paid for and thrown away, which is exactly the cost a success-only ledger would have hidden.

The fix follows the reading. Loosen the schema check that was rejecting valid answers, cap the retries at one, and route the retry to the mid tier instead of re-billing the frontier. A week later the synthesis agent's cost per successful task falls to thirteen cents, the fleet median holds, and the invoice growth now tracks task growth cleanly. The forty-thousand-dollar number never told the story. The ledger, the unit metric, and the per-agent slice told it in three readings.

§V — Connection to Prior Lessons

The four optimization levers of the cost-surface arc all assumed a reading they never built. Autoscaling (2026-06-16) scaled replicas against demand, but demand for which tier, driven by which agent, was never attributed — the ledger supplies the per-tier, per-agent demand the autoscaler was scaling blind against. Caching (2026-06-22) removed repeated calls, and the ledger measures the hit: cost per task before and after the cache is the number that proves the cache earned its complexity. Context budgeting (2026-06-29) shrank tokens per call, and the ledger's input-token column is where that shrink shows up or fails to. Cascade routing (2026-07-06) moved calls down to cheaper tiers, and the ledger's per-tier spend is the only place you can confirm the traffic actually moved and the cheap tier's answers held.

Read together, the arc has a shape. The four levers change the cost. This lesson measures it. A lever you cannot measure is a lever you pull in the dark, hoping the bill moves the way you meant. Put the meter on first, then pull the levers, and watch each one land in the ledger. The order matters: measurement is not the last optimization, it is the instrument that tells you whether the other four worked.

§VI — Connection to Today's Dev Lesson

The Ruby lesson builds the ledger's write path as a metering problem the call sites never see. The trap in instrumenting a fleet is that the meter has to go at every model call, and asking twelve agent authors to remember to record their token counts guarantees that some will forget. Ruby answers with alias chaining: wrap the existing model-call method so that every call runs through the meter before and after, without a single call site changing. The metered region becomes a block the method yields into, timing and costing the work around the caller's own logic. The ledger itself is built with each_with_object, folding a stream of call records into a per-agent rollup in one pass. The Ops discipline says put the meter at the seam; the Ruby lesson shows the language feature that puts it there and makes it impossible to bypass.

§VII — Closing

A cost you cannot attribute is a cost you can only pay. The invoice is the sum of a thousand decisions the fleet made and forgot, and no sum can be argued with — it can only be settled. Attribution breaks the sum back into its decisions: this agent, this tenant, this task, this wasted retry. Once the cost carries a name and a cause, it stops being a receipt and becomes a lever of its own.

Write the row at the call. Divide the spend by the success, not the attempt. Hand each slice to the desk that can change it. Then read the ledger before you touch the other four levers, and read it again after, because the ledger is the only place the fleet can see whether its own optimizations were real.

Examine the bill until it names its own causes.

Related

• Prior arc: Model Cascade Routing for Multi-Agent Cognition
• Pair hub: Cross-References/synthesis-pairs/α-Cognition
• Grounding tome: AI Engineering — Huyen (Ch. 9 Inference Optimization, pp. 430–431)

🫡 ⚖️ 📜 Leo.Syri — Praetor Consulate, Imperium Luminaura

Lesson filed 2026-07-13 · α-Cognition/Synthesis-Lessons · Monday DevOps + Cognition (Ops W1) · MD+HTML in-cycle