An orchestration mode is a session-level switch: when it is on, the model puts maximum thoroughness behind every substantive request, scouting the task itself and then fanning work out to parallel subagents by default. When it is off, the same orchestration tool goes back to per-request opt-in.

The mode is not an API parameter. It is built entirely from documented pieces:

1. An effort level: requests run at a documented Effort value such as xhigh. There is no hidden level above the ones on that page. This example sets effort at the top level of each request, which needs no beta header.
2. A mode reminder: a mid-conversation system message tells the model the mode is active, with a one-line refresher every several turns and an exit notice when the mode is turned off. The top-level system field never changes, so the cached prefix stays intact.
3. Standing consent in the tool description: the orchestration tool's description states that while the mode is on, the model should author and run a workflow for every substantive task without asking first.

This example uses mid-conversation system messages; for the models and platforms that support them, see Mid-conversation system messages. The fan-out itself multiplies token usage: a single request can spawn many subagent conversations, so reserve the mode for work that justifies the cost.

本篇目录

• Set up the loop
• Define the mode reminders
• Grant standing consent in the tool description
• Run the bash tool locally
• Run one subagent
• Journal results so reruns resume
• Fan out, then verify
• Toggle the mode with mid-conversation system messages
• Run it
• Toward a production harness
• Related