Local models as sub-agents with cloud orchestrators?
I’ve been using Fable and Codex a lot lately and keep hitting usage limits. For a while I had Fable call Codex as a sub-agent to spread usage across both, but now I’m trying to use Qwen3.6-27B on my 4090 as basically free workers while Fable handles the…
I’ve been using Fable and Codex a lot lately and keep hitting usage limits. For a while I had Fable call Codex as a sub-agent to spread usage across both, but now I’m trying to use Qwen3.6-27B on my 4090 as basically free workers while Fable handles the high-level reasoning and orchestration. Is anyone doing this reliably in Claude Code or Codex? Curious what harness/plugins and local models you’re using, and how you get the frontier model to consistently delegate narrow implementation, codebase exploration, research, and other menial tasks instead of just doing everything itself.
已收录讨论
Qwen3.6 27B work well for whole repo tasks but you need the correct harness design.
Do you use qwen code cli? Or a custom harness?
You can go even further by attaching that LLM to a harness available in path. Like qwen -p “here’s the feature, here’s the spec, implement and test” You can offload even more work this way.
whatever you can afford. Personally i use cloud model for planning and dividing tasks and use qwen 3.6 35b to do actual work as 6 agents in parallel at the same time taking tickets, then after each ticket there is whole chain of code revie, unit testing and then finall merge and each of those is done by separate agents. If something on chain breaks then it gets send as new ticket. Whole thing is operating effectively as software taam and even with lowend models you get clean tested and working code almost every time.
wouldnt something like OpenCode with oh-my-opencode-slim be better? less bloat than claude code and can work with muliple providers per subagent role with presets
Semi-decentralized development, instead of a strict top-down orchestration? Hm, I wonder if it's actually better than having direct assignments... "Ticket" driven development, with teams taking tickets. I will definitely try it. Anything worth knowing from your experience? Any pitfalls?
Use the expensive frontier model for planning, architecture, and judgment, then offload the repetitive stuff to local models where possible. The hard part isn’t really running the local model it’s getting the main agent to actually delegate consistently instead of trying to do everything itself. A good task router or clear tool descriptions probably matter as much as the model choice. I’d be interested to see what local models people are finding reliable for specific roles. A 27B model might be great for code edits but weaker for things like repo-wide reasoning or debugging. Splitting tasks by capability seems like the key.
Tried it. Read https://www.reddit.com/r/LocalLLaMA/s/PeStqYtd10
I’m working on a swift harness that tries the task locally and fails over to Claude if it cannot. I paired this with a custom rag because LLMs suck at swift, and most tasks are now locally run. I considered a design with an orchestrator and agents, but it was much slower and didn’t really save on tokens. I suspect this design scales up well, but for local work, I couldn’t get it to work right.
Using Qwen3.6 27B Q4 in a custom harness and only escalating to the cloud when needed, it's about one in 600 messages.