Personally tested it and it works! From now on, you have a smart model routing locally, which is fast and saves money. 💰 The model routing is working well this time. It has been upgraded from the "global fixed set" to dynamic selection according to the actual needs of the task. I made some local modifications without introducing Claude series models. You can DIY according to your own needs. The current process is roughly like this: User tasks come in → fireworks-goal-router makes the first judgment → selects the appropriate child route → codex-orchestration is responsible for delivery → dynamic-codex-workflow manages the status (pause and resume verification is fine) → Finally, Root accepts the integrated delivery. The responsibilities of each part are clearly divided: • fireworks-goal-router: responsible for the brain, deciding whether to split sub-tasks, which model to use, the level of effort, and what the role is • codex-orchestration: responsible for execution, throwing the task to the specified route • dynamic-codex-workflow: state persistence • Root: final check, checking the code, running tests, and delivering Compared with before: It was too rigid before - Advisor is always Sol, Executor is always Terra, a global set of executor routes, simple changes can also be implemented Multi-Agent processes are wasted. Now it is much more flexible: • Root can handle small changes by itself without opening child • Use Terra@medium for ordinary implementation • Call Sol@high only for architecture or high-risk matters • Special tasks can also specify model, provider, effort and role for child separately • Child uses fork_turns="none", only the smallest self-contained task package is given, the context is much cleaner, and Token is saved • Currently only OpenAI is enabled, and it will be expanded later. Practical benefits:
- The cost is easy to control, and simple tasks will not spend more money to "show off more agents".
- The model is used more accurately, Sol is responsible for planning review, and Terra is responsible for the specific implementation, and it is convenient to add models in the future.
- The subtask context is clean and does not inherit a lot of history.
- Auditing is convenient, with three-layer records of policy, route accepted, and actual used.
- Faults are easy to isolate. If a child hangs up, it will not drag down the whole. It can continue from the point of failure (this actual case encountered it)
- Root has clear responsibilities, and sub-outputs are just handoffs. Root is responsible for the final changes and testing, which is more like a formal engineering process. In short, the core of this change is dynamic model selection + strict boundary control + routing confirmation with actual evidence. In the future, no matter how complex the project is or whether we need to save costs, we can just continue to iterate on this level of control. Anyone who is also working on routing is welcome to chat~