[Feature]: Allow switching between different coding agents (Claude, Codex, OpenCode, GrokBuild, Cursor)

[RedStar071]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

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

• I would be open to helping implement this.

[juliusmarminge]

Closing as a duplicate of #6757, which tracks switching an existing conversation to another provider while carrying its context forward. Provider selection for new threads is available; same-thread handoff remains tracked there.