Feature Request: Support Selecting User-Created OpenRouter Presets Summary

[godzail]

Problem (one or two sentences)

Currently, RooCode allows selecting base models from OpenRouter, but it does not expose user-created presets configured in the OpenRouter dashboard.

OpenRouter presets allow users to define:

• Custom system prompts
• Temperature and sampling parameters
• Tool configuration
• Context length settings
• Model routing strategies

Without preset support, users must manually replicate these configurations inside RooCode, which:

• Breaks single source of truth
• Increases maintenance overhead
• Causes configuration drift
• Reduces flexibility for advanced workflows

Context (who is affected and when)

RooCode integrates with OpenRouter to allow users to select and use different foundation models.

On the OpenRouter side, users can define presets in their account. Presets encapsulate reusable configuration such as:

• System prompts
• Temperature and sampling parameters
• Tool usage configuration
• Context window settings
• Model routing strategies (including fallback chains or cost/latency optimization)

In many real-world workflows, especially for coding agents, users rely on presets as the canonical source of configuration. This allows them to:

• Maintain a single source of truth
• Adjust behavior centrally without modifying each client integration
• Reuse consistent configurations across tools

Currently, RooCode only exposes base models, which requires users to manually replicate preset behavior inside RooCode. This leads to configuration drift and reduces the value of OpenRouter’s preset abstraction.

Desired behavior (conceptual, not technical)

1. Preset Discovery

   • When OpenRouter is configured, RooCode fetches available presets associated with the authenticated account.
   • Presets are retrieved via the OpenRouter API.
   • Retrieval failures should not block model usage.

2. Model Selection UI

   • Presets appear in the model selector alongside base models.
   • They are clearly distinguishable (e.g., labeled as Preset: <name>).
   • If no presets exist, the UI behaves exactly as it does today.

3. Request Execution

   • When a preset is selected, RooCode sends the request using the preset identifier.
   • RooCode does not override preset-defined parameters unless explicitly configured by the user.
   • Switching between base models and presets should be seamless.

4. Error Handling

   • If a preset becomes invalid or deleted, RooCode displays a clear error and allows reselection.
   • If preset fetching fails, RooCode gracefully falls back to standard model listing.

5. Backward Compatibility

   • Existing configurations continue to work unchanged.
   • Users who do not use presets experience no behavior changes.

Constraints / preferences (optional)

Example Use Cases

• Switching between workflow-specific presets (e.g., Architect mode, Reviewer mode, Refactor mode).
• Using routing presets optimized for cost or latency.
• Managing structured output configurations centrally.
• Sharing standardized presets across a team or organization.

---

Benefits

• Centralized configuration management
• Reduced duplication of model settings
• Better alignment with OpenRouter capabilities
• Improved workflow flexibility for advanced users

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

No response

Proposed approach (optional)

No response

Trade-offs / risks (optional)

No response

[roomote]

I have analyzed this issue and explored the codebase. Here is my proposed implementation plan:

Investigation Note

Before implementing, we need to confirm whether OpenRouter exposes a public API endpoint for listing user-created presets (e.g., GET /api/v1/presets). The OpenRouter API docs primarily document /models and /models/{id}/endpoints, but preset listing may require an authenticated endpoint. If no such endpoint exists, this feature would be blocked on an OpenRouter API addition.

Proposed Implementation Plan (assuming API availability)

1. Add preset fetching to the OpenRouter fetcher (src/api/providers/fetchers/openrouter.ts)

• Add a new getOpenRouterPresets() function that calls the OpenRouter presets API (authenticated with the user's API key)
• Define Zod schemas for the preset response structure
• Parse presets into a new OpenRouterPreset type containing: id, name, model, and any configuration parameters

2. Add preset types (packages/types/src/providers/openrouter.ts)

• Define an OpenRouterPreset interface with fields like id, name, model, temperature, systemPrompt, etc.
• Export the type for use across the codebase

3. Extend provider settings (packages/types/src/provider-settings.ts)

• Add an openRouterPresetId field to the OpenRouter provider schema
• This field would be set when a user selects a preset instead of a base model

4. Update the OpenRouter handler (src/api/providers/openrouter.ts)

• When openRouterPresetId is set, include the preset identifier in API requests to OpenRouter
• Ensure preset-defined parameters (temperature, system prompt, etc.) are not overridden by RooCode defaults unless explicitly configured

5. Add preset caching (src/api/providers/fetchers/modelCache.ts)

• Add preset data to the existing model caching infrastructure
• Presets should be fetched alongside models but cached separately
• Failed preset fetches should not block model listing (graceful degradation)

6. Update the model selector UI (webview-ui/src/components/settings/providers/OpenRouter.tsx)

• Display presets in the model picker alongside base models
• Visually distinguish presets from base models (e.g., prefix with "Preset: " or use a badge/icon)
• When a preset is selected, store the openRouterPresetId in the configuration
• If no presets exist, the UI remains unchanged (backward compatible)

7. Update the webview message handler (src/core/webview/webviewMessageHandler.ts)

• Include preset data in the router models response or as a separate data channel
• Handle preset fetch errors gracefully

8. Error handling

• If a selected preset becomes invalid/deleted, show a clear error and allow reselection
• If preset fetching fails, fall back to standard model listing
• All existing configurations continue to work unchanged

9. Tests

• Unit tests for preset fetching and parsing
• Unit tests for the OpenRouter handler with preset selection
• UI tests for preset display in the model picker
• Error handling tests for invalid/deleted presets

Key Considerations

• Backward compatibility: Users without presets see no changes
• Graceful degradation: Preset fetch failures never block normal model usage
• Single source of truth: Preset parameters are respected from OpenRouter; RooCode does not duplicate them
• Authentication: Preset fetching requires the user's API key (presets are account-specific)

Open Question

Does OpenRouter currently expose a presets listing API? If not, we may need to coordinate with the OpenRouter team or propose an alternative approach (e.g., manual preset ID entry).

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.