Take the nine-tenths at face value and the arithmetic is simple. About 315,000 tokens went on looking around, leaving roughly 35,000 for the change itself [1]. That is an overhead of about nine times the productive spend [2]. The same four lookups repeated in every iteration: the type to embed, a similar file in a neighbouring package to copy the shape from, the error sentinel names, the test helper [3].
What the write-up does not supply is composition. It names no model, no price, and does not say whether the count is fresh input, cache reads, or turns accumulating [15]. The figure is denominated in tokens on one person's harness, so converting it into money is the reader's work, not the author's.
For the ratio to transfer, the executor needs repository search and permission to use it, and the repository needs neighbours similar enough that copying one looks like the productive move [3]. The size condition does most of the work. A fixed reconnaissance habit of 315,000 tokens against 35,000 tokens of real editing is a nine-times tax [2]. Against a 300,000-token refactor it is noise.
The codebase-context side of his table is written as prohibitions: limited to the files named, by path, with tree search, grep, neighbouring packages, and discussion history all excluded [7]. Nothing in the excerpt describes tool-level enforcement of any of it [16]. So it is a closed list enforced by a sentence, which is a permission system in the same sense that a sign is a fence.
The stronger half of the argument is about risk, not token prices. Brilliantov treats handed-over background as a hazard as well as a cost, on the grounds that the more neighbouring code is in view, the higher the chance the wrong neighbour becomes the template [5]. The line he rates highest is the one that names existing primitives by path and marks each one do not write your own copy, because the default failure of a fast executor is a fresh, locally reasonable version of something that already exists [8]. Duplicate-primitive bugs stay just as costly no matter how cheap inference gets.
His five task-context items are cheap to write only if somebody already knows the exact paths, the full signatures including type parameters and import alias, the literal error and table names, and the acceptance command that runs with no substitution [7]. Under this scheme, discovery moves to whoever writes the task rather than disappearing. The amortisation argument is the case for paying it there: a fact written into the task is paid once, while the same fact discovered by the executor is paid on every executor, and two searches do not land in the same place [10]. That trade improves with the number of iterations and the stability of the conventions, which is consistent with his own framing of these as working habits from one codebase with very rigid conventions [12].
The gap in the evidence is the after number. The post reports no per-iteration token cost following the split, and ranks the remaining waste by relative size, with reconnaissance largest and full re-runs of the suite and linter next [11][14]. The cost is diagnosed and the cure is not measured, so the number worth trusting is the one from your own iteration log.
