A lighter normal run can hide the diagnostics and failed attempts needed to build it. Treating all development usage as the cost of one future run is equally misleading. The browser work record retains both intervals, and I preserve that separation in the account.
Read the final successful run as its own interval
The final successful run records one outer model request, 317,935 cache-inclusive total tokens and 623 uncached-input-plus-output tokens. Those values belong to the iteration in which the runner waited through the existing plugins. They neither erase previous failures nor form a fixed price for future repetitions.
Usage must be considered together with completion. A small count with an unverified result would not establish that the same work was accomplished. The final historical iteration verified new results and remained distinct from an earlier manually refreshed attempt. I retain that relationship while omitting account, publication and video identifiers from the public article.
Retain the sixty-six development and diagnostic requests
Development, diagnosis and earlier tests account for sixty-six outer requests, 16,415,813 total tokens and 162,757 uncached input plus output. Adding the final run yields sixty-seven requests, 16,733,748 total and 163,380 uncached plus output. The scope and arithmetic can be checked together.
I do not divide that development aggregate by one normal run and call it a savings rate. Development contains attempts to build a reusable route; a normal run uses the established procedure. Nor should development disappear from the report. Retaining both scopes lets a reader see what the maker tried in order to obtain the reusable result.
The start and end of measurement belong to the result
The historical report defines its interval from the user request through final verification, explicitly excluding subsequent aggregation, report writing, tower recording and final response. It is not the project's timeless lifetime cost. Stated exclusions also prevent double counting when a later record is added.
I do not retroactively insert usage from writing this article or building a new shared module into that historical development table. Another day's improvement is another interval. Repeated status reads of one run ID are not automatically repeated model calls; response counts and usage-receipt call sets need separate checks. No currency or subscription-percentage conversion is established here. Even in the same token unit, different time ranges and call sets remain different quantities.
Removing failures makes development resemble a clean run
Known usage from an errored request still belongs in the record. A development history made only from successful calls would hide parsing failures, obstruction and loading errors encountered before the fix. Unknown figures should remain unknown while failed status stays visible.
Historical accounting tests charge an identical measured-failure receipt once and avoid assigning an old response to a new task. Preserving failure is different from inflating counts through redelivery. Those tests belong to the retired internal-model design; I did not reactivate that runner for this article. Their useful lesson is attribution and completeness, not a current execution claim.
The value of reuse needs repeated conditions and outcomes
Repeated reuse can support a later assessment of how development effort pays back. One successful run and a token table cannot establish a break-even count or savings for every workflow. Maintenance, failures and changing conditions need subsequent records too. Future repetitions are not counted as already successful executions.
The shared ledger separates development from normal_run and refuses development samples in its comparison function. It is a synthetic record example, with no live provider collection or pricing. I retain both the reusable benefit and the work actually required to create it, so the figures remain intelligible without deleting either side of the story.