When a retained turn settles with tokensKnown: false, the pool records the flag and debits 0 tokens. A turn that ran for 15 minutes of model time then costs the conserved pool nothing, and every sibling and descendant is budgeted as if that work never happened.
Measured
mech-interp-foundations-pi-20260915k, turn 1, from its spawn journal:
metered 2026-09-15T22:29:41Z in=0 out=0 ms=926150
RESULT 2026-09-15T22:29:41Z in=0 out=0 ms=926150 tokensKnown:false
mech-interp-foundations-pi-20260915l, turns 2 and 3: 0/0 ms=1693290 and 0/0 ms=846388, both tokensKnown:false. The sandbox's own done receipt for a comparable turn in the same run carried inputTokens: 73362, outputTokens: 44665. So each of these turns consumed on the order of 10^5 tokens and the pool charged none of them.
The immediate cause of the missing count is separate and fixed elsewhere (a stream break lost the terminal receipt; the runtime now resumes from the cursor). This issue is about what the pool does when a count is genuinely unavailable, because that will still happen.
What the pool does today
budget.ts documents tokensKnown on the readout as "tokensLeft is then a ceiling on what remains, not a measurement". That is correct as a description, but the debit itself is zero, so tokensLeft is not a ceiling on remaining budget; it is the unmodified prior balance. addSpend in util.ts carries the flag and adds 0.
The pool already has the right rule for the restore path. BudgetPoolRestore.uncertainReservations says: "Each uncertainReservation is a child that was recorded as started but never recorded as settled: its full declared ceiling is charged conservatively, while the public readout remains explicitly unknown." A settled turn whose count was lost is the same epistemic state as an unsettled child, and the same charge applies.
Proposed rule
When a settled Spend carries tokensKnown: false, debit the ceiling the work was admitted under (the node's perWorker.maxTokens, or its reservation) rather than the reported zero, and keep readout().tokensKnown = false exactly as now. This makes tokensLeft the ceiling the docs already claim it is, and it matches the restore precedent instead of inventing a new one.
The Discovery doctrine that consumes this pool states the invariant directly: "Missing measurements and unknown cost remain explicit; neither becomes zero or success."
Not proposed
Estimating the count from wall time or from a catalog price. The pool should charge a declared ceiling it can name, not a guess.
When a retained turn settles with
tokensKnown: false, the pool records the flag and debits 0 tokens. A turn that ran for 15 minutes of model time then costs the conserved pool nothing, and every sibling and descendant is budgeted as if that work never happened.Measured
mech-interp-foundations-pi-20260915k, turn 1, from its spawn journal:mech-interp-foundations-pi-20260915l, turns 2 and 3:0/0 ms=1693290and0/0 ms=846388, bothtokensKnown:false. The sandbox's owndonereceipt for a comparable turn in the same run carriedinputTokens: 73362, outputTokens: 44665. So each of these turns consumed on the order of 10^5 tokens and the pool charged none of them.The immediate cause of the missing count is separate and fixed elsewhere (a stream break lost the terminal receipt; the runtime now resumes from the cursor). This issue is about what the pool does when a count is genuinely unavailable, because that will still happen.
What the pool does today
budget.tsdocumentstokensKnownon the readout as "tokensLeft is then a ceiling on what remains, not a measurement". That is correct as a description, but the debit itself is zero, sotokensLeftis not a ceiling on remaining budget; it is the unmodified prior balance.addSpendinutil.tscarries the flag and adds0.The pool already has the right rule for the restore path.
BudgetPoolRestore.uncertainReservationssays: "Each uncertainReservation is a child that was recorded as started but never recorded as settled: its full declared ceiling is charged conservatively, while the public readout remains explicitly unknown." A settled turn whose count was lost is the same epistemic state as an unsettled child, and the same charge applies.Proposed rule
When a settled
SpendcarriestokensKnown: false, debit the ceiling the work was admitted under (the node'sperWorker.maxTokens, or its reservation) rather than the reported zero, and keepreadout().tokensKnown = falseexactly as now. This makestokensLeftthe ceiling the docs already claim it is, and it matches the restore precedent instead of inventing a new one.The Discovery doctrine that consumes this pool states the invariant directly: "Missing measurements and unknown cost remain explicit; neither becomes zero or success."
Not proposed
Estimating the count from wall time or from a catalog price. The pool should charge a declared ceiling it can name, not a guess.