Problem
After a model failover, the session entry permanently locks to the fallback model via sticky model, modelProvider, modelOverride, and providerOverride fields. Subsequent messages never consult the agent's configured primary model again.
Root Cause
setSessionRuntimeModel() sets entry.model/entry.modelProvider to whatever model was used (including fallback)
applyFallbackCandidateSelectionToEntry() sets modelOverride/providerOverride with modelOverrideSource: "auto"
resolveGatewayRunModel() checks entry.model first — if set, returns immediately without consulting agent config
Evidence
MonicaHall configured with github-copilot/claude-sonnet-4.6 but all Telegram sessions stuck on azure/kimi-k2.5-thinking or azure/gpt-5.4 after failover events.
Proposed Fix
Re-resolve from config at run start: when modelOverrideSource: "auto" and the agent config primary differs, clear the override and use config.
Impact
Any agent experiencing one failover permanently runs on the wrong model until manually fixed.
Related
Problem
After a model failover, the session entry permanently locks to the fallback model via sticky
model,modelProvider,modelOverride, andproviderOverridefields. Subsequent messages never consult the agent's configured primary model again.Root Cause
setSessionRuntimeModel()setsentry.model/entry.modelProviderto whatever model was used (including fallback)applyFallbackCandidateSelectionToEntry()setsmodelOverride/providerOverridewithmodelOverrideSource: "auto"resolveGatewayRunModel()checksentry.modelfirst — if set, returns immediately without consulting agent configEvidence
MonicaHall configured with
github-copilot/claude-sonnet-4.6but all Telegram sessions stuck onazure/kimi-k2.5-thinkingorazure/gpt-5.4after failover events.Proposed Fix
Re-resolve from config at run start: when
modelOverrideSource: "auto"and the agent config primary differs, clear the override and use config.Impact
Any agent experiencing one failover permanently runs on the wrong model until manually fixed.
Related