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

[whjvenyl]

Problem Description

i'm frustrated to have to switch each individual agent in a team to another llm if an endpoint reports as exhausted. i'd like to be able to switch a team fast to another model

Proposed Solution

orch team modify --model openai/claude-super-x

Alternatives Considered

No response

Area

CLI commands

Additional Context

No response

Contribution

• I'm willing to submit a PR for this feature.

[github-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!

[oxgeneral]

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.