Preset Model Providers & Multi-Model Switching

[peachest]

Feature Idea: Preset Model Providers & Multi-Model Switching

Background

Most mainstream Coding Agents today (Claude Code, Cursor, Cline, Continue, etc.) ship with a set of preset model providers (OpenAI, Anthropic, DeepSeek, Qwen, Gemini, OpenRouter, and so on). To configure a model, users typically only need to:

1. Pick a provider from a dropdown / list;
2. Paste in the corresponding API key.

That's it — no need to manually figure out the BaseUrl, decide whether the provider speaks the Anthropic protocol, or debug auth headers.

The current model configuration in open-code-review has two pain points compared to this:

1. No preset providers. Users have to look up each vendor's BaseUrl, API path, and whether it's OpenAI-compatible or Anthropic-compatible (the UseAnthropic flag, etc.) on their own. The onboarding cost is high, and a single wrong field can cost a long debugging session.
2. No model switching. Every time you want to try a different model, you have to rewrite the configuration from scratch. This is particularly painful for two groups of users:
   • People who want to try open-code-review across multiple models to compare results;
   • People who want to have several models review the same code and merge the findings, in order to improve issue coverage through a kind of "model ensemble".

Proposed Features

I'd like to propose adding the following two capabilities to open-code-review (inspired by pi's provider and custom module/provider):

1. Preset Model Providers

Ship a built-in catalog of common providers updated with each release. Each entry contains pre-configured fields:

Field	Description	Example
name	Provider display name	"Anthropic", "DeepSeek"
baseUrl	Default API endpoint	"https://api.anthropic.com"
api	Protocol type	"anthropic-messages" / "openai-completions" / "google-generative-ai"
apiKeyEnv	Recommended env var	"ANTHROPIC_API_KEY", "DEEPSEEK_API_KEY"
models	Recommended model list (id, name, reasoning, input, contextWindow, maxTokens, cost)	See example below
compat	Compatibility tuning for protocol quirks	See example below

After picking a provider, the user only needs to supply an API key (via environment variable or config file) — skipping low-level fields like BaseUrl, api protocol type, or UseAnthropic. A "Custom Provider" option should still be kept for self-hosted deployments or new vendors not yet in the catalog.

Why compat matters:

Even providers speaking the same protocol family (e.g. OpenAI Chat Completions) have subtle differences. Pre-configured compat fields let users switch providers without knowing these details:

Parameter	Description	When to use
supportsDeveloperRole	Whether the provider accepts developer role	false for Ollama/vLLM
supportsReasoningEffort	Whether reasoning_effort is supported	Some servers lack this
maxTokensField	"max_completion_tokens" vs "max_tokens"	Protocol variant
thinkingFormat	Thinking parameter format	"deepseek" / "openrouter" / "qwen" etc.
supportsEagerToolInputStreaming	Anthropic tool streaming marker	Anthropic-compatible proxies

Custom provider mechanism:

Allow users to extend providers in config:

custom_providers:
  my-local-llm:
    baseUrl: "http://localhost:8080/v1"
    api: "openai-completions"
    apiKey: "not-needed"
    compat:
      supportsDeveloperRole: false
    models:
      - id: "qwen2.5-coder:14b"
        name: "Qwen 2.5 Coder 14B"
        reasoning: false
        input: ["text"]
        contextWindow: 32768
        maxTokens: 4096

Custom providers appear alongside built-in providers in the model selector / config UI.

2. Multi-Model Configuration & Switching

Let users save multiple named model profiles and switch between them on demand, instead of rewriting the config every time.

Model profiles in config:

model_profiles:
  deepseek-v3:
    provider: deepseek
    model: deepseek-chat
    apiKey: "${DEEPSEEK_API_KEY}"
  claude-sonnet:
    provider: anthropic
    model: claude-sonnet-4-20250514
    apiKey: "${ANTHROPIC_API_KEY}"
  qwen-max:
    provider: custom
    customProvider: my-local-llm
    model: qwen2.5-coder:14b

Switching methods:

• CLI argument: ocr --profile deepseek-v3 --diff pr.diff
• Environment variable / default config: defaultProfile: deepseek-v3
• Interactive TUI selector: pick a profile at runtime

Parallel multi-model review (advanced):

Specify multiple profiles to review the same diff concurrently, then merge or present side by side for cross-validation:

ocr --profiles deepseek-v3,claude-sonnet,qwen-max --diff pr.diff --merge

Expected Benefits

• Significantly lower onboarding cost. New users no longer need to research each vendor's API endpoint, protocol type, or whether developer role is supported. Pick a preset provider, configure an API key, and go. This model has been proven effective by pi, Claude Code, Cursor, and other mainstream tools.

• Higher experimentation efficiency. Switch between models with a single CLI flag or profile name, without repeatedly rewriting config files. The community can easily compare how different models perform on code review tasks, helping the project gather quality feedback across models.

• Higher review quality via multi-model ensemble. Cross-model review meaningfully reduces the blind spots and biases of any single model. Reviewing the same diff with several models and merging or comparing results provides a tangible quality lift for critical codebases.

• Flexible extensibility. Built-in presets cover mainstream providers, while the custom provider entry accommodates self-hosted deployments (Ollama / vLLM / LM Studio), enterprise gateway proxies, and new vendors not yet in the catalog.

• Transparent adapter for vendor quirks. Pre-configured compat tuning parameters ensure the tool automatically adapts to protocol differences — thinking parameter format, role field names, context window size, etc. — even when the user switches between very different providers (e.g. OpenAI → DeepSeek → local model).

Open Questions for Discussion

1. Have you also run into pain points around model configuration or switching when using open-code-review?
2. Which providers should the built-in preset list cover? Should we support local deployment options like Ollama / vLLM?
3. For parallel multi-model review, do you prefer one merged & deduplicated output, or results grouped by model and shown side by side?
4. For configuration UX, what do you prefer: profiles in a config file, CLI subcommands for switching, or an interactive TUI selector?

Feedback and ideas are very welcome 🙌

[lizhengfeng101]

Thank you so much for this thoughtful and well-structured proposal! 🙏

We are truly honored that so many developers recognize and use our open-source tool. Your feedback means a lot to us.

We fully agree that lowering the onboarding cost for new users is critical. We will prioritize this feature request as our #1 priority and start working on preset model providers and streamlined configuration as soon as possible.

Stay tuned for updates — we will keep this discussion posted on progress.