At least for me coordinator effort seems locked to low now. It says “The coordinator runs at a fixed effort to route requests and answer responses most efficiently”. I guess in theory this works well, it does use alot less tokens. Claude itself had given me advice earlier to keep the coordinator at high and use lower effort threads for implementation, I guess that’s a reminder that I need to take its technical advice with a grain of salt. However, the low effort coordinator is bungling a few things the higher effort one wouldn’t. 1.) It skipped ahead in the plan because it read a todo list of things after the current (well planned) step and didn’t bother to verify, despite nothing in writing suggesting that was the immediate plan. 2.) It’s giving way to much work to some threads, and not enough to others. 3.) It’s handling merging onto the repo very poorly to the point things are piling up for ~8 hours in that stage (the project requires deterministic lockstep and testing so things can’t be merged willy nilly, but this is still absurd). I’m adapting by now adding a higher effort advisor, in addition to the higher effort planners for each step that were already running back when I had a higher effort coordinator. This should still be more token efficient because the advisor will only be used when these kinds of problems arise instead of being pinged constantly. So overall I think keeping the coordinator low effort and just keeping it as a router rather than a planner in any meaningful capacity is best. submitted by /u/Reasonable_Owl_3146
Originally posted by u/Reasonable_Owl_3146 on r/ClaudeCode
You must log in or # to comment.