If you rely on per-chat model aliases with a fallback default, you might be sending empty model requests to your LLM provider. A newly surfaced bug in alias resolution logic shows that the alias || default pattern executes before the alias string is actually resolved against the provider registry. This sequencing error means your configured default never gets a chance to kick in.

The Truthiness Trap

The core issue is JavaScript's evaluation order combined with truthiness checks. When a user specifies a per-chat model alias, that alias is stored as a non-empty string. In the expression alias || default, the non-empty alias evaluates as truthy immediately. The code returns the alias string without checking if that alias actually maps to a valid model ID in the current provider's configuration.

Resolution Happens Too Late

After the fallback logic determines the alias string is the winner, the system attempts to resolve that alias against the provider's model registry. If the alias doesn't exist in the registryβ€”perhaps due to a typo, a deprecated model, or a provider mismatchβ€”the resolution step returns undefined. This undefined value is then passed directly into the API request, effectively sending no model specification at all.

Silent Failures and Debugging Nightmares

This failure mode is particularly insidious because it doesn't throw a hard error during the fallback check. The code successfully picks the alias, successfully attempts resolution, and then silently submits a malformed request. Developers see unexpected API errors or default provider behavior instead of their intended fallback model, leading to hours of debugging configuration files that look perfectly valid.

Key Takeaways

  • Alias strings are truthy even when they don't map to valid models, causing || fallbacks to skip defaults.
  • Resolution against the provider registry must happen before fallback logic evaluates truthiness.
  • Sending undefined as a model parameter often results in silent API failures rather than explicit errors.

The Bottom Line

Stop using || for model fallbacks if you're dealing with aliases. Resolve the alias to a concrete model ID first, then check if the result is valid before falling back to your default configuration. Order of operations matters. Resolve, then fallback. Never the other way around.