The following comment was made by an LLM, it may be inaccurate:

No duplicate PRs found

Okay this is decent, but was wondering if this could be better...

I think the top level config should have a key called "fallbacks" which is an object that has 1 or two keys something like:

{
  "fallbacks": {
       "provider": {
            "anthropic": ["openai", "zai"]
        },
        "models":  {
            "anthropic/claude-haiku-4-5": ["openai/gpt-5-nano"]
        }
   }
}

Something like this, and it shouldn't be on the agents config I'd rather have it completely centralized and using the same providerID / modelID pattern we use everywhere else

Idk if this is the cleanest but thoughts?

Makes sense, centralized is cleaner.

A couple questions:

1. If both provider and models match, does model-specific take priority?
2. For provider fallbacks like "anthropic": ["openai"], how do we pick which OpenAI model to use?

I assumed the following while implementing it, please confirm if correct:

1. Model-specific fallbacks take priority over provider-level fallbacks.
2. For provider-level fallbacks (e.g. anthropic to openai), we pick the first available model from the target provider’s model list.

@rekram1-node

@rekram1-node When can we have this feature merged?

Will I be able to set this up for specific agents too? Or is this a global config?

Is this feature out?

Is this feature out?

Looks like its in review by maintainers

Thanks for the work on model fallback and the refactor, this is a useful step forward.

I’d like to suggest a slightly different abstraction that could make this more flexible and predictable long-term: introducing “virtual models” as a first-class concept in the configuration.

Instead of only defining fallback behavior on concrete models or providers, a virtual model would act as an alias to a set of real provider-specific models, together with a selection strategy.

Key idea

• Concrete models (e.g. anthropic/claude-opus-4.5) are always deterministic: selecting them always uses that exact model.
• Virtual models encapsulate dynamic behavior and are explicitly opt-in.
• The config defines:
  • the underlying models
  • how a model is chosen (round-robin, priority, sequential after rate limit, weighted, etc.)

Why this helps

1. Clear semantics: Explicit model selection never changes behavior. Dynamic selection is only used when a virtual model is chosen.
2. Operational control: Virtual models provide a single choke point for retries and switching policies, making it easier to reason about side effects, retries, and observability compared to implicit fallback on concrete models.
3. Extensibility: New strategies can be added without complicating fallback rules.
4. Consistency: Virtual models can be referenced anywhere a normal model can be used (global default, agent, session).

Example configuration

{
  "models": {
    "virtual/coding": {
      "type": "virtual",
      "strategy": "sequential",
      "models": [
        "anthropic/claude-opus-4.5",
        "openai/gpt-4.1",
        "openai/gpt-4o"
      ]
    },
    "virtual/fast": {
      "type": "virtual",
      "strategy": "round_robin",
      "models": [
        "openai/gpt-4o-mini",
        "openai/gpt-4.1-mini"
      ]
    }
  }
}

Semantics

• Selecting anthropic/claude-opus-4.5 always uses that exact model.
• Selecting virtual/coding delegates model choice to the virtual model’s strategy.
• Possible strategies could include:
  • priority
  • round_robin
  • random
  • sequential (on rate limit, failure, etc...)
  • weighted

This aligns well with ongoing discussions around native fallback and multi-provider usage, and could build cleanly on top of the current implementation without breaking existing configs.