提醒：DeepSeek 1M 上下文在 CCS 本地路由模式下不要填写 [1m] 后缀

[makoMakoGo]

这个问题用于补充 DeepSeek BYOK + Claude Code + CC Switch 本地路由模式下的配置说明。

下方两条评论分别说明：

1. 推荐配置做法
2. Claude Code 与 CC Switch 的代码证据

[makoMakoGo]

推荐配置做法

这里的关键区别是：[1m] 是 Claude Code 的客户端模型语法，用来让 Claude Code 启用 1M 上下文；但在 CCS 本地路由/代理模式下，CCS provider 里的模型字段会作为上游 API model 值参与映射，不能再当成 Claude Code 客户端语法来填。

1. 开启 CCS 本地路由/代理时

CCS provider 的模型字段不要带 [1m] 后缀，并且主模型 / ANTHROPIC_MODEL / Default model 建议留空。Default model 留空后，进入 Claude Code 时会自动使用 Claude Code 自己的默认 Opus 模型；这个模型本身就是 Claude Code 支持 1M 上下文的预设，刚好可以通过 CCS 的 Opus 映射转发到 DeepSeek 的真实上游模型名。

推荐填写方式：

主模型 / ANTHROPIC_MODEL / Default model：留空
Haiku：deepseek-v4-pro
Sonnet：deepseek-v4-pro
Opus：deepseek-v4-pro

等价到 provider env 时，不要把 ANTHROPIC_MODEL 固定成 deepseek-v4-pro；只保留需要的模型族映射即可，例如：

{
  "ANTHROPIC_DEFAULT_HAIKU_MODEL": "deepseek-v4-pro",
  "ANTHROPIC_DEFAULT_SONNET_MODEL": "deepseek-v4-pro",
  "ANTHROPIC_DEFAULT_OPUS_MODEL": "deepseek-v4-pro"
}

这样 Claude Code 负责本地 1M 上下文逻辑，CCS 只负责把 Opus/Sonnet/Haiku 这类 Claude 模型族映射到 DeepSeek 的真实模型名 deepseek-v4-pro。如果进入 Claude Code 后当前模型没有自动落到支持 1M 的 Opus/Sonnet，再用 /model 手动切换到 Claude Code 支持 1M 上下文的 Sonnet 或 Opus 模型/预设。

预期效果应类似：

Claude Code 默认 Opus / Sonnet 1M 预设 -> deepseek-v4-pro

需要避免的错误链路是：在 CCS 本地路由模式下把 provider 模型字段填成 deepseek-v4-pro[1m]。这样 CCS 会把 [1m] 当成上游模型名的一部分原样转发给 DeepSeek；DeepSeek 侧可能判定 deepseek-v4-pro[1m] 不是规范模型名，然后 fallback 到 deepseek-v4-flash。这时 CCS 统计页就会出现类似下面的记录：

deepseek-v4-pro -> deepseek-v4-flash

这里左边是进入 CCS 代理时 Claude Code 请求里的模型，右边是 DeepSeek 响应里声明的实际模型。

2. 不开启 CCS 本地路由/代理时

这种情况下 CCS 只是写 Claude Code 配置，不接管请求转发。此时可以按 Claude Code / DeepSeek 的直接配置方式使用 [1m] 后缀，因为 Claude Code 会用它开启 1M 上下文，并在真正发 API 请求前移除该后缀。

实测更清晰的填写方式是：

主模型：deepseek-v4-pro[1m]
Haiku：deepseek-v4-pro[1m]
Sonnet：deepseek-v4-pro
Opus：deepseek-v4-pro

不建议 Sonnet / Opus 也填写 [1m]，否则 Claude Code 的 /model 显示里可能出现重复后缀，例如：

Set model to deepseek-v4-pro[1m][1m]

这种重复后缀下游请求仍可能是正确的 deepseek-v4-pro，但显示非常误导，容易让用户误判 CCS 或 Claude Code 的模型映射行为。

[makoMakoGo]

代码证据与链路分析

1. Claude Code 侧：[1m] 是客户端语法，不是最终 API 模型名

排查 Claude Code 本地源码/还原源码时，可以看到 [1m] 主要用于本地上下文窗口和 beta header 判断。

在 src/utils/context.ts 中：

export function has1mContext(model: string): boolean {
  return /\[1m\]/i.test(model)
}

同文件的 getContextWindowForModel() 里，命中 [1m] 后会直接返回 1M 上下文：

if (has1mContext(model)) {
  return 1_000_000
}

在 src/utils/betas.ts 中，命中 [1m] 后会追加 1M context beta header：

if (has1mContext(model)) {
  betaHeaders.push(CONTEXT_1M_BETA_HEADER)
}

同时，Claude Code 在真正发 API 请求前会规范化模型名。在 src/utils/model/model.ts 中：

export function normalizeModelStringForAPI(model: string): string {
  return model.replace(/\[(1|2)m\]/gi, '')
}

在 src/services/api/claude.ts 构造请求体时，API model 字段使用的是规范化后的模型名：

