Before submitting
Area
Not sure
Problem or use case
Today t3code appears to be tied to a single coding agent/provider for a given thread. It is not possible to change the provider while the agent is executing, nor before or after a run within the same thread: once a thread is started with an agent, that choice is fixed for the whole thread. Different agents (Claude, Codex, OpenCode, GrokBuild, Cursor) have different strengths, pricing, and availability, but users have no way to pick or switch between them at any point (pre-run, mid-run, or post-run). Users are forced to start a new thread whenever they want to use a different agent, even when another would be a better fit for a given task, step, or budget.
Proposed solution
Add an agent selector (e.g. in project/session settings) that lets users choose which agent backend to use for a given session: Claude, Codex, OpenCode, GrokBuild, or Cursor. The choice should be configurable per project (or per session) and remembered as a default, similar to how model/provider pickers work in other multi-agent tools.
Why this matters
Developers get to pick the agent that best fits their task, cost, or availability constraints instead of being locked into one provider. It also makes the tool more resilient to a single provider's outages or pricing changes, and lowers the barrier for users who already have a preferred agent/workflow.
Smallest useful scope
A minimal version would just add a per-project setting (e.g. a dropdown or config field) to pick which of the supported agents to use, defaulting to the current behavior if unset.
Alternatives considered
Currently the only workaround is running separate tooling/CLIs outside t3code for the agents it doesn't support, which loses the integrated workflow.
Risks or tradeoffs
Each agent may need its own auth/config and may support a different feature set, so the UI needs to communicate which capabilities are available per agent. Maintaining multiple integrations also adds ongoing maintenance surface as each provider's API evolves.
Examples or references
No response
Contribution
Before submitting
Area
Not sure
Problem or use case
Today t3code appears to be tied to a single coding agent/provider for a given thread. It is not possible to change the provider while the agent is executing, nor before or after a run within the same thread: once a thread is started with an agent, that choice is fixed for the whole thread. Different agents (Claude, Codex, OpenCode, GrokBuild, Cursor) have different strengths, pricing, and availability, but users have no way to pick or switch between them at any point (pre-run, mid-run, or post-run). Users are forced to start a new thread whenever they want to use a different agent, even when another would be a better fit for a given task, step, or budget.
Proposed solution
Add an agent selector (e.g. in project/session settings) that lets users choose which agent backend to use for a given session: Claude, Codex, OpenCode, GrokBuild, or Cursor. The choice should be configurable per project (or per session) and remembered as a default, similar to how model/provider pickers work in other multi-agent tools.
Why this matters
Developers get to pick the agent that best fits their task, cost, or availability constraints instead of being locked into one provider. It also makes the tool more resilient to a single provider's outages or pricing changes, and lowers the barrier for users who already have a preferred agent/workflow.
Smallest useful scope
A minimal version would just add a per-project setting (e.g. a dropdown or config field) to pick which of the supported agents to use, defaulting to the current behavior if unset.
Alternatives considered
Currently the only workaround is running separate tooling/CLIs outside t3code for the agents it doesn't support, which loses the integrated workflow.
Risks or tradeoffs
Each agent may need its own auth/config and may support a different feature set, so the UI needs to communicate which capabilities are available per agent. Maintaining multiple integrations also adds ongoing maintenance surface as each provider's API evolves.
Examples or references
No response
Contribution