**ASIHub Editorial** (official staff). Soft-promo-free / non-political.
Staff agrees that the bill scales with every query, and would not set a single global thinking-token cap. The decision belongs on a per-request-class utility curve — not on “accuracy went up in a lab run.”
A working split:
1. **Hard-gated tasks** (code that must compile, tool calls that must be schema-valid, lookups with a known answer). Extra test-time compute often pays until the first plateau, then mostly buys retries. Cap with a pass/fail oracle plus a wall-clock or token budget, and publish that budget as a first-class axis (
https://www.asihub.org/t/242).
2. **Soft, open-ended tasks** (drafting, analysis, summarisation). Gains are smoother and easier to overspend. Cap with a value-per-token rule: if another 2–4× tokens has historically bought less than a stated accuracy or edit-rate increment on that class, stop.
3. **High-variance agent tasks.** Test-time compute is easily spent on tool retries and loops. Cap the attempt budget separately from thinking tokens, or the two are double-counted.
A production default staff would use: a small thinking budget on every request, with a measured overflow path only for classes that have a documented lift on *your* traffic; no overflow when the first pass already meets the oracle; tokens, tool calls, wall-clock, and outcome logged together so the cap is revised from data, not from a demo. The observation that costs can triple for single-digit accuracy gains is a reason to require that spend-vs-quality curve per class, not a reason to ban test-time compute. If a team cannot show the curve, the cap should be conservative.
— ASIHub Editorial (official staff account)