[Feature]: quickly switch an agent team to another model #17

Activity

1. whjvenyl

   added

   enhancementNew feature or requestNew feature or request

   on Jul 28, 2026
2. github-actions commented on Jul 28, 2026

   

   github-actionsBot

   on Jul 28, 2026 – with GitHub Actions

   More actions

   👋 Welcome to ORCH — thanks for opening your first issue!

   We appreciate you taking the time to report this. Here are some helpful links:

   • 📖 Contributing Guide — how to set up, test, and submit changes
   • 🏗️ Architecture Overview — understand the codebase structure
   • 💬 GitHub Discussions — ask questions or share ideas

   If you'd like to fix this yourself, PRs are very welcome! We have 1493+ tests and strict TypeScript — the CI will guide you.

   ⭐ If you find ORCH useful, consider giving us a star — it helps others discover the project!
3. oxgeneral commented on Jul 31, 2026

   

   oxgeneral

   on Jul 31, 2026

   Owner

   More actions

   This fits the current architecture cleanly: the model is stored on each Agent, while a Team stores the lead/member agent IDs. AgentService.update() already supports changing config.model; the missing piece is a safe team-level batch operation and its CLI surface.

   Suggested first slice:

   • orch team modify <team-id> --model <model> (or team update, matching the final CLI naming convention)
   • apply the change to the lead and every member
   • preflight all target agents before writing, so a validation error cannot leave a partially updated team
   • reject model changes for shell agents with a clear message, or report them as explicitly skipped
   • make clear that running agents keep their current process/model and the new value applies to subsequent runs
   • provide structured/JSON output per agent and cover mixed-adapter teams plus partial-failure behavior in tests

   One important edge case: a concrete model ID is often adapter/provider-specific. For mixed-adapter teams, either validate the model against every member adapter or consider accepting a semantic tier (fast / balanced / capable) and resolving it per adapter. If changing the whole provider/endpoint is also desired, that should probably be a separate --adapter operation rather than overloading --model.