fix(core): bare deepseek-v4 alias never reaches the 1M token-limit rows
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=1000000Unit 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.
Source: QwenLM/qwen-code