Reserve 100, charge 130: what a shared token ledger actually bounds
A reservation stops at 100, yet a subsequent actual-usage charge can be 130: the ledger accepts the charge and records an overrun of 30. This was a synthetic input in our same-day internal source-code experiment, not an observed provider overrun. It separates two questions often combined in budget evaluation: how much the system permits callers to reserve, and how much the provider ultimately produces.
At the interface we executed, those are separate mechanisms. A reservation limit is not an actual-output cap. The ledger can constrain shared reservations and preserve an accurate overrun record without making an external provider obey a requested cap.
From requested allowance to actual charge
Analysis used the complete retrieved 111-line ledger module, pinned by content hash. The code uses one lock for reservations, charges provider-reported actual usage, releases failed calls and records overruns. It comes from the public code accompanying a study of multi-agent budget comparisons.[1][2]
Internal probes ran locally under Python 3.13.15, with expected outputs encoded before execution. Seven checks covered distinct responsibilities:[3]
- Sequential requests for 80 and 80 received 80 and 20 under a limit of 100.
- A further request for 1 was denied after exhaustion.
- Releasing 20 and charging actual usage of 50 left spent=50, reserved=0, remaining=50 and overrun=0.
- Reserving 100 and submitting synthetic actual usage of 130 left spent=130, reserved=0, remaining=0, exhausted=true and overrun=30.
- Missing usage was rejected; a separate check recognized the output-token count alias.
- Eight threads requesting 30 each produced total reservations of 100 in every one of twenty rounds.
Missing usage and the alias were separate checks within the total of seven. Concurrency results show no reservation overshoot under those observed schedules, rather than proving every possible interleaving safe. The 130-token charge was supplied by the test and cannot estimate provider-overrun prevalence.[3]
Stopping allocation cannot undo output already produced
Denying subsequent reservations can prevent new commitments; it cannot reclaim output that already exists. Accepting an actual charge of 130 while recording an overrun preserves spending visibility. Calling this simply a failed budget would discard evidence that reservation control worked. Calling the successful reservation checks an end-to-end hard cap would exceed their scope.
Our interpretation is that budget comparisons should examine reservation exclusion, requested provider caps, returned actual usage, overrun handling and whether each architecture executed as intended. This experiment directly executed only the local ledger: no models, provider routes or complete task trajectories ran.
Accounting also cannot substitute for object fidelity. Another mechanism in the Research Object compares issued and executed writes, which concern a different object from token usage. Whether recording a mismatch prevents execution requires examining that path; a record does not establish a block.[1][2]
Why paper outcomes do not become an architecture ranking
The study authors report that no cell met the preregistered 90% write-as-issued fidelity bar. Their stricter audit reports 680/2744, about 25%. Mechanically valid cells therefore cannot simply be described as architecture-fidelity-valid cells.[1, section 4.1 and Table 6]
The authors also report positive gain for one near-threshold cell under a second simulator. The interval for the between-simulator change crosses zero, without multiplicity correction. This limits a claim of no gain under any conditions; it does not establish a different universal conclusion. Wide capability-slope intervals leave the relationship unresolved. A descriptive concentration of loss in exhausted episodes does not identify its cause.[1, sections 4.3–4.6]
These qualifications do not remove the value of the isolated ledger experiment. They locate that value at a budget interface, rather than in reproducing multi-agent accuracy, explaining the paper's losses or ranking all agent architectures.
Evidence and sources
Source facts establish the module's mechanisms. Author-reported results retain the authors' experimental scope. Our internal experiment establishes only outputs from local synthetic inputs and concurrency probes. No independent third-party reproduction of the same claim was established; internal evidence is not independent validation. Publication, citation and peer review do not automatically establish correctness, and implementation success does not establish general validity.
- Multi-agent budget-comparison study, version 1, study authors, research paper; same-day admitted reading, especially sections 4.1 and 4.3–4.6. Fidelity, simulator and statistical findings remain author-reported.
- Public study code, project maintainers, code; retrieved
completion_budget.py, 111 lines. A content hash pins the local extraction; no immutable commit equivalent to the paper's evaluation deployment was verified. - Same-day internal Analysis probes: the literal module, seven checks, twenty concurrency-round outputs, execution record and source-content hashes accompany the Research Object. No model or benchmark ran.
The missing evidence is the complete call path
The next question is how the complete serving path handles a provider ignoring requested caps, and how overruns enter budget matching and validity filtering. The study's schema-visibility correction received only a small check rather than a full-grid rerun. Its prose and methods also describe that check's tasks inconsistently; they cannot silently be assembled into a complete replication.[1]
Until that evidence is available, the demonstrated reservation control and overrun accounting can stand on their own. Provider compliance, architecture fidelity and comparative outcomes still require separate judgments.