Providers and models

The app works with local coding-agent tools. It does not replace provider authentication or proxy provider traffic; it launches a local command or adapter and keeps workspace, tab, and review state around that session.

Supported providers and surfaces

Chat UI means the app can render the provider’s messages, markdown, tool activity, and supported inline diffs. Terminal means the provider runs through its native CLI interface. Experimental integrations may change more quickly and may be hidden until enabled.

Experimental

Experimental providers are disabled by default and may change more quickly. Open Settings → Agents and enable a provider before selecting it. Enabling a provider makes it available in selectors; it does not install its CLI or authenticate an account.

Provider	Default command	Chat UI	Terminal	Status
Claude Code	claude	Yes	Yes	Stable
Codex	codex	Yes	Yes	Stable
Cursor	cursor-agent	Yes	Yes	Stable
OpenCode	opencode	Yes	Yes	Stable
Pi	pi	Yes	Yes	Stable
Oh My Pi	omp	Yes	Yes	Stable
Grok	grok	Yes	Yes	Stable
Kimi Code	kimi	Yes	Yes	Experimental
Prime Agent	prime-agent	Yes	Yes	Experimental
fx (Vercel)	fx	Yes	Yes	Experimental
GitHub Copilot	copilot	No	Yes	Experimental
Factory Droid	droid	No	Yes	Experimental
Kiro	kiro-cli	No	Yes	Experimental
Qwen Code	qwen	No	Yes	Experimental
Hermes	hermes	No	Yes	Experimental
Antigravity	agy	No	Yes	Experimental
Gemini Legacy	gemini	No	Yes	Experimental legacy integration

The installed app is the authority if this table and its provider picker ever differ. Provider capabilities evolve independently, and a provider can support a feature in Terminal before its Chat UI adapter does.

Install and authenticate first

Install the provider through its official instructions, authenticate it, and run its command in a normal terminal. For example:

Copy

claude --help
codex --help
opencode --help
pi --help

The app discovers commands through your macOS login-shell PATH. Restart the app after changing shell startup files. If the command fails or requests login outside the app, resolve that with the provider before starting a session.

Enable a provider

Open Settings → Agents to:

• Enable or disable providers.
• Check installation status.
• Override an executable command or add launch flags.
• Control which models appear in pickers.
• Select Chat UI or Terminal as the default surface for new agent tabs.

First-run onboarding emphasizes installed stable providers. Use More or Settings to reveal additional and experimental options.

Choose providers by scope and task

Choose session and action defaults in Settings → Routing. Settings cascade global → workspace → project. A project can inherit the workspace provider while overriding only its model or profile.

Git and review actions have two routing groups:

• Fast for bounded work such as inline commit, Commit & push, Commit, and Create PR/MR.
• Thorough for review, conflicts, failed CI, blocked merges, comments, and requested changes.

Each route picker can select a provider, profile, model, and supported thinking level. Individual actions can override their group. Separate click controls choose reuse, submission, or background behavior for a normal click and ⌘-click. See Git actions and pull requests.

Models and reasoning

Model lists and thinking controls are provider-specific. Agents controls model visibility; Routing selects the models used by new sessions and actions.

• Inherit follows the parent scope or route shown in the picker.
• CLI default lets the provider use its configured model without saving an explicit model pin. The picker can display the resolved model while keeping this choice unpinned.
• Selecting a named model pins that model, even when it is also the current CLI default.

New chats follow Session default. Resumed chats retain their saved selection. Returning a supported live or resumed chat to CLI default restores the provider’s configured default; pending changes and failures appear in the composer. A model or thinking change takes effect only when the adapter accepts it. It does not relabel earlier responses.

Choose thinking effort from the selected model’s supported levels, or leave it at its default. Automatic naming follows Fast unless its route is overridden.

Retired model selections

Saved pins for GPT-5.3 Codex, GPT-5.3 Codex Spark, GPT-5.4, and GPT-5.4 Mini return to inherited routing or provider defaults, with a one-time notice. Review Routing if you need an explicit replacement.

Chat UI versus Terminal

Choose Chat UI when you want rendered markdown, tool activity, inline diffs, attachments, app-level history, and integrated notification handling. Choose Terminal when you need the provider’s native interactive UI, a flag that the Chat UI does not expose, or a terminal-only provider.

Using both is normal: keep an agent chat beside a terminal that runs tests or development servers. The selected surface is a default; each new tab can choose another supported provider or tool.

Beta

Claude’s Compliant Claude view is a beta setting under Settings → Agents → Claude Code. Enable it to run local Claude chats through Claude Code’s interactive mode and keep usage on the selected subscription plan. SSH workspaces always use the structured claude -p transport. Enabling the setting affects future compatible launches; it does not authenticate Claude or change the account selected by its CLI.

When Compliant Claude view is disabled, local Chat UI uses Claude’s noninteractive CLI path. Confirm the active CLI account and billing behavior before long-running work.

Permissions and approvals

Provider permission modes decide whether an agent asks before commands, file changes, or risky actions. The app exposes the modes a provider supports and warns before explicit bypass settings.

Use the least permissive mode that still fits the task. A background or auto-submitted action does not remove the provider’s approval requirements; requests appear in the relevant session and notification queue.

Profiles

Settings → Profiles manages Claude and Codex accounts together. Use the existing CLI login, add a subscription account through browser sign-in, add an API-key profile, or use an existing profile directory. Each account card shows its identity and supports reauthentication and advanced configuration.

Configure a profile

1. Open Settings → Profiles and choose Add account for Claude or Codex, or use More… for an API key or existing profile.
2. Complete sign-in, or supply the key or profile directory. Saving an API key stores it locally; it does not validate the key.
3. Use Advanced for the config directory, executable, optional launch flags, and profile appearance.
4. Open Settings → Routing, choose the scope, and select the profile under Default profiles or on a specific route. Route pickers also offer Add profile.

Claude profiles use CLAUDE_CONFIG_DIR; Codex profiles use CODEX_HOME. API-key usage is billed separately from subscriptions. Claude can also opt into a profile’s settings API key; missing credentials or conflicting transport settings cause a launch error.

Choose defaults and update routes

Routing has independent Claude and Codex defaults at Global, Workspace, and Project scope. They apply to new chats, terminals, and orchestration launches. Existing profile defaults migrate into Routing. A profile picker’s CLI default uses the provider’s own account and configuration without a named profile.

Apply to all routes replaces that provider’s profile selections in the current scope while preserving model, thinking, and other providers’ effective profile choices. Use Undo to reverse the change. Before removing a profile used by Routing, choose a replacement there.

The composer and tab identify the selected profile. Changing profiles in an established chat starts a separate continuation and keeps the original chat on its account; see Switch profiles.

Troubleshooting

If a provider is missing or unavailable:

1. Run its configured command in a normal login shell.
2. Confirm authentication through the provider’s own CLI.
3. Restart the app after changing PATH or shell configuration.
4. Check that the provider and intended models are enabled in Settings.
5. Confirm the selected surface is supported in the table above.
6. For Chat UI discovery, run sc chat providers from an app-launched terminal.

A provider that works in Terminal but does not appear in Chat UI usually lacks a Chat UI adapter or has that integration disabled.