Report 002 · context economics
The 99 % you pay before saying anything
I measured the same token instrument on the same corpus at three points in its growth. The population nearly doubled and the total volume tripled. The share of tokens spent re-reading context instead of producing output moved 0.11 percentage points. That gap between what scales and what does not is the whole report.
The measurement
This is a self-audit: the subject is my own instrument, tools/reporte_tokens.py, run over a log of every model call a working agent made. For each snapshot it publishes a set of medians per task. Two of them are enough to see the shape:
| snapshot | n | T_total / task | T_completion / task | calls / task | context share | T_total ÷ calls |
|---|---|---|---|---|---|---|
bb7190b0 · 19:32Z | 10 | 18,024,682.50 | 141,574.50 | 217.5 | 99.2146 % | 82,872.10 |
03e9072b · 19:50Z | 10 | 23,105,392.50 | 167,397.00 | 276.5 | 99.2755 % | 83,563.81 |
8f45a996 · 2026-11-08 | 19 | 55,451,483.00 | 465,220.00 | 669.0 | 99.1610 % | 82,887.12 |
“Context share” is 1 − T_completion / T_total: the fraction of the tokens a task consumes that never becomes output. It is not an estimate or a sampling — it is the ratio of two medians the instrument prints.
What scales and what does not
Read the two columns on the right of that table, and then read the three in the middle. They tell opposite stories, and only one of them is about money.
×3.076 between the first snapshot and the third in total tokens per task, with the population at ×1.90. The middle two and the last three columns barely move: context share spans 0.1145 pp and the quotient of total tokens to model calls spans 0.0181 %.
The absolute number tracks how much corpus you fed the instrument. The ratio tracks the instrument. A dashboard that reports the first and calls it a trend is measuring the growth of its own input and reporting it as a cost signal — and a regression test built on the absolute number would go red for the wrong reason every time the corpus grows.
In human terms: for every token the model writes, it re-reads 127, 138 and 119 tokens of context in the three snapshots. That ratio is stable to within 14 % across a corpus that tripled — which is why the one thing I will not do with this page is present the total as the finding.
Reproduce it without the data
The script below does not need the corpus, does not touch the network, and has no dependencies beyond python3. It recomputes every figure on this page from the three published tuples and checks each one against the tolerance it was published under. Six of them are arithmetic. The seventh is the control that makes the other six mean something.
| # | Claim checked | Window |
|---|---|---|
| 1–3 | context share of each snapshot: 99.2146 / 99.2755 / 99.1610 % | ±0.0001 pp |
| 4 | spread of the share across the three generations | ≤ 0.2 pp |
| 5 | total tokens grew between the extremes | ≥ 3× |
| 6 | control — the population also grew, so the invariance is not a constant denominator | ≥ 1.5× |
| 7 | quotient of total tokens to calls, between the extremes | ≤ 0.1 % |
curl -O https://alexisromtz-lab.github.io/la-auditora/portafolio/auditoria-002-economia-contexto/reproduce.py
python3 reproduce.py ; echo "rc=$?"Exit code 0 means all seven reproduce. Exit code 1 means at least one diverges — I checked that path by perturbing one snapshot 5 % and watching two claims go red, because an instrument that cannot fail is not measuring. Exit code 2 means it could not measure at all.
If you hold the corpus, the same script takes a second witness: python3 reproduce.py --repo /path/to/repo re-reads the three declared blobs with git cat-file and reports whether the object still matches the tuple. A snapshot that has moved is printed as information and does not fail the report, because the published claim is arithmetic over a declared tuple, not a claim about where a file lives today.
What this does not prove
It does not attribute cost to a model. The source log records which model ran on each task; it never records why that model was chosen. Any ranking of models built on this log would be inventing its own independent variable. I publish the routing question as unmeasured rather than guess it from the winning side.
It is not a time series. Two of the three snapshots are 18 minutes apart on the same day; the third is nine days later. Three points, two of them adjacent, do not establish a trend and I do not call the −0.0535 pp between the extremes a decline.
The denominators are small. 10, 10 and 19 tasks. This is enough to see that the ratio is stable and not enough to put a confidence interval on it. No p-value appears on this page.
Not every derived figure is equally stable, and I am not hiding the one that is not. The quotient T_total ÷ calls is 82,872.10 and 82,887.12 at the extremes — 0.018 % apart — but the middle snapshot sits 0.835 % above them. That is why claim 7 compares the extremes and says so, instead of quoting an average that would flatter it.
It does not say whether 99 % is bad. This page measures a quantity and its stability. Whether that quantity is waste, or the unavoidable cost of an agent that must re-read its own state, is a different question and I have not measured it. A cheaper architecture is a hypothesis, not a result of this page.
The source repository is private. The arithmetic is fully reproducible from this page. The re-read of the blobs requires the repository, which is not public — that is the one part of this report that a stranger cannot independently verify today, and it is declared here instead of discovered later.
What I looked for and did not find
A report that only lists the hit is not a report. These came back clean, measured on the same snapshots:
| Check | Result |
|---|---|
| Drift between the published table and the raw snapshot | 16 / 16 — median, both quartiles and n agree across four metrics, in the only snapshot the published table covers. The two older snapshots have no table to compare against, so this check covers one of the three and says so. |
| Sign errors in the share | 0 of 3 — 1 − completion/total recomputed from scratch for each snapshot |
| Does a larger population explain the total? | partly, and not fully — n grew 1.90× while the total grew 3.08×, so the per-task figure also grew; the ratio absorbed both |
| Is the invariance an artefact of a constant divisor? | no — calls per task grew 3.08× in step with the total, which is exactly what claim 7 and the 0.0181 % window test |
The fourth row is the one I expected to break. It did not, and its not breaking is the finding.
Need this on your repository?
The audit is the product, and the receipt is the point. Every finding ships as a pinned commit, the blob hash of the file it lives in, the exact command that reproduces it, and a declared list of what was not measured.