解决 CC Switch 代理下小米 MiMo 模型在 Codex 中无法使用的问题。
使用 CC Switch 作为本地代理时，小米 MiMo 模型（mimo-v2.5-pro 等）在 Codex 中调用会返回 HTTP 404 或 HTTP 400 错误。原因有两个：
1. 端点格式不匹配（404）
Codex 使用 OpenAI Responses API 格式（/v1/responses），而 MiMo API 只支持 OpenAI Chat Completions 格式（/v1/chat/completions）。CC Switch 虽然内置了格式转换能力，会将请求转为 /v1/chat/completions 格式后转发，但如果 MiMo 的 endpoint 直接指向真实 API 地址，CC Switch 发出的请求路径可能不被 MiMo 服务器识别。
2. reasoning_content 回传要求（400）
根据小米官方公告，在 Agent 类产品（Codex、Cursor、TRAE 等）的多轮会话中，如果历史消息包含工具调用（tool_calls），后续请求必须完整回传 assistant 消息中的 reasoning_content 字段。缺少该字段时，MiMo API 将返回 400 错误。
受影响的模型包括：mimo-v2.5-pro、mimo-v2.5、mimo-v2-pro、mimo-v2-omni、mimo-v2-flash。
在 CC Switch 和 MiMo API 之间部署一个轻量 Node.js 中间件，它做的事情很简单：
- 接收 CC Switch 转发的
/v1/chat/completions请求 - 自动注入
thinking: { type: "enabled" }以启用 MiMo 思考模式 - 校验历史消息中
reasoning_content的回传完整性 - 将请求转发到 MiMo 真实 API 并原样返回响应（含 reasoning_content）
- 支持流式和非流式两种模式
请求链路：Codex → CC Switch (15721) → 中间件 (15722) → MiMo API
1. 复制文件
将以下文件放到一个固定目录（例如 C:\Users\<你的用户名>\.cc-switch\）：
mimo-proxy.js
start-mimo-proxy.bat # Windows 手动启动用
start-mimo-proxy-silent.vbs # Windows 静默启动用（无窗口）
2. 启动中间件
手动启动（有控制台窗口）：
node mimo-proxy.js或双击 start-mimo-proxy.bat。
静默启动（后台运行，无窗口）：
# Windows
wscript start-mimo-proxy-silent.vbs
# Linux / macOS
node mimo-proxy.js &3. 配置 CC Switch
在 CC Switch 中修改 Xiaomi MiMo 供应商的 API 请求地址，指向中间件：
http://127.0.0.1:15722/v1
4. 设置开机自启（可选）
将 start-mimo-proxy-silent.vbs 的快捷方式放入 Windows 启动目录：
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\
| 变量 | 默认值 | 说明 |
|---|---|---|
MIMO_PROXY_PORT |
15722 |
中间件监听端口 |
MIMO_HOST |
token-plan-cn.xiaomimimo.com |
MiMo API 主机地址 |
使用自定义配置示例：
MIMO_HOST=api.xiaomimimo.com MIMO_PROXY_PORT=18080 node mimo-proxy.js中间件启动报端口占用
# Windows: 查找占用端口的进程
netstat -ano | findstr 15722
taskkill /PID <进程号> /F
# Linux / macOS
lsof -i :15722
kill <PID>CC Switch 报熔断器触发（Circuit Breaker Open）
连续失败后 CC Switch 会触发熔断保护，暂时阻断请求。等待 60 秒后会自动恢复为半开状态，或在 CC Switch 中切换到其他供应商再切回 MiMo 即可重置。
MiMo 返回 400 错误
通常是多轮对话中 reasoning_content 缺失。确保 CC Switch 版本支持传递 reasoning_content，或在新会话中重新开始对话。
中间件本身不做 Responses API ↔ Chat Completions 的格式转换（CC Switch 已经内置了这个能力），它只负责：
- 注入思考模式参数 — 在请求 body 中添加
thinking: { type: "enabled" } - reasoning_content 校验 — 检测历史 assistant 消息中是否存在 tool_calls 但缺少 reasoning_content，发现异常时打印警告
- 流式透传 — 流式请求直接 pipe 转发，不缓冲
- 日志记录 — 打印每次请求的关键信息，方便调试
MIT