Skip to content

[ENHANCEMENT] Centralize model family defaults for tool preferences and settings across all providers #10214

@hannesrudolph

Description

@hannesrudolph

Problem (one or two sentences)

Model-specific settings like includedTools, excludedTools, and defaultTemperature are currently duplicated in two places: hardcoded in type definitions (e.g., openai.ts, gemini.ts) and applied at runtime via router-tool-preferences.ts. This creates inconsistency when the same model family (e.g., GPT models, Gemini models) is used through different providers.

Context (who is affected and when)

Users who access OpenAI or Gemini models through various providers (native, OpenRouter, Requesty, Bedrock, Azure, etc.) may availability and behavior. For example, a GPT model accessed via OpenRouter correctly gets apply_patch included, but the same model via Azure might not have these preferences applied.

Desired behavior (conceptual, not technical)

When a model from a recognized family (OpenAI, Gemini, etc.) is used through any provider, it should automatically receive the appropriate default settings for that family. These defaults should only apply when the setting isn't already explicitly configured. This ensures consistent behavior regardless of which provider hosts the model.

Constraints / preferences (optional)

  • First-match-wins pattern matching (patterns ordered from most specific to least specific)
  • Don't override settings that are already explicitly set on the model info
  • Easy to extend with new model families and settings
  • Backwards compatible with existing configurations

Request checklist

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

Acceptance criteria (optional)

Given a model ID containing "gemini-3" accessed through any provider
When the model info is retrieved
Then defaultTemperature should be 1 (if not already set)
And includedTools should contain ["write_file", "edit_file"] (if not already set)
And excludedTools should contain ["apply_diff"] (if not already set)

Given a model ID containing "gpt" or "openai" accessed through any provider
When the model info is retrieved
Then includedTools should contain ["apply_patch"] (if not already set)
And excludedTools should contain ["apply_diff", "write_to_file"] (if not already set)

Given a model with explicitly defined includedTools in its type definition
When model family defaults are applied
Then the explicitly defined tools should NOT be overridden

Given a new model family needs to be added
When a developer adds a pattern and defaults to the registry
Then all providers automatically apply those defaults

Proposed approach (optional)

  1. Create src/api/providers/utils/model-family-defaults.ts with:

    • A MODEL_FAMILY_REGISTRY array defining patterns and their default ModelInfo properties
    • An applyModelFamilyDefaults(modelId, info) function that applies first-matching family defaults
  2. Add helper method in src/api/providers/base-provider.ts:

    protected applyModelDefaults(id: string, info: ModelInfo): ModelInfo {
      return applyModelFamilyDefaults(id, info)
    }
  3. Update each provider's getModel() to call the helper (one-line addition each)

  4. Clean up duplicated settings from type definitions:

    • packages/types/src/providers/openai.ts - remove includedTools/excludedTools from model entries
    • packages/types/src/providers/gemini.ts - remove includedTools/excludedTools from model entries
  5. Delete src/api/providers/utils/router-tool-preferences.ts and remove its imports from openrouter.ts and requesty.ts

Trade-offs / risks (optional)

  • Requires updating ~35+ provider files (though each is a one-line change)
  • Pattern matching order matters - more specific patterns must come first
  • Existing type definitions that have settings will continue working (not overridden), so transition is safe
  • Model family detection relies on string patterns in model IDs, which could have edge cases

Metadata

Metadata

Assignees

No one assigned

    Labels

    EnhancementNew feature or requestIssue/PR - TriageNew issue. Needs quick review to confirm validity and assign labels.

    Type

    No type

    Projects

    Status

    Triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions