fix(core): default context windows to 200k - #6387
Merged
Merged
Conversation
Collaborator
Author
E2E verification reportValidated the bundled CLI after Result: the run reached the fake provider endpoint and reported a connection error. It did not fail locally with {
"hasHardLimitZero": false,
"hasConnectionError": true
} |
Contributor
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
Collaborator
|
Thanks for the PR! (Re-run after author response to review feedback) Template looks good ✓ Problem: Observed bug with clear reproduction. The installed build produces Direction: Aligned. Modern models (Claude 200K, GPT-5 272K, Gemini 1M) all exceed the old 128K fallback. The env-var consistency fix mirrors the existing modalities fallback pattern in Approach: Focused and minimal — constant bump, 8-line fallback using Moving on to code review. 🔍 中文说明感谢贡献！（作者回应审查反馈后的重新运行） 模板完整 ✓ 问题： 已观测到的 bug，有明确的复现。安装版在使用 方向： 对齐。现代模型均超过旧的 128K 兜底值。环境变量路径一致性修复复用了 方案： 聚焦且最小化——常量提升、使用 进入代码审查 🔍 — Qwen Code · qwen3.7-max |
Collaborator
Code ReviewIndependent proposal: To fix the env-var-only context window inconsistency, I'd add a fallback in Findings: Clean, minimal implementation. The fallback is placed correctly after the field resolution loop and before the modalities fallback. No code depends on No critical blockers or AGENTS.md violations found. Unit Tests
Before (installed build)After (this PR)Before: 中文说明代码审查独立方案： 修复环境变量路径的上下文窗口不一致问题，应该在 发现： 实现干净、最小化。兜底逻辑正确放置。vscode-ide-companion 的 复现对比Before: — Qwen Code · qwen3.7-max |
Collaborator
|
This PR fixes a genuine inconsistency: the same model gets different context-window assumptions depending solely on whether it was selected through env vars or provider config. The before/after tmux test confirms the fix — The implementation is a refinement over the initial push: All 329 unit tests across 3 test files pass. Build and typecheck clean. CI green (7 successful, 14 skipped, 0 failing). The before/after reproduction is convincing. Every change in the diff is necessary for the stated goal — nothing to cut, nothing to split out. The Approving. ✅ 中文说明这个 PR 修复了一个真实的不一致性：同一个模型仅因选择方式不同而得到不同的上下文窗口假设。before/after tmux 测试确认了修复效果。 相比初始提交有改进： 329 个单元测试全部通过。构建和类型检查均正常。CI 绿色（7 成功，14 跳过，0 失败）。diff 中每处变更都是实现目标所必需的。 批准 ✅ — Qwen Code · qwen3.7-max |
qwen-code-ci-bot
approved these changes
Jul 6, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
qwen-code-ci-bot
added
category/core
qwen-code-ci-bot
requested changes
Jul 6, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
[Critical] VSCode extension has stale DEFAULT_TOKEN_LIMIT (128K)
packages/vscode-ide-companion/src/utils/tokenLimits.ts:27 still has DEFAULT_TOKEN_LIMIT = 131_072 with a "Keep this file in sync with: packages/core/src/core/tokenLimits.ts" comment. This PR bumps the core constant to 200K but doesn't update the companion copy. The IDE's context-usage footer will compute thresholds against 128K while the CLI operates against 200K.
[Critical] DEFAULT_TOKEN_LIMIT blast radius broader than described
The global constant change from 128K to 200K affects ALL downstream ?? DEFAULT_TOKEN_LIMIT consumers (at least 6 sites: geminiChat.ts, client.ts, chatCompressionService.ts, contextCommand.ts, useContextualTips.ts, Session.ts), not just the env-var path. Any code path where contextWindowSize remains undefined (Qwen OAuth, managed-settings edge cases) silently shifts from 128K to 200K. Consider either keeping DEFAULT_TOKEN_LIMIT at 128K with a separate constant for auto-detection, or explicitly setting contextWindowSize in all non-env-var paths.
— qwen3.7-max via Qwen Code /review
- Use knownTokenLimit() in the env-var resolver fallback so unknown models keep contextWindowSize undefined instead of being labeled 'auto-detected from model' with the generic default - Add resolver tests: known limit differing from the default (gpt-4o), unknown model stays undefined, settings value not overridden - Recalibrate the config.getWarnings default-window test for the 200K fallback - Sync the vscode-ide-companion copy of DEFAULT_TOKEN_LIMIT to 200K
Collaborator
Author
|
Responding to the two review-level points (f5cbb4e): VSCode companion Blast radius of the default bump — this is the intended change, not an accident of the env-var fix: the PR deliberately moves the global fallback to 200K, and the tradeoff for smaller-window providers is called out in the Risk & Scope section. Keeping Also fixed the CI failure: |
yiliang114
approved these changes
Jul 6, 2026
yiliang114
left a comment
yiliang114
left a comment
Collaborator
There was a problem hiding this comment.
Thanks for the follow-up update. The latest revision addresses the previous review concerns for me: env-only known models now stamp contextWindowSize through knownTokenLimit(), unknown models stay undefined, and the companion DEFAULT_TOKEN_LIMIT copy is back in sync with core.
I also spot-checked the GLM path on this branch: OPENAI_MODEL=glm-5.2 resolves to contextWindowSize=1000000 with a computed source, so the 0.19.6 hard-limit-zero failure mode is covered. Local verification passed:
- cd packages/core && npx vitest run src/core/tokenLimits.test.ts src/models/modelConfigResolver.test.ts src/core/geminiChat.test.ts — 329 passed
- cd packages/core && npm run typecheck — passed
I do not see a merge blocker here. A dedicated glm-5.2 resolver regression test would be a nice follow-up, but the current gpt-4o / unknown-model / settings-override tests cover the behavior.
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
No issues found. LGTM! ✅
Downgraded from Approve to Comment: CI still running.
— qwen3.7-max via Qwen Code /review
Collaborator
|
@qwen-code /triage |
yiliang114
enabled auto-merge
July 6, 2026 12:31
qwen-code-ci-bot
approved these changes
Jul 6, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
This was referenced Jul 6, 2026
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
3 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.
What this PR does
This PR changes Qwen Code's global fallback context window from 128K to 200K and makes env-var-only model selection apply the same model-derived context-window defaults as provider-backed model selection. A model supplied through
OPENAI_MODELnow resolvescontextWindowSizefrom the existing token limit patterns when the user did not configure an explicit context window.Why it's needed
Provider-backed models already get model-derived context defaults, so Claude-family models resolve to their 200K input window when selected through
modelProviders. The env-var-only path resolved the model id but leftcontextWindowSizeunset, which made later compression logic fall back to the old generic 128K default. That inconsistency meant the same model could get different context-window assumptions depending only on whether it was selected through env vars or provider config.This is related to #6384, but it is not the same fix. #6384 is primarily about how much output budget Qwen Code should reserve by default and how to design that policy for models with large maximum output tokens. This PR addresses the input-context side: the generic fallback should be 200K, and env-var model resolution should respect the same token-limit patterns as provider-backed models. It does not attempt to settle the default output-token reservation tradeoff from #6384, though changing the fallback window naturally affects code paths that cap an output reservation against the fallback context window when no more specific window is available.
Reviewer Test Plan
How to verify
Run the focused resolver/token/compression tests and confirm
OPENAI_MODEL=claude-opus-4-6resolves a 200,000-token context window without requiring amodelProvidersentry. For the bundled CLI sanity check, run with a dummy key and invalid OpenAI-compatible base URL; the command should reach the fake endpoint and report a connection error, not fail locally withhard limit: 0.Evidence (Before & After)
Before: env-var-only Claude model selection left
contextWindowSizeundefined, so compression fell back to the generic 128K context window while output-token lookup still used Claude's model-specific output limit.After: env-var-only Claude model selection resolves
contextWindowSizeto 200,000 through the same token-limit patterns used for provider-backed model defaults, and the global fallback context window is 200,000 for unknown models.Commands run locally:
Bundled CLI sanity check result:
hasHardLimitZero: false,hasConnectionError: truewhen usingOPENAI_MODEL=claude-opus-4-6, dummy API key, andOPENAI_BASE_URL=http://127.0.0.1:9/v1.Tested on
Environment (optional)
Local Node/npm workspace, bundled CLI via
node dist/cli.jswith cleanQWEN_HOMEandQWEN_RUNTIME_DIR.Risk & Scope
contextWindowSizeexplicitly.Linked Issues
Related to #6384.
中文说明
What this PR does
这个 PR 将 Qwen Code 的全局兜底上下文窗口从 128K 调整为 200K，并让仅通过环境变量选择模型的路径使用与
modelProviders路径一致的模型派生上下文窗口默认值。当用户通过OPENAI_MODEL指定模型且没有显式配置上下文窗口时，现在会根据已有的 token limit patterns 自动解析contextWindowSize。Why it's needed
通过
modelProviders选择模型时，模型已经会获得派生出的上下文默认值，因此 Claude 系列模型会解析到 200K input window。但仅通过环境变量选择模型时，代码只解析了 model id，没有填充contextWindowSize，后续压缩逻辑就会回退到旧的通用 128K 默认值。这会导致同一个模型仅因为选择方式不同，就得到不同的上下文窗口假设。这个 PR 与 #6384 相关，但不是同一个修复。#6384 主要讨论默认应该预留多少输出 token，以及对于最大输出 token 很大的模型应该如何设计这套策略。这个 PR 处理的是 input context 侧的问题：通用兜底值应该是 200K，并且环境变量模型解析应该尊重与 provider-backed 模型相同的 token-limit patterns。这个 PR 不试图解决 #6384 中默认输出 token 预留策略的设计取舍；不过当没有更具体的上下文窗口可用时，兜底窗口变为 200K 会自然影响那些用兜底上下文窗口来限制输出预留上限的路径。
Reviewer Test Plan
How to verify
运行聚焦的 resolver/token/compression 测试，并确认
OPENAI_MODEL=claude-opus-4-6在没有modelProviders配置的情况下也会解析到 200,000 token 的上下文窗口。对于 bundled CLI sanity check，使用 dummy key 和无效的 OpenAI-compatible base URL；命令应该到达假的 endpoint 并报告 connection error，而不是在本地因为hard limit: 0失败。Evidence (Before & After)
Before: 仅通过环境变量选择 Claude 模型时，
contextWindowSize保持 undefined，因此压缩逻辑回退到通用 128K 上下文窗口；与此同时，输出 token lookup 又会使用 Claude 的模型特定输出上限。After: 仅通过环境变量选择 Claude 模型时，会通过与 provider-backed 模型默认值相同的 token-limit patterns 将
contextWindowSize解析为 200,000；未知模型的全局兜底上下文窗口也变为 200,000。本地运行的命令：
Bundled CLI sanity check 结果：使用
OPENAI_MODEL=claude-opus-4-6、dummy API key 和OPENAI_BASE_URL=http://127.0.0.1:9/v1时，结果为hasHardLimitZero: false，hasConnectionError: true。Tested on
Environment (optional)
本地 Node/npm workspace，使用 clean
QWEN_HOME和QWEN_RUNTIME_DIR运行 bundled CLI：node dist/cli.js。Risk & Scope
contextWindowSize，否则可能依赖 reactive context-overflow handling。Linked Issues
Related to #6384.