mimo2codex 是一个本地代理工具，核心功能是让最新版 OpenAI Codex CLI / 桌面端通过 Responses API 接入小米 MiMo、DeepSeek 等主流大模型，同时兼容 OpenAI Chat Completions 协议的其他 LLM。以下是其核心优势与缺点的结构化分析。

优势

1. 解决关键兼容性问题

• 突破小米 MiMo 官方限制：官方仅支持 Codex 的wire_api = "chat"模式，而最新版 Codex 已将此开关设为硬错误，官方建议降级到 0.80.0（会丢失新功能）
• 实现双向兼容：Codex 用最新版（保留宠物、桌面新功能、新工具），MiMo 服务端不变，无需修改任何代码或重新发包

2. 多模型灵活路由与集成

• 内置双核心支持：小米 MiMo V2.5 系列（pro/flash/omni）+ DeepSeek V4 Pro 系列，可按客户端model字段自动路由
• 通用 provider 机制：无需改代码即可接入几乎所有 OpenAI Chat Completions 兼容模型（Qwen/GLM/Kimi/Ollama/vLLM 等）或原生 Responses API（如 OpenAI 官方）
• 智能模型映射：未知模型字段自动 fallback 到默认 provider，支持自定义别名映射，管理更灵活

3. 完整能力适配与增强

• 工具调用全兼容：支持 function tools、并行调用、local_shell、custom、MCP namespace等高级功能
• 思维链透传：自动处理 MiMo 官方要求的多轮reasoning_content回传（≥0.2.3 版本），避免 400 错误或模型幻觉
• 视觉与联网优化：
  • MiMo 视觉模型（v2.5/omni）自动走视觉路径，pro/flash 自动剥图 + 占位文本
  • 联网搜索自动翻译成 MiMo 原生web_searchbuiltin，失败时自动重试并记忆状态
• 主机智能切换：根据 MiMo API 密钥前缀（tp-*/sk-*）自动选择 token-plan/pay-as-you-go 主机

4. 管理与运维便捷性

• Admin Web UI：提供模型清单、别名管理、聊天日志、Token 统计、Provider 配置等可视化功能
• 一键配置切换：v0.2.6 + 新增 "Codex 启用" 页面，原子写入配置文件并自动备份，原始配置永久保留
• 运行时覆盖：无需重启 Codex 即可动态切换上游模型，开发效率大幅提升
• sqlite 持久化：所有配置与日志存储在本地数据库，支持自定义数据目录
• cc-switch 集成：兼容多 CLI 工具管理中心，一键切换不同供应商

5. 成本与灵活性优势

• 接入高性价比模型：如 MiMo V2-Flash（$0.1 / 百万输入 token，$0.3 / 百万输出 token），成本远低于 OpenAI Codex
• 本地部署：无需依赖外部服务，数据隐私更有保障
• 混合使用：同一实例中可同时混用不同模型，按任务需求动态选择最优模型

项目架构

项目结构

mimo2codex/
├── src/
│   ├── cli.ts                  │   ├── config.ts               # 配置接口，默认值，环境变量/命令行参数解析
│   ├── server.ts               # HTTP 服务器，路由，请求生命周期
│   ├── translate/              # ← 核心：双向协议转换
│   │   ├── types.ts            #   共享类型定义 (Responses 与 Chat 结构)
│   │   ├── reqToChat.ts        #   Responses 请求 → Chat 请求
│   │   ├── respToResponses.ts  #   Chat 响应 → Responses 对象 (非流式)
│   │   └── streamToSse.ts      #   Chat SSE 块 → Responses SSE 事件 (流式)
│   ├── upstream/               # ← 核心：MiMo API 通信
│   │   ├── mimoClient.ts       #   带重试和错误映射的 HTTP 客户端
│   │   └── chatStream.ts       #   SSE 块解析器 (eventsource-parser)
│   └── util/
│       ├── ids.ts              #   基于 nanoid 的 ID 生成 (resp_, msg_, fc_, rs_, call_)
│       ├── log.ts              #   带脱敏的结构化日志
│       └── sse.ts              #   SSE sink 抽象 (HTTP + 内存，用于测试)
├── test/                       # 单元测试 (vitest)
│   ├── reqToChat.test.ts
│   ├── respToResponses.test.ts
│   └── streamToSse.test.ts
├── mimoskill/                  # 弥补 MiMo 功能缺口的配套技能 (图像生成等)
│   ├── SKILL.md                #   能力矩阵与决策树
│   ├── scripts/                #   generate_pet.py, install_pet.sh, mimo_chat.py
│   ├── references/             #   models.md, pet_workflow.md
│   └── assets/                 #   pet_prompt_template.md
└── scripts/                    # 安装辅助脚本 (install.sh, install.ps1)

