Feature Request: Support Provider-Specific Model Variants in Aliases #1

Problem

The current alias configuration appears to map a single alias to a model identifier.

Some providers, such as OpenAI, expose additional configuration dimensions beyond the model name. For example, GPT-5.5 can be used with different reasoning variants (e.g. low, medium, high) while still using the same underlying model.

Today, creating aliases such as:

• fast → GPT-5.5 with low reasoning
• balanced → GPT-5.5 with medium reasoning
• high → GPT-5.5 with high reasoning

is not possible without repeatedly specifying the variant elsewhere.

Proposed Solution

Allow aliases to support either:

Current format (backward compatible)

{
  "fast": "openai/gpt-5.5"
}

Array format

{
  "fast": ["openai/gpt-5.5", "low"],
  "balanced": ["openai/gpt-5.5", "medium"],
  "high": ["openai/gpt-5.5", "high"]
}

Object format (preferred)

{
  "fast": {
    "model": "openai/gpt-5.5",
    "variant": "low"
  },
  "balanced": {
    "model": "openai/gpt-5.5",
    "variant": "medium"
  },
  "high": {
    "model": "openai/gpt-5.5",
    "variant": "high"
  }
}

Why the Object Format Is Useful

The object format is more extensible and could support future provider-specific options without introducing additional breaking changes:

{
  "high": {
    "model": "openai/gpt-5.5",
    "variant": "high"
  }
}

Benefits

• Keeps aliases expressive and easy to understand.
• Supports providers that expose model variants separately from model names.
• Remains backward compatible with the current string-based configuration.
• Provides a path for future provider-specific settings.

Thanks for considering it. I think this would make aliases much more useful for workflows where the same model is used with different reasoning levels or execution profiles.