fix(config): honor default_model in ResolveModelWithFallback before iterating providers#3994
Merged
esengine merged 1 commit intoJun 11, 2026
Conversation
…terating providers When a tab's stored model ref is stale, empty, or points to a removed provider, ResolveModelWithFallback jumped straight to scanning [[providers]] in order and picked the first one with a configured API key. Since deepseek-flash is first in the built-in defaults, it always won — even when the user had configured a different default_model. Fix: insert a middle step that tries c.DefaultModel before resorting to the provider iteration. This ensures the user's explicit preference is honored whenever the default provider is configured and has a valid API key. Fixes esengine#3801.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Fixes #3801
When the user configures a
default_model(e.g.glm5) but that model is not the first provider in iteration order,ResolveModelWithFallbackignores it and falls back to the first configured provider instead. This causes new conversations to be assigned the wrong model (e.g.deepseek-v4-flash), forcing the user to manually switch every time.Root Cause
ResolveModelWithFallbackhad only two paths:There was no check for the user's
DefaultModelbetween step 1 and step 2.Fix
Added a
DefaultModelpreference check between the direct-resolve and the provider-iteration fallback:DefaultModelfirst (skip if the stale ref was the DefaultModel — it already failed above, so retrying is pointless)Configured()gate on the provider-iteration path)Changes
internal/config/config.go— 3-line block added toResolveModelWithFallbackinternal/config/model_fallback_test.go— new testTestResolveModelWithFallbackHonorsDefaultModelcovering empty ref, stale ref, and keyless-default → next-configured chainingVerification