> Orchestrator takes a dynamic, bidirectional approach between Carbon and Gemini 4 Hydrogen within the evolution of a single trajectory. For example, Carbon can start in a read-only phase to explore dependencies, resolve ambiguities, and build a concrete plan with explicit re-planning triggers. Hydrogen could then take over to write edits, update packages, and run tests. If Hydrogen hits friction, it would hand back to Carbon to inspect the state, repair the plan, and resume execution. This allows Orchestrator to reach near-Carbon task success while being faster and more quota-efficient. On Terminal-Bench 4.1, Orchestrator reached near-Carbon task success rates while, on average, consuming 24% less quota and completing 19% faster.

Is this now how e.g. Opus works now? I use Opus 5.5 on high for just about everything now, and my bill's not gone up (gone down actually). I had assumed under the hood it was doing this (e.g. I'm sure its not literally Opus doing the log checking / file searches). Towards Google's choice, I'm skeptical introducing a new concept (Orchestrator) for this is really necessary, when they could have just done it by default, unless its plainly lower quality than pinning Carbon.

In the CLI it usually wont spawn subagents.. 5.5 is just a bit more efficient than 5. In cowork mode it might do it.

My own implementation workflow is orchestrator based, but I generally dont use the small models because they're fucking morons

I found when fable first came out when I switched from opus my usage actually went down. Personal theory was that since it was smarter it took fewer tokens to accomplish the same tasks.