Multi-Provider

SlyCode orchestrates these tools; it does not replace them or proxy their APIs. Each CLI must be installed and authenticated separately, using its own account and login flow. You need at least one; slycode doctor checks which agents are installed.

Provider choice is per session, resolved at three levels:

• Per card. Every card terminal starts under a provider. The terminal panel lets you switch provider before starting a session; that switch is ephemeral and affects the next start only.
• Per project. Each project can carry its own default session config: provider, permissions mode, and an optional model.
• Global. A workspace-wide default acts as the fallback when a project has no override.

Resolution order is per-project override first, then the global default. A top-bar control in the dashboard edits these defaults; changes made inside a terminal panel never overwrite the saved default.

Projects also declare which providers they use during the Add Project wizard, which scaffolds the matching instruction files.

Each provider declares a list of selectable models in its configuration. The terminal panel shows a model picker populated from that list, and messaging forwards the same selection, so you can choose a model per session at start time. The chosen model is passed to the agent CLI via the provider's model flag.

• Defaults can pin a model. The global and per-project defaults accept an optional model, including a free-text custom model ID for anything not in the configured list.
• Fresh sessions only. The model flag applies when a session starts. Resuming reconnects to the session's existing model, so the flag is suppressed on resume.
• Visible everywhere. The model is stored on the session and surfaced in session info for both live and stopped sessions.

A card is not tied to one agent. The card modal's terminal tab supports simultaneous Claude, Codex, and Gemini sessions on the same card. When more than one session exists, provider pills appear, each with its own status dot, and a "+" control starts a session under another provider.

Sessions survive card moves between stages, and new sibling sessions, for example one created by a cross-card prompt, are discovered live. On the board, each card face shows a session status dot: green for running, orange for detached, gray for none.

Every provider CLI has its own resume mechanism: some take a resume flag with a session ID, others use a resume subcommand, and each stores its session history in a different place. SlyCode abstracts all of it behind one Resume button.

• When a session starts, SlyCode detects the provider's own session ID in the background and links it to the SlyCode session.
• Session state persists across restarts. A stopped session keeps its ID, working directory, provider, and model, so it shows as resumable later.
• Resuming rebuilds the correct provider-specific resume command for you. If detection missed an ID, a Relink control re-detects it.
• Detached sessions (no browser connected) keep running and still accept prompts, which is what lets automations work with no UI open.

Each provider reads project instructions from its own file: Claude Code reads CLAUDE.md, Codex CLI reads AGENTS.md (with CODEX.md as an alternate), and Gemini CLI reads GEMINI.md. A project scaffolded for one provider is missing the files the others expect.

SlyCode checks for the provider's instruction file before a session starts. If the primary file is missing but another provider's instruction file exists, it offers to copy it, for example copying AGENTS.md to CODEX.md. The copy is strictly opt-in: nothing is created unless you confirm, and if there is nothing to copy from, no action is taken.

Running multiple providers is most useful when they check each other's work. SlyCode's challenge actions send a card's design or implementation to a different provider for adversarial review: the second agent critiques the work, and the findings come back synthesized into agree, disagree, and discuss buckets. No code changes happen without your approval.

Cross-agent notes on the card keep the full conversation, with per-agent badges showing who said what. See Kanban workflow for how challenge actions fit into the card lifecycle.

• Configuration: provider configs, defaults, and everything else in the workspace.
• Code Mode: the zoomable codebase atlas built into every project.