AiMaMi Codex 管理工具：账号额度、会话修复与智能路由怎么配

AiMaMi 是一款面向 OpenAI Codex 用户的开源桌面应用，集中处理账号与额度、历史会话、MCP 与 Skills、自定义指令，以及第三方模型 Provider 和中转服务的路由配置。项目基于 Tauri 2、React 与 Rust 开发，GitHub 仓库以 Apache License 2.0 发布，当前最新正式版本为 1.2.6。

定位需要先说清楚。Codex 现在已经不只有 CLI，OpenAI 的桌面端可以按项目管理线程、并行运行 Agent、查看代码 Diff，也支持 Worktree 等开发流程。AiMaMi 不承担这部分工作，它盯的是 ~/.codex 这个目录：账号凭证、TOML 配置、线程数据库、MCP 条目分散在其中，手工维护容易出错。

与官方 Codex 桌面端的分工

两者不构成替代关系，覆盖的是同一套环境里的不同环节。官方桌面端负责写代码本身，AiMaMi 负责维护这套本地环境。

官方 Codex 桌面端负责开发工作、AiMaMi 负责维护本地环境的分工对照图 — 图：官方 Codex 桌面端与 AiMaMi 覆盖的是同一套环境里的不同环节

只用一个 ChatGPT 账号、只调官方模型的用户，官方桌面端基本已经够用。AiMaMi 的价值出现在 ~/.codex 下配置变多之后——账号不止一个、Provider 不止一家、线程堆到几百条的时候。

会话管理与线程修复

AiMaMi 读取 Codex 本地线程索引，把不同项目下的历史会话集中展示，支持分析、批量清理和线程修复。

吃力的部分在修复。近几个版本反复处理的问题集中在几处：智能路由切换后左侧线程不可见、线程 Provider 记录不一致、SQLite 数据库被 IDE 或索引器占用导致写入失败。1.1.8 的更新记录写明，路由开关时的历史线程 provider 收敛改成了硬门禁加写后复查；Windows 下加入 SQLite 锁争用退避重试和占用进程检测，数据库被占用时会直接提示需要关闭哪个进程，而不是静默失败导致线程丢失。线程积累到一定规模之后，这部分的实际价值大于”浏览历史记录”本身。

MCP、Skills 与 AGENTS.md 管理

MCP 条目和 Skills 可以在界面里完成添加、启用、备份和恢复。自定义指令方面，AiMaMi 只管理 ~/.codex/AGENTS.md 中由它维护的那一段内容，提供预览和回滚，不整文件接管。这类功能不增加 Codex 的能力，作用是把频繁手改配置文件的出错概率压下来。对 MCP 机制本身还不熟悉的读者，可以先看 MCP 协议的工作方式拆解。

智能路由与中转模型

这是目前分量最重的一块功能。AiMaMi 可以配置第三方 Provider 和中转服务，通过协议适配让 Claude、DeepSeek 等模型出现在 Codex 的模型列表里，同时提供连通性测试、配置导入导出和路由诊断。1.2.6 补充了 deepseek-v4-flash 的 responses 协议适配，也修复了部分 Windows 机型开启路由后 GPT-5.6 系列模型缺失的问题。

有一个使用条件必须放在前面：中转模型的请求由 AiMaMi 在本机运行的代理转发，Codex 使用这些模型期间 AiMaMi 需要保持运行。请求最终仍然发往所配置的第三方 Provider，模型并不在本地推理。

智能路由开启后请求从 Codex 经 AiMaMi 本地代理转发至第三方中转服务的链路图 — 图：智能路由开启后，一次请求从 Codex 到目标模型实际经过的环节

这条链路意味着两层依赖。本地进程和远端服务任意一头出问题，Codex 里的中转模型就会失效。把它作为长期主力方案之前，这两层的稳定性需要分别评估。

账号状态与额度查看

仪表盘集中展示账号状态、5 小时与每周额度的消耗比例及重置时间，并支持账号导入导出与自动切换。项目说明给出的自动切换典型场景，是当前账号额度耗尽后寻找其他可用账号并重新启动 Codex。

功能本身方便，边界需要自己把握。多账号管理适用于管理自己正常持有和使用的账户，把自动轮换当作规避平台限制的手段属于另一回事，账号、额度、API 与第三方 Provider 的使用都需遵守对应服务商的条款。只想看用量、不需要这一整套管理能力的用户，CodexBar 这类菜单栏用量监控工具更轻量。

安装方式与源码构建

GitHub Releases 提供现成安装包，普通用户不需要预装 Node.js 或 Rust。当前 Release 覆盖的平台：

macOS：Universal 安装包 AiMaMi-1.2.6-universal.dmg，同时支持 Apple Silicon 与 Intel，要求 macOS 12 及以上版本
Windows：x64 安装包 AiMaMi_1.2.6_x64-setup.exe，Release 标注支持 Windows 10 / 11
Linux：README 标记为部分工作流尽力支持，目前不是主要 Release 平台

已安装的版本可以直接在应用内「检查更新」完成 OTA 升级。自行编译则需要 Node.js、pnpm、Rust 以及 Tauri 对应的系统依赖：

git clone https://github.com/borawong/AiMaMi.git
cd AiMaMi
pnpm install
pnpm tauri dev

打包生产版本使用 pnpm tauri build。

还有一条官方提醒：升级 AiMaMi 之前先把 Codex 更新到最新版本，否则智能路由、线程迁移和诊断功能可能出现兼容性问题。这句话从 1.1.1 一直挂到 1.2.6 的发布说明里，属于与宿主程序耦合较紧的项目常见的约束。国内下载安装包走的是 GitHub 域名，网络条件不理想时可能需要相应的网络环境或第三方镜像。

开源与数据链路的风险评估

仓库以 Apache License 2.0 发布，React 前端、Tauri / Rust 后端、构建脚本与项目文件都包含在内。早期版本文章里”账号、线程和智能路由属于私有闭源模块””自行编译只能获得基础功能”的说法已经不适用。

许可证解决的是代码可审计的问题，不解决数据链路的问题。AiMaMi 直接读写 Codex 的本地配置、账号信息和线程数据库，应用自身数据保存在 ~/.codex/codexmate/；一旦接上第三方中转，请求内容还会进入对应的第三方服务。涉及团队代码或商业项目时，评估对象不止 AiMaMi 一个，实际使用的 Codex 版本、模型 Provider 和中转服务需要一起纳入。项目也在 README 中声明与 OpenAI 无隶属、认可或赞助关系。

适用人群判断

只偶尔打开 Codex 写点代码、主要使用官方模型、几乎不碰 MCP 和 Provider 的用户，安装 AiMaMi 的必要性不大，官方桌面端已经覆盖需求。

把 Codex 当作长期开发环境的用户是另一种情况：同时跑多个项目、历史线程大量堆积、需要维护多套 MCP 和 Skills、经常修改 AGENTS.md、要在不同 Provider 与模型之间切换。这些场景下手改配置文件的频率足够高，图形界面带来的收益才成立。多账号用户的判断标准更简单：切换账号如果已经成为日常动作，这个工具就有意义。

想先把 Codex 本身的工作流搭起来，可以参考 OpenAI Codex 的完整使用教程；Codex 插件生态如何扩展，本地口播剪辑 Agent 的安装与能力边界是一个具体例子。