Still present in current main (verified today in src/utils/providerProfiles.ts); originally root-caused on 0.24.0.
Bug: when a provider profile lists multiple models (CSV in profile.model), the context-window env map is built as:
CLAUDE_CODE_OPENAI_CONTEXT_WINDOWS: JSON.stringify({
[getPrimaryModel(activeProfile.model)]: activeProfile.maxContextLength,
})(both call sites — the profile-env builder and the compatibility-env builder around lines ~1187 and ~1554). getPrimaryModel() returns only the FIRST entry of the list, so every other model in the same profile gets no entry and silently falls back to the hardcoded default window (128000 in 0.24.0).
Consequence: on any non-primary model of a profile, the context meter and auto-compact operate on the wrong window — over-compacting for big-context models, or (worse) never compacting in time and dying with an engine-side 400 on smaller ones. We hit this with local vLLM profiles where several aliases share one profile with maxContextLength set: only the first alias was protected.
Suggested fix: build the map over the whole parsed list — all models in a profile share its maxContextLength:
CLAUDE_CODE_OPENAI_CONTEXT_WINDOWS: JSON.stringify(
Object.fromEntries(parseModelList(activeProfile.model).map(m => [m, activeProfile.maxContextLength])),
)
Related but distinct: #2136 covers usage records reading zero on local OpenAI-compatible providers; this one is about the window map itself being incomplete, so it bites even once #2144 lands.
Still present in current
main(verified today insrc/utils/providerProfiles.ts); originally root-caused on 0.24.0.Bug: when a provider profile lists multiple models (CSV in
profile.model), the context-window env map is built as:(both call sites — the profile-env builder and the compatibility-env builder around lines ~1187 and ~1554).
getPrimaryModel()returns only the FIRST entry of the list, so every other model in the same profile gets no entry and silently falls back to the hardcoded default window (128000 in 0.24.0).Consequence: on any non-primary model of a profile, the context meter and auto-compact operate on the wrong window — over-compacting for big-context models, or (worse) never compacting in time and dying with an engine-side 400 on smaller ones. We hit this with local vLLM profiles where several aliases share one profile with
maxContextLengthset: only the first alias was protected.Suggested fix: build the map over the whole parsed list — all models in a profile share its
maxContextLength:Related but distinct: #2136 covers usage records reading zero on local OpenAI-compatible providers; this one is about the window map itself being incomplete, so it bites even once #2144 lands.