Models
Coograph delegates to six agents whose demands differ by an order of magnitude. explore reads a great deal and decides little. debugger reads little and decides everything. Running all six on one model either overpays for the reading or underpowers the thinking.
Claude Code has always supported a model per agent and a model per invocation. Coograph now uses it, and asks you first.
Five tools, and the catalogue is yours. Claude Code, Cursor, VS Code Copilot, Codex CLI and OpenCode each let you set a model per agent, so Coograph writes the mapping where that tool reads it. What it cannot do is guess which models you have: every one of them wants a different model id. So you declare a catalogue, and the suggestion reasons about your models at your rates. Aider and Cline are a different case entirely — see Reach below.
It never picks for you
A fresh install ships models.mode: unset. That is not a default mapping, it is the absence of one: every agent inherits whatever model your session is running, exactly as before.
The first ticket in a project asks once, after investigation and before the proposal, because that is the first moment the shape of the work is known:
Coograph can run each agent on a different model. Do you want one model for everything, a saved mapping, or to be asked per ticket?
Your answer goes into openspec/config.yaml and the question never returns, whatever you chose. Asking on every ticket is the kind of friction that gets a useful feature switched off for the wrong reason.
The four modes
| Mode | What happens |
|---|---|
unset | What ships. Asks once on the next ticket, then never again. |
off | Every agent inherits the session model. Nothing is ever suggested. |
preset | The saved mapping is applied quietly. A suggestion appears only for an outlier ticket. |
per-task | A mapping is suggested for every ticket before it is used. |
# openspec/config.yaml
models:
mode: preset
preset:
explore: haiku
search: haiku
verifier: sonnet
reviewer: opus
debugger: opus
planner: opus
retro: opus
Sync never overwrites config.yaml, so your choice survives a template update.
Two commands
/coograph-suggest-multi-models proposes a mapping, for the project or for the ticket in hand. Each row names the agent, the model, a reason grounded in your actual change, and the estimated cost difference against your session model. You can edit any line, accept, or decline. Nothing is written until you accept. It is also the way back into a project you turned off.
/coograph-disable-multi-models sets mode: off in one step. No confirmation prompt, because the command’s only job is that. Any saved mapping is kept, so turning it back on does not start from nothing.
Every run says which model did the work
A delegated run ends with one line:
models: reviewer=opus (mapping), explore=haiku (mapping)
It prints in every mode. With off or unset it reads (inherited) and names your session model. That line is the point: without it you cannot tell a working mapping from a silently ignored one, and an invisible feature is indistinguishable from a broken one.
Your catalogue
A mapping is only worth anything if it names models your tool can load, and no two tools spell them the same way. Cursor wants composer-2. OpenCode wants provider/model-id. Copilot resolves only its own vendor’s models. A table of Anthropic aliases shipped by us would be wrong for most people and silently wrong for the rest.
So the catalogue is yours. Each alias binds to the id your tool loads and rough per-million-token rates, which is what lets a suggestion quote a cost delta in your terms rather than ours:
# openspec/config.yaml
models:
mode: preset
catalog:
cheap: { id: claude-haiku-4-5, in: 1, out: 5 }
mid: { id: claude-sonnet-5, in: 2, out: 10 }
capable: { id: claude-opus-5, in: 5, out: 25 }
preset:
explore: cheap
search: cheap
verifier: mid
reviewer: capable
debugger: capable
Those ids are an example, not a default. Coograph ships no catalogue at all.
Without one, nothing changes. On Claude Code the four built-in aliases keep working exactly as before. On any other tool the suggestion asks you to declare a catalogue rather than inventing ids that would fail at load. It never infers one from an API key, an installed SDK or the tool you happen to be running.
A preset naming an alias the catalogue does not define is an error, not a guess: it says which alias and stops.
Which tier for which agent
Roles map to your aliases, so the shape matters more than the names:
| Agent | Tier | Reason |
|---|---|---|
explore, search | cheapest | Bulk reading and summarising. High token volume, little judgment. The largest saving available. |
verifier | middle | Runs commands and checks results against stated criteria. Mechanical. |
debugger | capable | Root-causing is where a cheap model burns turns guessing and costs more than it saved. |
reviewer | capable | One caught defect repays the difference many times over. |
planner | capable | Low volume, high leverage. It sets the shape of everything after it. |
retro | capable | Reads a deterministic report and argues from it. |
The suggestion adjusts for the work. A one-file change with an obvious fix does not need an expensive reviewer. A concurrency bug, a migration, an auth path or anything touching money argues the other way. A top tier usually costs several times the middle one and earns it only on genuinely hard, long-horizon work.
The catch worth knowing
Prompt caches are model-scoped. Six agents across four models means six cache namespaces instead of one, and a short agent run can lose more to cache misses than it saves on the per-token rate. That is why the cheap assignments are the read-heavy agents: their runs are long enough to absorb it. It is also why a suggestion that proposes three or more models says so out loud.
Two more limits, stated plainly. The suggestion is a guess from ticket text and file counts, so it will sometimes be wrong, which is why nothing applies without your accept. And the rate table above will age; the command re-states the date it was recorded and that the figures are estimates.
Reach
Five tools delegate to Coograph’s agents, so a model per role is a real setting. Each wants it somewhere different, and Coograph writes it there:
| Tool | Where the mapping goes |
|---|---|
| Claude Code | the model parameter on the Agent call |
| Cursor | model: frontmatter on subagent markdown in .cursor/agents/ or .claude/agents/ |
| VS Code Copilot | model: frontmatter in .github/agents/*.agent.md |
| Codex CLI | TOML agent definitions under ~/.codex/agents/, which also take a reasoning effort |
| OpenCode | agents in opencode.json, ids in provider/model-id form |
A role you did not map is left to inherit rather than pinned.
A mapping that cannot be written is refused, not approximated. VS Code Copilot resolves only its own vendor’s models, so a catalogue naming something else is rejected with the id and the constraint named. Writing a near-miss and letting it fail when the tool loads it would be worse than saying no.
Aider and Cline
Not supported, and not planned — there is nothing to support.
Coograph runs as rules in those tools. There is one agent, and it runs everything, so there are no roles to assign a model to. Aider’s --editor-model and --weak-model, and Cline’s separate Plan and Act models, are those tools’ own pipeline stages. Assigning Coograph’s reviewer to Aider’s editor slot is not a lossy collapse of seven roles into three; there is no reviewer at runtime to collapse.
If you use either, pick one model and set it yourself. That is the whole answer, and calling it “coming soon” would imply work that should never arrive.