Per-task model configuration

[cometkim]

Problem Statement

I'm currently optimizing code review costs by selecting the cheaper model.

However, sometimes a lack of intelligence in the model can lead to higher token consumption or lower accuracy.

So I'm currently considering using different models for each sequence. Like the most recent DoorDash research splits the process into a scout agent and a deep review agent.

Proposed Solution

Since OpenCodeReview has separate agents for each task, I think it can provide a configuration that allows selecting different models for them. For example, different models can be used for PLAN_TASK and MAIN_TASK, and a cheaper alternative model can be selected for MEMORY_COMPRESSION_TASK.

Alternatives Considered

No response

Affected Area

Configuration

Additional Context

No response

[lizhengfeng101]

Thanks for the great suggestion!

Per-task model configuration is actually something our internal version already supports. When open-sourcing OpenCodeReview, we deliberately left it out to reduce cognitive complexity for users. But since there's real demand for it, I think we'll add support for this in a future release.

Really appreciate you sharing the DoorDash reference too — the scout/deep-review split is a nice fit for our per-task agent design.

[chethanuk]

Following up — since per-task model config already exists in your internal version, would you be open to publishing the intended config schema (even just the JSON shape) ahead of the implementation? That would let integrations and docs prepare, and community PRs could target it without guessing.

For reference, the ecosystem has converged on two shapes: a small fixed role set (aider's weak_model/editor_model, opencode's model + small_model) or a typed slot map (crush's models.large/small, with its agents binding to one of those slots internally). Mechanically OCR looks ready for either — every ChatRequest already sets Model per call and resolution is centralized in internal/llm/resolver.go (ResolveEndpointWithModelOverride already exists). Happy to implement against whichever schema you choose.