Many Agents, One Workflow: Providers and Capabilities
T3 Code’s provider problem is not how to display several model names in one picker. It is how to give different agent runtimes a shared control surface while preserving the account, session, permission, and tool behavior that makes each runtime what it is. This chapter separates provider kinds, configured instances, adapters, sessions, and capabilities so a reader can choose an agent for a real task without assuming that a common interface means identical execution.
A provider name is not an execution identity
A provider is the agent runtime T3 Code controls, such as Codex or Claude Code. But “Claude” or “Codex” is too broad to identify the work that will run. The same provider kind can have multiple accounts, configuration directories, endpoints, or permission settings. T3 Code therefore distinguishes a driver, which identifies an integration, from a provider instance, which identifies one configuration and account lifecycle.
That distinction protects state. If two accounts using the same driver shared mutable session or model-catalog state, a status refresh or login change for one account could affect the other. A thread could resume with the wrong identity, or a model list could appear available simply because a different account reported it. Treating an instance as a real execution identity keeps the provider’s credentials, session history, and configuration attached to the environment and account that own them.
The installation boundary follows the same logic. Provider command-line tools must be installed and authenticated on the machine running the T3 Code server, and their executables must be discoverable there unless a managed runtime or explicit binary path is used. A phone can open provider settings, but it cannot supply the missing executable on the remote host. T3 Code also warns when a provider version has known compatibility problems with its release. These are host and instance conditions, not client-display details.
The difference between an instance and a provider kind becomes especially important when an existing thread is continued. A thread is not just a transcript that any account can pick up. Its provider session may contain native conversation state, local configuration, or account-specific access. A switch is safe only when the relevant provider instances can share the state required for that continuation, or when T3 Code has a supported way to transfer the needed context.
What the adapter should—and should not—hide
T3 Code places provider-specific protocols, account ownership, permissions, and capabilities behind an adapter boundary. The adapter translates between the provider’s native messages and the control plane’s common operations. A user can therefore encounter concepts such as a thread, a turn, a question, an approval, or a model choice without the rest of the application containing separate branches for every provider.
The adapter is not a claim that the providers do the same things. It is a translation point with a limit. It can normalize the fact that an agent is starting work, streaming output, asking for approval, or ending a turn. It must preserve the native identifiers, request options, and capability differences needed to respond correctly. A provider’s approval option may not be interchangeable with another provider’s similarly named option.