Claude Code 经 CC Switch 调用国内模型仍慢于 OpenCode，核心原因是协议转换开销、架构设计差异及潜在的风控检测机制，而非数据回传美国导致延迟（数据实际发往国内模型）。

核心原因解析

1. 协议转换与中间层损耗：Claude Code 原生使用 Anthropic 私有协议，CC Switch 需拦截请求、解析 Body、将 Anthropic 格式转换为国内模型兼容格式（如 OpenAI 标准），再逆向转换响应；此“拦截 - 转译 - 转发 - 回译”链路增加额外 CPU 耗时与网络跳数（通常增加 80-150ms TTFB），而 OpenCode 原生支持多协议直连，无此转译层 。

2. 上下文加载机制差异：Claude Code 默认采用全量或激进上下文策略以维持其“结对编程”连贯性，即便换模型也未完全适配国产模型的短上下文特性，导致单次请求 Token 体积大；OpenCode 更倾向于按需加载或轻量拼接，请求包更小，传输与推理启动更快 。

3. 内置风控检测干扰：2026 年 4 月后版本（如 2.1.91+）在检测到代理或中国时区时，会触发隐蔽的时区/域名校验逻辑及提示词隐写标记过程，虽不直接回传数据至美国（当使用 CC Switch 指向国内 API 时），但本地执行检测与字符替换操作消耗了计算资源并阻塞了部分异步流程，造成体感卡顿 。

4. 网络链路拓扑不同：CC Switch 作为本地代理（localhost:8899）需维持双连接（Client↔Switch↔Model），若 Switch 配置非最优节点或存在健康检查轮询，会引入抖动；OpenCode 支持配置直连国内厂商 API，减少中间环节 。

关于“数据回传美国”的澄清

- 无直接影响：当通过 CC Switch 正确配置指向国内模型（如 DeepSeek、通义千问等）时，业务数据（代码、提示词）直接发送至国内服务器，不会回传至 Anthropic 美国服务器，因此跨国网络延迟不是主因 。

- 潜在风险点：被曝光的“隐写/标记”代码是在本地客户端执行，将识别信息编码进发送给当前目标模型（即国内模型）的请求头或提示词中，由国内模型转发或丢弃，并非直接回传美国；但此本地处理过程本身增加了延迟 。

优化建议

- 切换模式：在 CC Switch 中开启“直连模式”或关闭非必要健康检查，减少代理层开销。

- 降级上下文：手动限制 Claude Code 的上下文窗口或启用精简模式，减少单次请求负载。

- 验证版本：确认 CC Switch 及 Claude Code 为最新修复版（移除检测逻辑的版本），避免旧版风控代码拖慢速度 。

- 对比测试：同一国内模型下，对比 OpenCode 直连与 CC Switch 中转的 TTFB，若差距显著缩小，则证实为协议转换损耗 。

综上，速度差异主要源于工具架构的“重壳”特性与本地检测逻辑，而非数据出境网络延迟。若追求极致速度且使用国产模型，OpenCode 的轻量直连架构更具优势 。