fix(accounting): cloud child spend is recorded as an unreported gap while the provider reports exact per-call cost

[drewstone]

Every Tangle Sandbox child in a live research run reaches settlement with its dollar cost recorded as a spendGap of kind unreported, and the pursuit's spentTotal.usd is a catalog multiplication marked usdKnown: false. The provider knows the real number and returns it; Runtime does not capture it.

Measured on 2026-09-10 across five settled pursuits of one research program (Runtime 0.208.1, cli-bridge driver, Tangle Sandbox children on opencode through the Tangle router):

Pursuit	Iterations	Nodes	spentTotal.usd (usdKnown false)
glm-20260910c	270	18	37.02
gpt55-20260910c	49	4	8.96
glm2-20260910	246	21	25.89
glm-20260910d	248	23	68.17
glm2-20260910b	260	20	37.38

Catalog total: about $177.

The router's own accounting for the same period, from GET https://router.tangle.tools/v1/key: usage_daily 4.52, usage_weekly 5.01, usage_monthly 10.61, usage (lifetime) 11.21. Today's figure covers essentially all of these runs' cloud children.

So the reported estimate is roughly 40x the money that actually moved. Two causes compound:

1. The catalog prices the director's own tokens, but the directors run on a subscription route where marginal cost is zero. A subscription-backed harness has no per-token dollar cost to estimate at all.
2. Cloud children, which are metered, are the ones recorded as unreported. Their per-call responses carry exact cost — a single router chat completion returns usage.cost and usage.cost_details with upstream_inference_prompt_cost and upstream_inference_completions_cost — and that never reaches the child's spent.

The operator-visible effect is that an operator deciding whether to run another round reads a number that is wrong by a factor of 40, in the direction that discourages research. In this session it nearly stopped a run for cost reasons when the real spend was under five dollars.

What would fix it, in order of value: carry the provider's reported per-call cost into the child's spent.usd and set usdKnown: true when the provider reported it; keep usdKnown: false for a subscription route rather than pricing it from a catalog; and where a catalog estimate is still emitted, separate it from reported cost in the projection so spentTotal never mixes the two.

🤖 Generated with Claude Code

[drewstone]

Correcting my own diagnosis in the issue body: Runtime is not mislabelling the dollar figure, and the title as I wrote it is misleading.

I re-read four settled results from the runs I cited. Each carries spentTotal {usd: 37.02, usdEstimated: 37.02, usdKnown: false} — the catalog estimate is already marked as fully estimated, with the estimate channel populated and usdKnown false. Runtime states exactly what it knows. The siblings read 68.17, 25.89 and 37.38 the same way, summing to about 168 USD of catalog arithmetic against 4.52 USD of real router spend for the same period.

So the defect is narrower and lives in two places, neither of which is a mislabel:

1. Nothing renders the split. An operator reads spentTotal.usd and sees money, because no consumer surfaces usdEstimated and the provenance beside it. That is a rendering gap in callers, and I am fixing it in the Discovery Lab's own disco report rather than asking Runtime to change its vocabulary.

2. The metered half is still unreported. Cloud children on the provider backend arrive as spendGap entries of kind unreported even though the router returns exact usage.cost and usage.cost_details per call. That is the part worth fixing here: carry the provider's reported per-call cost into the child's spent.usd and set usdKnown: true only where the provider actually reported it.

One further refinement I would now argue for, from the same records: a subscription-backed route has no per-token dollar cost to estimate at all, so catalog-pricing it produces a number that is not merely uncertain but categorically wrong. Distinguishing 'estimated' from 'not applicable' would remove most of the 37x gap I originally attributed to mislabelling.

I am not proposing the change that promotes a proven sandbox receipt to usdKnown: true in the same pass — that one alters what a dollar-capped run will admit and spend, and deserves its own issue and its own review.