A successful improved run with lower usage is useful evidence. It still does not promise the same reduction for every task. The browser records contain both sequential and interleaved comparisons, which let me separate what each measurement can actually support.
First check that equivalent work was accomplished
If the improved path does less work, fewer tokens do not establish efficiency for the original task. The public-page comparison supplied the same fresh reference and objective, then checked actual title/link extraction and the final response. Size-only offline auditing remained separate from verification of the business result.
The delivery comparison verified the same kind of registration and private result while using new artifacts per run. Reused receipts were not counted as new transfers. Matching the objective and result is a starting point; it does not also equalize cache or conversation length. Outcome equivalence and experimental-condition equivalence require separate checks.
Sequential comparisons retain an execution-order effect
The earlier and final compact runs differ in outer request count, execution route, accumulated context and cache state. The arithmetic change from 1,073,497 to 317,935 is valid for those samples, but is not a fixed product savings rate. The code can still explain which waiting layer changed.
Small input/output and local polling counts support the structural account; they do not isolate its exact causal contribution in a controlled experiment. Execution order, cache hits and response length can affect usage too. I retain the actual figures while stating which further questions those figures cannot answer, instead of either exaggerating or discarding the observation.
Interleaving helps, but the sample remains small
The version 0.1.117 screen-summary comparison ran baseline, improved, improved, baseline. Each execution made two model calls for actual extraction and final response. The two-run totals were 134,088 and 127,694, a sample reduction of about 4.77 percent. Interleaving was a separate attempt to reduce one-sided ordering bias.
Cache and generated length were still not fully fixed. The result is not an average over every site's writing, upload or authentication wait. It is a small successful sample of one reading task. I do not mix the later 0.1.118 instruction/schema figures into it as additional equivalent samples, because the changed component and execution conditions differ.
Deleting failed early comparisons changes the interpretation
Earlier screen-summary records retain an initial implementation that bypassed the size gate and increased usage, followed by a revision that lost fresh references and failed to finish. Reading only the final success would hide the constraint that had been broken. An optimization label did not make every iteration smaller and correct.
The fixes changed summarization order and canonical fresh-snapshot selection rather than raising limits or allowing stale references. This article reviews historical documentation and selected code without repeating the original model calls. Failed-development usage and final performance samples also retain different accounting scopes, so correction history does not become either invisible or a misleading performance denominator.
Write down what the next experiment changes and preserves
A new comparison should state objective and success criteria, model/settings, input artifacts, order, call count, cache and total tokens. When a condition cannot be fixed, record that limitation. Runs with unverified results must not quietly enter or disappear from a denominator labelled successful execution.
The shared ledger calculates arithmetic differences for complete metrics while leaving controlled-experiment verification and general-savings guarantees False. It makes no recommendation that a model is always cheaper. Publishing the conditions alongside the figures lets another maker design a better experiment. A useful sample does not need an inflated promise to remain useful.