#12122·qwen-code

fix(core): bare deepseek-v4 alias never reaches the 1M token-limit rows

Author: he-yufengCreated Sep 17, 2026Updated Sep 17, 2026
Labelspriority/P2type/bugcategory/corescope/token-management

What happens

qwen -m deepseek-v4 shows a 128K context window even though packages/core/src/core/tokenLimits.ts has a /^deepseek-v4/ → 1M input row and a /^deepseek-v4/ → 384K output row. For the bare alias both rows are dead.

Measured on current main by driving the CLI in tmux and reading /context (credit: @qqqys, verification in #11909):

deepseek-flash         normalize=deepseek-flash     input=1000000
deepseek-v4            normalize=deepseek           input=131072
deepseek-v4.1-flash    normalize=deepseek-v4.1-flash input=1000000

Unit level it reproduces as tokenLimit('deepseek-v4') === 131072 where 1000000 is expected.

Root cause

normalize() strips trailing -v\d+(?:\.\d+)* as a version tag (tokenLimits.ts, the "remove trailing build / date / revision suffixes" step). For the bare alias that suffix IS the model generation: deepseek-v4 collapses to deepseek and matches the generic /^deepseek/ → 128K fallback before the table sees it. Names with anything after the version (deepseek-v4.1-flash) keep the prefix and hit the V4 rows, which is why only the bare alias is affected.

Proposed fix

Exempt the deepseek-v4 family from the trailing-version strip, using the same guard idiom already in place for qwen-plus-latest / qwen-flash-latest / qwen-vl-max-latest / kimi-k2-0905 a few lines above. The limit rows are prefix-matched, so keeping the family prefix intact is sufficient; nothing else about normalization changes.

I have the patch and regression tests ready and will open the PR shortly.

Environment

qwen-code main @ 4eda03bf5eec (also reproduces on the #11909 head), macOS arm64, Node 22.