内置模型

http://127.0.0.1:8788/admin

主要缺点与局限

1. 模型能力边界限制

• 宠物生成受限：Codex /hatch命令在客户端硬编码调用 OpenAI 图像 API，mimo2codex 无法拦截，需通过 mimoskill 脚本绕路（如 Pollinations.ai）
• MiMo agentic 能力不足：与 GPT 5.5 等主流模型相比，在多步推理和动态工具调用上仍有差距，可能出现 "自言自语" 不调工具的情况
• 视觉模型限制：仅 MiMo v2.5 和 v2-omni 支持图像输入，其他模型需自动剥图处理

2. 配置与兼容性门槛

• 环境变量管理复杂：需配置多个 API 密钥（MIMO_API_KEY/DS_API_KEY 等），不同系统（macOS/Linux/Windows）路径不同
• 版本依赖严格：需 Node.js ≥18，部分功能（如 reasoning 回传）要求≥0.2.3 版本，升级不及时会导致 400 错误
• Codex 客户端限制：上下文显示为 258k 而非 1M（Codex 官方客户端限制，与 mimo2codex 无关）

3. 功能与性能局限

• 图像生成缺失：MiMo 原生无图像生成能力，需依赖第三方服务（如 Pollinations.ai）或 OpenAI API
• 日志与监控：虽然提供 Admin UI，但高级监控功能（如实时性能分析）仍显不足
• 并行处理限制：部分复杂任务（如多轮 agentic 编码）可能因模型本身限制导致性能下降

4. 维护与支持挑战

• 社区驱动：开源项目，依赖社区维护，更新频率取决于开发者精力
• 故障排查复杂：需熟悉 Codex 和 MiMo 双方协议，部分错误（如 400 reasoning_content缺失）需专业知识定位
• API 变更风险：若 OpenAI 或 MiMo 更新 API 协议，可能导致代理失效，需等待适配更新

配置

mimo2codex init                       # 在 ~/.mimo2codex/ 下生成 .env + .env.example
# 编辑器打开 ~/.mimo2codex/.env 填入真 key
mimo2codex                            # 每次启动自动加载，banner 上会显示加载了哪些 key 名

运行

生成Readme.md

全面梳理当前项目工程代码所采用的全部技术栈，包括但不限于前端框架、后端语言及运行环境、数据库系统、第三方中间件、构建工具、部署依赖等核心技术组件，基于梳理结果生成一份规范、完整的ReadMe.md英文版文件，ReadMe-ZhCn.md中文版,ReadMe.md中链接关联ReadMe-ZhCn.md，生成过程需遵循以下要求：
梳理技术栈时需覆盖项目所有核心模块的技术选型，注明各技术的具体版本号，补充各技术在项目中的核心作用说明
ReadMe.md需包含标准的项目介绍、技术栈清单、环境依赖要求、本地部署与启动步骤、项目结构说明、开发规范、常见问题排查章节
技术栈清单需采用清晰的分类展示格式，区分前端、后端、基础设施、工具链四大类，确保层级分明
环境依赖要求需明确标注各依赖的最低兼容版本，避免环境冲突
本地部署步骤需编写可直接执行的操作指令，适配主流的Windows、macOS、Linux开发环境
最终生成的ReadMe.md需符合开源项目通用的文档规范，语言简洁易懂，无歧义，可直接用于项目托管平台展示