T3 Coder uses the Codex, Claude Code, Pi, and Kilo Code installations already available in the connected Coder workspace. It does not run a provider on the local computer, install a missing provider in the workspace, or copy provider credentials between them.
This fork supports API-backed usage only. Subscription-backed ChatGPT and Claude consumer plans are outside the supported product scope. This describes the supported configuration, rather than a runtime check that rejects every other authentication mode.
Each provider is checked independently.
| Status | What it means |
|---|---|
| Ready | The CLI responded, its authentication is usable, and it can contribute models. |
| Unauthenticated | The CLI is installed, but you must sign in inside the workspace before using it. |
| Unavailable | The CLI is missing, disabled, incompatible, or could not be checked. |
Only ready providers contribute models to the model picker. An unavailable provider remains visible with an explanation where that context is useful, but it cannot be selected for new work.
Only one provider needs to be installed for the workspace to connect. If one provider is unavailable, the others that are ready continue to work. There is no automatic mid-thread or mid-turn fallback. Existing work remains tied to its provider so T3 Coder does not silently change agent behavior or conversation history.
Configure API access through the workspace's Codex, Claude Code, Pi, or Kilo Code configuration and your organization's credential-management process. Credentials belong in the workspace provider configuration, never in T3 Coder's browser or local gateway. T3 Coder does not collect API keys.
Reconnect after updating authentication so provider status and capabilities are checked again.
The model picker is capability-driven rather than a hard-coded compatibility list:
- Codex models, reasoning choices, and service tiers come from the workspace Codex app server.
- Claude models and supported access modes come from the workspace Claude Code installation.
- Pi models and thinking levels come from the workspace Pi installation; see Pi.
- Kilo Code models and options come from the workspace Kilo Code installation; see Kilo Code.
- A model appears only while its provider is ready.
- The current and older model sections follow the upstream model lifecycle list bundled with the T3 Coder release.
- Existing threads retain their recorded provider and model selection unless the user explicitly changes a supported option.
The access menu follows the same principle. It shows the modes supported by the selected provider and model. Workspace Codex configuration requirements can restrict which modes are offered.
See Access modes for what each mode means.
Type / in the composer to search available commands. Type $ to search available skills.
T3 Coder uses the inventory reported by the selected workspace provider and project, so the list
can differ between Codex, Claude, Pi, and Kilo Code or between workspaces.
Codex sub-agent activity includes model and reasoning information when Codex reports it. T3 Coder leaves missing metadata blank rather than copying the parent agent's settings.
Codex can also surface asynchronous questions while it continues working. Answering one records
the resolution and starts a follow-up message in the same thread; unanswered questions remain
available even after a long activity history. Dismiss an asynchronous question to close it without
sending anything to Codex; blocking questions still require an answer or interruption. Context compaction is available for both Codex and
Claude through the /compact command.
You can paste PNG, JPEG, or WebP images into a message. T3 Coder validates and places them in its workspace attachment area. Codex receives validated images as native image input. This exception does not enable general file uploads.
T3-managed Codex and Claude sessions use the MCP servers and Codex app integrations configured in the workspace, as upstream does. When a Codex MCP server asks for confirmation, T3 Coder shows it as an approval request. The Claude browser integration is disabled.
Codex, Claude, Pi, and Kilo Code can still use T3 Coder's own tools: delegating work to child agents, reading and messaging other threads, managing the queue and pending questions, scheduling recurring tasks, launching threads in worktrees, managing projects, linking merge requests, and sending workspace files and images to other threads in the same workspace. Instead of an MCP server, T3 gives each provider session a workspace command that runs these tools and removes it when the session stops. In plan mode, agents can use only the tools that read state. Browser preview and device tools are not available.
The Providers page always shows which workspace you are editing. On the first visit it selects the workspace from your current conversation when possible, otherwise the first configured workspace. It remembers an explicit selection while T3 Coder remains open and lets you switch workspaces at any time. A stopped or unavailable workspace remains selected and must be started from Coder connections before its provider settings can be read or changed.
Provider configuration and text-generation defaults are stored in the selected workspace. Model favorites, hidden models, and model ordering are browser preferences shared by every workspace.
The default Codex, Claude, Pi, and Kilo Code settings use the workspace's standard executables, provider homes, and existing API authentication. Most users should leave them unchanged. Each provider can be enabled or disabled independently.
Additional provider instances let a workspace expose another Codex, Claude, Pi, or Kilo Code installation, identity, or configuration without replacing the default. The same settings experience is used for every provider, while each provider shows only the choices it supports.
The Models section also lets you add, edit, and remove custom model IDs, give them display names, and configure the controls exposed for those models. Existing custom model IDs remain valid without conversion. These definitions are stored in the selected workspace; they do not install a model or grant access to one that the workspace provider cannot use.
These settings change how T3 Coder uses software and state already present in the workspace. They do not install a provider, perform login, or copy provider state to the local computer.
Provider settings show availability and authentication status, without subscription-quota panels. The conversation retains context/token usage and provider-reported runtime limit errors. These are not API spend, credit balances, or billing limits; consult your API billing system for those. T3 Coder does not provide a billing dashboard, external usage hubs, or pricing lookups.
When Claude reports a blocking usage limit during a turn, the conversation shows a warning. Claude's own safety fallback notifications are also shown; T3 Coder does not initiate a provider or account switch.
When Codex reports a usage-limit failure, the conversation names the exhausted window and its reset time when available. These are provider runtime errors, not an API billing dashboard.
Claude verbose output is supported for generated titles, branch names, commit messages, and merge request descriptions. These metadata requests run in the workspace. Claude runs them with executable tools, hooks, skills, and MCP servers disabled; title generation also runs outside the project folder.
Provider update checks is on by default. For each enabled provider installed through an
identifiable package manager, the workspace helper checks the npm registry (registry.npmjs.org)
for its latest version. Manual installations are not checked. To turn these checks off, disable
Settings → Maintenance → Provider update checks for the workspace.
Update all in the sidebar updates outdated Codex, Claude, and Pi installations on connected Coder workspaces by running each provider’s identified installer inside its workspace. Hover it to see which installations will update. Only installations whose updater can be identified are included; manual-only installations must be updated in their workspace terminal. Updates to versions marked broken or unsupported by the bundled compatibility policy are not offered. Updates sharing an installer run one at a time and report their results together.