Easier per-review model and reasoning-effort selection: guidance on an acceptable approach

Feature request

Following up on #2818, I’d like to discuss the underlying use case and agree on an acceptable approach before preparing another PR. Thank you for reviewing the previous implementation; I understand the decision to decline it was based on maintenance and security concerns.

I want an easy-to-remember way to select a model and reasoning effort for an individual review from a PR comment.

As discussed in the previous PR, this is already possible with:

/review --config.model=<provider-model-id> --config.reasoning_effort=high

The improvement I’m looking for is convenience: a short command that avoids having to remember configuration keys and full provider model identifiers. For example:

/review fable+high

That syntax is illustrative; I’m happy to use a different format or an approach that fits the existing configuration system better.

Motivation

On my team, engineers use different models to write code, and we want to request reviews from a different model because different models catch different bugs. For example, when someone uses Astra to implement a change, we want Fable to review it. When someone uses Opus, we want Sol to review it.

Choosing the review model is therefore a frequent, per-PR decision. Typing out full provider model identifiers and configuration flags every time is too cumbersome for this everyday workflow:

/review --config.model=<provider-model-id> --config.reasoning_effort=high

We need a concise, easy-to-remember syntax that makes requesting the appropriate reviewer quick:

/review fable+high
/review sol+high

The specific syntax is negotiable; making this workflow convenient is the goal. I’d prefer to contribute an accepted upstream solution rather than maintain a fork.

I recognize that shorthand alone would not restrict the existing model-selection flags or establish a new security boundary.

For an initial contribution, selecting one model and effort for one invocation would be enough. Caller-defined fallback chains and changes to AI handlers, retry behavior, or review output are unnecessary for this goal.

Could you help clarify:

• Would you consider a smaller usability improvement for this workflow?
• What syntax or existing extension point would you prefer?
• What maintenance and security requirements would an acceptable implementation need to meet?

If the preferred direction is to keep the existing flags, I’d also welcome guidance on whether a documentation improvement or configuration-based shortcut would be useful. I’m happy to agree on the scope and acceptance criteria here before writing another PR.