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
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.
• Choose default model and reasoning effort where supported.
• 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

Session defaults 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.

Advanced routing can pin a provider and model per action. It can also give a normal click and ⌘-click different reuse, submission, or background behavior. See Git actions and pull requests.

Models and reasoning

Model lists and reasoning controls are provider-specific. The app shows only configured or visible models and applies a reasoning level only when the selected provider supports it.

Changing a model or reasoning level affects a live Chat UI session only when that adapter supports mid-session changes. Otherwise, the new selection applies to the next session. Check the provider header before assuming a running process changed models.

The optional naming model handles one-time branch and tab naming. It can differ from the model used for implementation work.

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

Profiles let one provider use separate accounts, environments, or launch flags. Claude and Codex profiles point to distinct CLI config directories:

• Claude launches the profile with CLAUDE_CONFIG_DIR.
• Codex launches the profile with CODEX_HOME.

Each profile has a name, config directory, optional launch flags, and color. Other providers may expose profiles for organization even when they do not use a dedicated config-directory environment variable.

Configure a profile

1. Open Settings → Profiles and add a profile under the provider.
2. Select the provider config directory.
3. If validation fails, launch the provider once against that directory, authenticate, and check again.
4. Add optional launch flags and a distinguishing color.
5. Choose the profile at global, workspace, or project scope.

The provider header and tab indicators identify the resolved profile so work and personal accounts are less likely to be confused.

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.