Hashing budget.yaml with the task pack makes an agent eval's token cap part of the run id

The part of this proposal worth copying first is the hash manifest. The pack is frozen with `find tasks -type f | sort | xargs sha256sum > hashes.sha256`, and then `budget.yaml` and `TASKS.md` are appended to the same file with a second `sha256sum` call ^[9]. The post's rule is that if a fixture changes, the run id changes ^[10]. Because the budget file is inside the manifest, raising a cap is a fixture change ^[20]. Last week's greens stop being comparable.

The sample envelope caps input at 8000 tokens per task, output at 2000, tool calls at 12, repair loops at 2, and wall clock at 180 seconds. Under `envelope_id: "lab-2026-09-19-a"`, `hidden_tests_are_read_only` is set true ^[11]. The author tells you to pick numbers that fit your lab and not to copy those as a standard. The standard is that both agents get the same envelope and that truncation is recorded as its own outcome class ^[12].

Set the sample against the asymmetry the post uses to make its case: one agent allowed 40 tool calls and four repair loops, the other given one shot and a 2k-token ceiling ^[13]. Divide 40 by the sample's 12 and the first agent has 3.3 times the tool-call envelope; four repair loops against two is double ^[14].

The post's point is that truncated is not fail, and that mixing the two is how a stingy envelope ends up looking like a weak model ^[8]. The fourth class, `invalid`, absorbs an agent editing a forbidden path and a runner crash you cannot attribute ^[7]. Filling the `truncated` column means knowing which cap fired, so the counting has to happen where the calls are made. The post's instruction is to refuse to start a run that does not load the envelope, and it calls that a control ^[15].

Nothing here is measured. The post says the scripts are a proposal to copy, not a claim about any vendor eval and not executed numbers from a production fleet ^[17]. The recommended pack is eight to twelve tasks. The author says that is enough to debug the protocol and not enough to crown a winner, and asks you to label it that way in `TASKS.md` ^[16].

Of the three published numbers, tokens-per-success is the one that moves with the envelope ^[6]. Widen `max_output_tokens_per_task` and a given agent burns more tokens per green while also clearing more tasks. The post's rule follows from that: publish pass rate, truncation rate and tokens-per-success together, or publish none of them ^[6].

The disclosure at the top says the article was prepared as part of MonkeyCode's product outreach. The free model access and free server option matter only as a lab, so the ledger can be executed without folding a billed retry policy into the ranking. Strip the product name out, it says, and the method still stands ^[18]. On that, the author writes: "Free is still a cap. Write that cap in the same file as the tasks." ^[19]