Agent Profiles and Configurations

Create predictable per-project agent defaults instead of improvising model and binary selection on every task.

Not every repository should route through the same agent or the same model profile.

​

How model selection actually works

Conductor does not ship a separate internal whitelist of models for Claude Code, Codex, Gemini, Copilot, or the rest of the built-in agents.

The installed CLI, the credentials it is using, and the provider plan or organization policy decide which models are available in that environment.

That means one repo can see a ChatGPT-plan-filtered Codex list, another can use API-backed OpenAI models, and a Claude Code project can expose a different Anthropic catalog on the same Conductor install.

​

Blank override versus pinned override

• Leave the custom override blank when you want Conductor to use the current upstream CLI or provider selection.
• Set agentConfig.model only when a repository needs one exact model string for stability, cost control, or reasoning depth.
• Prefer repo-level defaults over task-by-task model switching.

projects:
  fast-web-app:
    agent: codex
    # no model override: follow the Codex CLI default for this environment

  regulated-backend:
    agent: claude-code
    agentConfig:
      model: claude-sonnet-4-6

​

When the agent owns model selection

Some agents keep model choice in their own CLI profile, router, or account settings.

That is fine. Use Conductor to pick the runtime per repository, then let the agent keep model state unless there is a clear need to pin it inside the project config.

​

What to standardize across teams

• one default agent per repository
• a pinned model only where the repo truly needs it
• shared naming for fast, deep, or review-oriented profiles
• documented exceptions instead of invisible local overrides

​

Related guides

• Supported Coding Agents
• Agent Guides
• Projects and Repositories