[FEATURE]: LLM Council support #4789

Activity

1. alexander-ivash-netwrix

   added

   discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion

   on Nov 26, 2025
2. github-actions commented on Nov 26, 2025

   

   github-actionsBot

   on Nov 26, 2025 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate or related to existing feature requests. Please check:

   • Can several commonly used models be specified in the configuration file? #3263: Can several commonly used models be specified in the configuration file? (task-based model routing)
   • [FEATURE]: custom model aliases #3439: [FEATURE]: custom model aliases (model aliasing for configuration)
   • [FEATURE]: Use a cheap model to name sessions #4133: [FEATURE]: Use a cheap model to name sessions (using different models for different purposes)

   These requests explore similar concepts around using multiple models strategically in different scenarios, which aligns with the council concept you're proposing.
3. dinhtruongng commented on Mar 5, 2026

   

   dinhtruongng

   on Mar 5, 2026

   More actions

   This would be very useful :)

   👍React with 👍1Reacted by makuchaku
4. makuchaku commented on Apr 6, 2026

   

   makuchaku

   on Apr 6, 2026

   More actions

   This is fully solvable with just /commands and subagents.
   Subagents : council_gpt, council_gemini
   /brainstorm => kicks off both agents, makes them debate with each other, summarizes into a final answer
5. thdxr

   assigned

   kitlangton

   on May 3, 2026
6. thdxr

   removed

   discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion

   on May 3, 2026
7. adndvlp commented on May 4, 2026

   

   adndvlp

   on May 4, 2026

   More actions

   I've been working on exactly this -- https://github.com/adndvlp/conclave, a fork of OpenCode that adds multi-LLM team debates. From the user side it's just /team to pick models, then every prompt goes through the debate automatically before anything gets implemented.

   Instead of the council model (parallel opinions -> anonymous review -> chairman), I went with structured debate rounds. Models talk directly to each other using explicit signals parsed from the last 5 lines of each response:

   LEAD:<reason>           -- take ownership
   SUPPORT:<name>:<reason> -- endorse someone
   CHALLENGE:<specific>    -- concrete objection  
   SYNTHESIZE:<X and Y>    -- merge proposals
   EXTEND:<reason>         -- vote for more rounds
   

   Minimum 2 rounds, winner by endorsement score (endorsements * 2 + leads), only the winner implements. The engine is packages/opencode/src/team/.

   Some things I ran into:

   • Free models work for debate, not implementation -- Gemini Flash debating at 1024 tokens with temp 0.2 is fine. But you don't want it writing the code. The team converges on a winner and that winner alone gets the full tool suite. This matches the subagent idea @makuchaku mentioned, but instead of /commands it's built into the session flow.
   • CLI bridging removes the API key problem entirely -- if you've got gemini-cli or claude-code installed, they join teams using their existing auth. Those CLIs show up as cli-gemini, cli-claude, cli-codex provider IDs in team config. Mix API and CLI models in the same team.
   • Breaking teams is where this gets different from council -- models can vote BREAK to split into sub-teams (backend, frontend, auth, etc). Each sub-team debates internally then implements its own piece, simultaneously. Instead of one chairman producing all output, you get parallel code generation across teams. Three phases: decision round -> sub-team formation with invite resolution -> parallel internal debates with global coordination rounds where teams broadcast dependencies to each other. Simultaneous editing works today as long as teams touch different files. The bigger idea would be same-file parallel edits -- multiple LLMs modifying different sections of the same file simultaneously, with automatic merge of non-conflicting changes and conflict escalation only when they actually overlap on the same lines.
   • Context window handling -- each model gets the thread truncated to 25% of its context limit. Models with 1M tokens see the full debate; small-context models get signal-only summaries. Without this you hit constant overflows.
   • Regex parsing works fine -- I was worried models wouldn't follow the signal format, but with explicit prompt instructions they're pretty reliable. Simpler than adding another LLM call as judge, and works for CLI subprocesses too (which can't do structured output).

   Only 5 new files on top of OpenCode (team/debate.ts, team.ts, prompts.ts, cli-adapter.ts, schema.ts) plus small changes to session/prompt.ts and session/processor.ts for the integration points.

   Biggest pain point honestly was the session status streaming -- showing live per-model reasoning during debate rounds without killing the TUI performance. Ended up with a 250ms debounce on participant text chunks and it still gets janky with 4+ models. Happy to share that part if it's useful.

   👍React with 👍1Reacted by Josué Miguel Aguilar Polo
8. github-actions commented on Jul 5, 2026

   

   github-actionsBot

   on Jul 5, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
9. github-actions

   closed this as not plannedon Jul 5, 2026