model: normalizeModelStringForAPI(options.model)

所以 Claude Code 直连时的实际链路是：

deepseek-v4-pro[1m]
  -> Claude Code 本地识别 [1m]，启用 1M 上下文逻辑
  -> 发送 API 请求前移除 [1m]
  -> 上游实际收到 deepseek-v4-pro

2. CCS 本地路由侧：provider 模型字段会被原样用于映射

在 CCS 本地路由/接管模式中，src-tauri/src/services/proxy.rs 里定义了需要从 Claude live 配置移除的模型覆盖字段：

const CLAUDE_MODEL_OVERRIDE_ENV_KEYS: [&str; 6] = [
    "ANTHROPIC_MODEL",
    "ANTHROPIC_REASONING_MODEL",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL",
    "ANTHROPIC_DEFAULT_SONNET_MODEL",
    "ANTHROPIC_DEFAULT_OPUS_MODEL",
    "ANTHROPIC_SMALL_FAST_MODEL",
];

apply_claude_takeover_fields() 会把 Claude Code 的 base URL 指向 CCS 本地代理，并移除这些模型字段。这意味着本地路由开启后，Claude Code 不再直接使用 provider 里这些模型字段作为自己的模型配置；这些字段会变成 CCS 的代理映射配置。

在 src-tauri/src/proxy/model_mapper.rs 中，CCS 从 provider 配置读取模型字段：

ANTHROPIC_MODEL
ANTHROPIC_DEFAULT_HAIKU_MODEL
ANTHROPIC_DEFAULT_SONNET_MODEL
ANTHROPIC_DEFAULT_OPUS_MODEL

map_model() 会按照 haiku / opus / sonnet / default 做映射，并直接返回 provider 字段里的字符串。apply_model_mapping() 随后直接写回请求体：

body["model"] = serde_json::json!(mapped);

这里没有 Claude Code 那种 normalizeModelStringForAPI()。因此如果 provider 字段里填的是：

deepseek-v4-pro[1m]

CCS 就会把它作为真实上游模型名发出去。

3. 统计日志为什么会显示 pro -> flash

CCS 代理统计里的两个模型来源不同：

• request_model 来自进入代理时的请求体，见 src-tauri/src/proxy/handler_context.rs。
• model 来自上游响应 SSE 的 message_start.message.model，见 src-tauri/src/proxy/usage/parser.rs。

因此当日志显示：

deepseek-v4-pro -> deepseek-v4-flash

含义是：Claude Code 进入 CCS 代理时请求模型看起来是 deepseek-v4-pro，但上游响应声明实际模型是 deepseek-v4-flash。

本地日志中可以看到类似链路：

[ModelMapper] 模型映射: deepseek-v4-pro -> deepseek-v4-pro[1m]
[Claude] >>> 请求 URL: https://api.deepseek.com/anthropic/v1/messages?beta=true (model=deepseek-v4-pro[1m])
... "model":"deepseek-v4-flash" ...

这说明问题不是 CCS 统计页把模型显示错了，而是 CCS 本地代理确实可能把带 [1m] 的字符串当成上游模型名发给 DeepSeek；DeepSeek 对非规范模型名回退到 deepseek-v4-flash 后，统计页正确记录了这个差异。

[hwccurry]

解决了我的燃眉问题，谢谢～

[farion1231]

非常及时！

[farion1231]

@makoMakoGo 请问您有兴趣当本项目的 maintainer 吗？

[makoMakoGo]

@makoMakoGo 请问您有兴趣当本项目的 maintainer 吗？

可以

[farion1231]

@makoMakoGo 请问您有兴趣当本项目的 maintainer 吗？

可以

已经邀请您！方便的话可以发一个QQ之类的联系方式给我吗？farion1231@gmail.com

[michael-laoyu]

codex如何使用deepseekV4呢？deepseekv4不支持responses格式

[d-joshua-c]

太有用了, 意外发现这个改动可以适配 Claude code 新出的 auto mode, 如果按照 DeepSeek 官网的那个配置会显示 opus model unavailable, 按照换成上面的配置之后就正常了, 可以美美的烧 token 了; 并且 subagent 也恢复正常, 可以积极调用

[SpxZhu]

为啥我按照官方的配置, 也开启了CCS Proxy, 都能正确的路由到选定的模型啊...

[makoMakoGo]

为啥我按照官方的配置, 也开启了CCS Proxy, 都能正确的路由到选定的模型啊...

写issue前，我给DeepSeek员工反应过这个情况，可能优化了吧

[microbluey]

cc-switch + openrouter + deepseek v4 pro无法生效
如果配置了deepseek/deepseek-v4-pro[1m] 或者主模型不配置，/context 会生效，能看到变成 1m，但调用模型的时候会报：如下错误：
“ There's an issue with the selected model (deepseek/deepseek-v4-pro[1m]). It may not exist or you may not have access to it. Run /model to pick a different model.”

如果配置了deepseek/deepseek-v4-pro，则上下文只有200k