Providers and models

Superconductor works with the agent tools you already use. It does not replace provider authentication or route provider traffic through Superconductor servers; it launches local tools or native provider adapters and stores local app state around those sessions.

Provider types

Superconductor exposes two provider surfaces:

• Terminal providers run as local CLI processes in a project or worktree terminal.
• Chat providers use the native chat surface when Superconductor ships an adapter for that provider.

A provider can appear in both surfaces. Terminal and chat sessions may differ in capability because each provider exposes its own resume, model, upload, tool, and event APIs.

Before configuring a provider

Install and authenticate the provider outside Superconductor first. In a normal terminal, confirm the command runs:

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

Use the command that matches your provider, matching the command shown in Superconductor settings. If the CLI fails in your normal shell, fix that before opening it from Superconductor.

Provider settings

Open settings to manage provider availability, launch commands, default behavior, and routing. Settings cascade from project to workspace to global, so a repository can override the global default provider or model.

Provider settings include:

• Enabling or disabling providers.
• Choosing the default provider for new workspaces.
• Selecting default models and reasoning levels.
• Adjusting terminal launch presets.
• Checking whether required provider tools are installed.

Models and reasoning

Model and reasoning controls are provider-specific. A reasoning level offered by one provider or model may not exist for another, so Superconductor applies a control only when the provider supports it.

A live chat session receives model or reasoning changes directly when the provider supports mid-session updates. Otherwise, updated settings affect future sessions, not the running provider process.

Custom presets

Terminal presets define custom arguments, environment variables, wrappers, and project-specific launch behavior.

When a preset wraps a provider command, Superconductor still depends on recognizable provider behavior for resume and session classification.

Profiles

A profile points the provider CLI at a separate config directory so one provider can carry several accounts or environments side by side. Currently, Claude and Codex support profile config directories. The Claude profile sets CLAUDE_CONFIG_DIR; the Codex profile sets CODEX_HOME. Other providers list profiles for organization, without an environment variable.

Each profile stores:

• Name — identifier shown in pickers and tab indicators.
• Config directory — folder holding the provider’s local CLI config and credentials.
• Launch flags — extra arguments appended to the provider command.
• Color — UI marker for quick recognition.

Configure a profile

1. Open Settings → Agents, expand the provider, and open Profiles.
2. Click Add profile.
3. Click Select Profile Folder and pick a directory containing that provider’s CLI config. If the folder lacks recognizable config, run the provider CLI once against that path, then click Check again.
4. Set optional launch flags and a color.
5. Pick a default profile per scope. Scopes cascade global → workspace → project, and each scope can override the inherited default.

Use profiles

When a workspace or project selects a profile, Superconductor launches the provider with the matching config directory and launch flags. Switch the active profile from the provider header in chat or the provider entry in settings. Each worktree may resolve a different profile depending on its workspace and project overrides.

Troubleshooting provider setup

If a provider is missing or disabled:

1. Run the provider command in a normal terminal.
2. Confirm you are signed in through the provider’s own CLI.
3. Restart the Superconductor session after changing shell configuration.
4. Check provider settings and installation status.
5. For native chat sessions, run:

sc chat providers

If the provider appears in terminal workflows but not native chat, it lacks a native chat adapter.