feat: per-persona model selection for AI CLI adapters

[johannes-engler-mw]

Summary

Add the ability to configure different AI models for different reviewer personas. Currently, the entire review workflow runs as a single AI process, and all reviewers inherit the same model. This feature would allow users to assign specific models to specific reviewers (e.g., use a stronger model for principal reviews and a faster model for quality checks).

Motivation

• Different review personas have different complexity needs — a holistic architecture review benefits from a more capable model, while a focused lint-style check can use a faster/cheaper one.
• OpenCode already supports --model provider/model per invocation, and Claude Code supports --model. The mechanism exists but OCR doesn't expose it.
• Cost optimization: users can balance review quality vs. token spend per persona.

Current Architecture

1. The dashboard's command-runner.ts spawns one AI process for the entire 8-phase review workflow.
2. The AI acts as "Tech Lead" and spawns individual reviewer tasks internally (Phase 4) using the CLI's built-in Task tool.
3. All reviewers inherit the parent process's model — no per-persona control.

Key files

File	Role
packages/dashboard/src/server/services/ai-cli/types.ts	SpawnOptions type — no model field
packages/dashboard/src/server/services/ai-cli/opencode-adapter.ts	OpenCode spawn — no --model flag
packages/dashboard/src/server/services/ai-cli/claude-adapter.ts	Claude Code spawn — no --model flag
packages/dashboard/src/server/socket/command-runner.ts	Orchestrates workflow spawn (single process)
.ocr/config.yaml	default_team config — count only, no model field
.ocr/skills/references/workflow.md	Phase 4 reviewer spawning instructions

Proposed Design

1. Config schema (config.yaml)

Extend default_team to support model per reviewer type:

default_team:
  principal:
    count: 2
    model: anthropic/claude-sonnet-4-20250514
  quality:
    count: 2
    model: anthropic/claude-haiku-4-5-20251001
  security:
    count: 1
    # model omitted = use default

Backwards-compatible: principal: 2 (number) still works as shorthand for { count: 2 }.

2. Type changes (SpawnOptions)

export type SpawnOptions = {
  prompt: string
  cwd: string
  mode: SpawnMode
  maxTurns?: number
  allowedTools?: string[]
  resumeSessionId?: string
  model?: string  // NEW: e.g. "anthropic/claude-sonnet-4-20250514"
}

3. Adapter changes

Both adapters pass --model when opts.model is set:

• OpenCode: opencode run "prompt" --format json --model <model>
• Claude Code: claude --print --model <model> ...

4. Architectural change: per-reviewer process spawning

This is the core change. Instead of one monolithic AI session:

Phase	Process	Model
1-3 (Tech Lead)	Single AI process	Default model
4 (Reviews)	One AI process per reviewer	Per-reviewer model from config
5-8 (Synthesis)	Single AI process	Default model

command-runner.ts would need to:

1. Parse default_team config (including model fields)
2. Run Phases 1-3 as one process (Tech Lead analysis)
3. Spawn N separate processes for Phase 4, each with its own --model flag and reviewer persona prompt
4. Collect all review outputs
5. Run Phases 5-8 as another process for synthesis

5. Workflow instructions update

Update .ocr/skills/references/workflow.md Phase 4 to reflect that reviewers may be pre-spawned by the command runner rather than self-spawned by the Tech Lead.

Complexity & Considerations

• Backwards compatibility: Number-only default_team values (principal: 2) must keep working.
• Process orchestration: Phases 1-3 must complete before Phase 4 starts; Phase 4 reviewers can run in parallel; Phases 5-8 need all reviews collected.
• State tracking: ocr state transition calls need to work across multiple processes.
• Error handling: Individual reviewer process failures shouldn't abort the entire review.
• Session context: Each reviewer process needs the same context files (discovered-standards, requirements, Tech Lead guidance) but doesn't share a conversation history with other reviewers.
• Default model: When no model is specified per-reviewer, the AI CLI's own default applies (no --model flag passed).

Acceptance Criteria

• config.yaml supports both reviewer: 2 (shorthand) and reviewer: { count: 2, model: "..." } (extended)
• SpawnOptions.model is passed as --model to both Claude Code and OpenCode adapters
• Each reviewer in Phase 4 runs as a separate AI process with its configured model
• Reviews are collected and written to the correct session paths
• State transitions work correctly across the multi-process workflow
• Existing single-model workflows continue to work unchanged

[spencermarx]

Hey @johannes-engler-mw — first off, sorry for the slow response on this. We've been heads-down at my company on a big release these past couple weeks and triage on OCR has taken a back seat. Appreciate you writing this up so thoroughly in the meantime, it made it easy to pick the thread back up cold.

Taking a proper look at this today. The motivation lands for us too — we already think of OCR as a team of reviewers rather than one linter, and it's a little inconsistent that the team-of-reviewers metaphor stops at the prompt and not the compute behind it. So we're definitely going to solve for this; it's a question of shape, not whether.

Going to weigh your proposal seriously as we work through the design — the config schema you sketched (with the count/model shorthand-vs-extended form) is exactly the kind of backwards-compatible move we'd want, and the per-process Phase 4 fan-out is a real architectural option we need to think carefully about. A couple of things we want to chew on before we lock in an approach: whether model selection belongs on the persona, on the team composition, on the tier, or some layered combination of all three; whether per-reviewer model selection actually requires the Phase 4 multi-process change or whether those are two separate shifts you've reasonably bundled together; and how we want to handle the fact that Claude Code and OpenCode use slightly different --model string conventions (passthrough vs translate vs introduce our own logical names like fast/balanced/strong). We'll likely land somewhere close to where you've pointed but want to be deliberate about those calls so the config surface ages well.

We'll keep you posted here once we have an initial implementation up that you can actually try — would love your feedback on it once it's runnable. Thanks again for the writeup.