What would you like?
Tighten budget ownership so each budget clearly belongs to one subsystem and old tool-shaped names do not linger after the tool surface changes.
The goal is to keep budgeting explicit while making the policy easier to reason about and maintain.
Motivation
The budgeting design is strong because it makes limits visible and host-owned, but some names still reflect older tool boundaries rather than current subsystem ownership.
That creates small drift risks and makes it harder to see which budgets are true subsystem policy versus leftover presentation or tool-specific detail.
Proposed approach
Keep the existing layered budgeting model, but normalize the naming and ownership so each budget maps cleanly to the subsystem that actually owns it.
Focus on clarity and consistency, not on adding a new configuration system or more budget knobs.
Scope
- tool output budgets
- lifecycle and prompt budgeting terminology
- config naming
- test defaults and trace summaries
What would you like?
Tighten budget ownership so each budget clearly belongs to one subsystem and old tool-shaped names do not linger after the tool surface changes.
The goal is to keep budgeting explicit while making the policy easier to reason about and maintain.
Motivation
The budgeting design is strong because it makes limits visible and host-owned, but some names still reflect older tool boundaries rather than current subsystem ownership.
That creates small drift risks and makes it harder to see which budgets are true subsystem policy versus leftover presentation or tool-specific detail.
Proposed approach
Keep the existing layered budgeting model, but normalize the naming and ownership so each budget maps cleanly to the subsystem that actually owns it.
Focus on clarity and consistency, not on adding a new configuration system or more budget knobs.
Scope