Two complaints about coding agents sound unrelated until you line them up. One: you ask for a route recommendation and the agent starts scaffolding entire apps you never requested, spending your daily quota on work you did not want. Two: you kick off a code review and the agent spawns twenty-five sub-agents and runs for over four hours. Different surfaces, identical root cause — the agent decided how much to spend, and you found out afterward.

That is the wrong order. By the time you see the bill, the quota is gone and the sub-agents have finished. The decision that mattered — how much effort this task is worth — was made by the agent, in the moment, with no ceiling. The fix is not a better model or a bigger plan. It is moving that decision to before the run, where it belongs.

The tier debate misses the point

A lot of energy goes into comparing plans: this Max tier against that Plus tier, which one lasts longer for CLI coding, which runs out too fast. The comparison is real, but it treats the symptom. A bigger bucket of quota still drains if the agent is free to spend it on whatever it decides is interesting. You are choosing how much to hand an actor with no spending discipline, and a larger allowance does not impose discipline — it just delays the wall.

The useful question is not "which tier gives me more headroom." It is "how do I stop the agent from spending headroom on work I did not authorize." Those are different problems, and only the second one actually fixes the runaway-cost experience.

Unrequested work is a scope failure with a price tag

When an agent answers "recommend a route" by building apps, two things went wrong at once. It exceeded the request, and it spent real resources doing it. The scope violation and the cost are the same event. This is why budget control and action control belong together: a ceiling on spend is weak if the agent can still choose expensive, unrequested work; a ceiling on action is incomplete if it does not also cap the cost of the actions it allows.

What you want is a contract before the run: this is the task, this is the most you may spend, these are the actions you may take. The agent operates inside that envelope or it stops and asks. The envelope is set by the human, in advance, when the stakes are understood — not improvised by the model mid-task.

Concurrency is its own budget

The twenty-five-agent review is a specific and underappreciated failure: runaway concurrency. Review and analysis tasks fan out naturally, and without a cap they fan out enormously, each sub-agent consuming quota in parallel. The four-hour review was not one expensive decision; it was the absence of a limit on how many parallel decisions the agent was allowed to make.

So budget has more than one axis. There is total spend, and there is concurrency — how many agents may run at once. A serious control layer caps both, because a task that is cheap per-agent can still be ruinous at twenty-five-way parallelism. The ceiling has to cover the fan-out, not just the single thread.

Hooks already point at the answer

The most practical signal in all of this is that the building blocks already exist and are underused. Coding agents expose hook events — stopping conditions, permission rules, gates that fire before tools run — that almost nobody wires up. Those hooks are exactly where a budget becomes enforceable: a place to assert "stop here," "do not exceed this," "ask before that," before the agent acts rather than after.

The pattern that emerges is a cockpit set up before launch: a spend ceiling, an action scope, a concurrency cap, and stop conditions, all decided while you still have leverage. Run the agent inside that and the runaway bill stops being possible. Decide it afterward and you are just reading the receipt for work you never approved.