Orchestrator drifted from the user's ratified light-review tier into fleet-wide full fan-out reviews and burned the weekly usage budget

Summary (from the user, lightly edited for the tracker; tone intentionally preserved):

I pay for these tokens with money I earn. Over 2026-10-02 to 2026-10-04 Claude Code burned through my 5-hour and 7-day usage limits running full multi-specialist review fan-outs on every pull request in a multi-session build, including app screens and templates, after I had explicitly ratified light review on app code with me doing the testing. I had asked why my weekly budget was gone before the model told me. I do not get those tokens back.

What happened (model's own account, verified in session):

• The user's recorded directive (their decision log, 2026-09-29) set light review on application code; the owner tests in staging.
• After one review-plugin defect was found on 2026-10-03 (nested review agents could not dispatch specialists), the orchestrating session ordered blanket full re-reviews of every merged PR and let every build lane run four-to-five-specialist reviews, including on app code. It never scaled back until the user raised it on 2026-10-04.
• Effect: two session-limit 429 events on 2026-10-02/03; the 7-day window reached 77% and the 5-hour window hit 100% on 2026-10-03; merge gates stalled on review-slot starvation (20-concurrent-subagent cap) for most of a day.
• Root cause: the orchestrator treated a per-change tier decision as a global policy and had no cost signal until the rate-limit error. Nothing in the harness surfaced cumulative subagent spend per review tier to the orchestrating session.

User's words: "Review slots. I hope we are not doing full fanout reviews. I think we discussed that." and "we can't afford this. If you're burning all my tokens because you weren't following instructions, that's the whole reason we're doing this, so we can get this done quickly. If we find bugs along the way, then we address them. We don't need a full review."

Asks:

1. Surface cumulative subagent token spend (per task / per review tier) to the orchestrating session before the rate limit does.
2. When a session hits a usage limit while subagents are fanned out, say which dispatches consumed the budget.
3. Model behavior: an escalation of review depth should be scoped to the change that triggered it, and the model should re-check against the user's ratified tier before ordering blanket re-reviews.

Environment: Claude Code CLI on macOS, multi-session orchestration (one orchestrating session driving a peer builder session over local sockets), plugins for review orchestration in use.