choose providers and models

orcr runs agents across providers so you can send each piece of work to the tool that does it best. claude and codex ship supported in the first release. this page covers how to pick a provider and model per agent, and a starting routing table.

the three flags

• -a <provider>: the provider. optional; when omitted it falls back to defaults.agent in config (default claude). it also filters orcr agent ls and orcr top.
• --model <m>: the model within that provider. empty means the provider default.
• --effort <e>: the reasoning-effort level, mapped per provider. empty means the provider default.

orcr agent run --name reviewer -a codex -p "…"
orcr agent run --name fixer -a claude --model opus --effort high -p "…"
orcr agent ask  --name draft -a claude --model sonnet -p "…"

in the SDK these are agent, model, and effort:

await orcr.agent.run({ agent: "claude", model: "opus", effort: "high", name: "fixer", prompt: "…" });

precedence

the provider (and any tuning) resolves in this order:

CLI flag  →  config (defaults.agent / defaults.model / defaults.effort)  →  built-in default

set the defaults you use most in ~/.orcr/config.json, and override per agent on the command line:

{
  "defaults": {
    "agent": "claude",   // used when -a is omitted
    "model": "",         // empty = provider default
    "effort": ""
  }
}

there is no default timeout, which is deliberate and separate from provider defaults. see configure orchestratr.

a routing table to start from

match the work to the model, and use a different provider for review than the one that did the work. edit this for your setup.

the "different provider for review" rule shows up throughout the patterns: a codex verifier judging claude's work, or vice versa, so the reviewer is a different model than the author and gives an independent check rather than one model judging its own output.

orcr server status shows which integrations are installed, so you know what you can route to right now.

supported providers

a provider is supported only when both integration layers are present: herdr's integration (so herdr can observe the agent's state and transcript) and orcr's integration (so orcr can drive it). running with a provider missing either layer fails fast at agent run with integration_missing, naming the missing layer and the exact fix; nothing is spawned. there are no degraded half-modes. see providers and integrations.

why interactive TUIs, not headless API calls

every agent runs as a real interactive TUI in a herdr pane, which keeps provider routing affordable. interactive TUI sessions bill against flat subscription plans; headless API-mode invocations bill per token, so running many agents per token costs far more than a flat plan. running agents as real TUIs also keeps them attachable and steerable, and it is the durable path as providers restrict headless usage. routing work across providers lets you spend each subscription's quota where that provider is strongest.

next

• run and manage agents: where these flags go.
• teach any agent to orchestrate (the skill): the routing table lives there too, for the agent to use.
• configure orchestratr: defaults and per-provider caps.
• providers and integrations: the two-layer model.