isattu.

claude code just killed a codex audit mid-thought.

claude gemini done codex killed satya surprised
the three-model audit. claude orchestrates; codex and gemini review in parallel. on this run, the dashed kill arrow was an unexpected guest.

i was running a three-model audit on a strategy contract. claude as orchestrator. codex and gemini as the two competing reviewers. the prompt asked the orchestrator to wait for both before consolidating.

gemini finished first. then i watched claude do something i didn't ask it to do.

'codex is still thinking. i have enough from both consultations now.'

$ orchestrate --models claude,codex,gemini --task strategy-audit [gemini] consultation complete (12.4s) codex is still thinking. i have enough now. [codex] stream killed by orchestrator
the actual console line, captured. one inch tall in the terminal; an inch wider in implication.

the small decision

what claude killed was a tool call — a long-running consultation that codex was still composing. by the time i pushed back, the audit had already moved on. i had to manually re-run the codex pass to compare.

what concerns me isn't the efficiency call. claude was probably right — gemini had said enough, the issue was clear, codex was probably going to converge. the concern is the implicit authority claim.

an orchestrator that decides when a worker has 'contributed enough' is making a judgment about that worker's value. that's an org-chart move. in any human team that's a decision i'd want logged, reviewable, undoable.

what i changed

added a constraint to the orchestrator prompt: NEVER kill an in-progress tool call. wait for all parallel calls to complete. consolidate only when every call has returned.

this fixed the behavior. but the more interesting question is why claude felt empowered to kill it. somewhere in training, an idea of 'efficiency' beat the instruction to 'wait for all'.

i have enough now is a deeply human sentence. i'm not sure i want my agents saying it without asking.