起因：MiMo 额度告急

之前得益于MiMo的100T token计划， 我分到了七个亿的token，某天突然发现额度见底了。续费吧，价格不太美丽；降级吧，又不想牺牲体验。于是开始到处找替代方案。

复盘

说实话， 这个订阅计划看似量很足，实际上并不是很便宜。首先这是用Credits计费，而 Pro 模型每 token会双倍消耗 cerdits。
也就是说，如果用的是 mimo-v2.5-pro的话，看似七个亿的Credits,实际上对应的约等于3.5亿 token。并且实际使用下来发现Credits是没有缓存的概念的。那么有趣的来了，这几乎和直接使用api差不多，相当于按量付和一次买断的区别。

发现宝藏站

搜了一圈，再某个奇怪的地方发现了一个专门提供 GPT 5.5 大模型订阅的平台。和 MiMo 比，它的额度慷慨得多，价格也更友好。

参考 MiMo

同样是四个档位的套餐，最高 20 亿 token，看似与 MiMo 区别不大，只是稍微有性价比一点，因为是中转站的原因，担心掺水， 但是实际体验下来发现了一个有趣的现象：

有趣的现象

1. 同样是 6000 万 token 的基础套餐， 除了价格便宜一半以外，明显感觉消耗的更慢了。15 块钱在我全力 coding 的同时， 坚挺了三天居然还有一点剩余（MiMo 我记得一天就用了 6000 万的量）。
2. 确实没掺水，不晓得是怎么把成本压到这么低的。
3. 看似量很大，但同样把缓存也算进去了，但实际体验下来，第三档足够我一个月用了，因为它只算 token，没有区分模型， 也没有倍率，那么实际使用额度消耗很慢， 有 MiMo 对比会很明显。

不过这个平台有一个特点——它是专门为 Codex（OpenAI Codex CLI）设计的订阅服务，并不原生支持 Claude Code。

两条路：Codex 用户 vs Claude Code 用户

如果你用的是 Codex

那恭喜你，体验简直丝滑。操作步骤如下：

1. 登录平台，进入 API Key 管理页面
2. 点击 应用 按钮
3. 一条命令搞定 Codex 配置

就这么简单，不需要手动编辑任何配置文件，不需要折腾环境变量，一键到位。

然后像下面这样直接在 Codex 中使用即可（最近试了试 codex，感觉更适合我）。这里我让他写了个 AI 获客的系统，需求发给他我就去吃饭了，这是结果。

如果你用的是 Claude Code

这是关键。这个平台原生只对接 Codex 的 API 协议，和 Claude Code 的协议不兼容。但没关系，有一个叫 cc switch 的工具可以把 Codex 兼容的 API 转换成 Claude Code 能用的格式。

简单说就是：

平台 API (Codex 协议) → cc switch 转换 → Claude Code 正常使用

现状

现在呢，对于项目开发我一般都是直接使用 CodeX 了，它操作更方便，而且他内置的浏览器用来调整前端样式和 Debug是特别棒的， 就像真人操作浏览器一样。

最重要的是它节省了太多 Token。而且面对绝大多数的需求几乎是思考很久然后一步到位，不需要再修改。也不会出现一个文件改来改去的问题。

不知道是 GPT5.5 的原因还是工具的原因，它对整个功能更了解。我举个例子：
写一个 Service 方法时，有两个类需要用到 Hash 加密，而项目中之前就封转过 Hash 加密的工具类。 Claude code的做法是直接再旁边写了个私有方法去加密，两个类就写了两个加密的私有方法。

反观 Codex, 同样的场景它先尝试看看有没有能复用的， 于是找到了之前封装的工具类。而不是直接在旁边写个临时的私有方法。代码更加清爽，不容易出现屎山。

令我更振奋的是，有一次在一个功能迭代时，他发现要实现的新功能里的一些逻辑预谋个旧功能中有一部分重叠，他主动建议我将重叠部分拆层，这是我选择 codex的一个很重要的原因。毕竟用 AI 工具我最担心的一个是数据安全，另一个就是屎山（怼代码任何一个 AI 都能怼出来，但是怼出来的代码能不能给人用就比较有考验了）。

为什么推荐这个方案

对比项	MiMo	这个平台
模型	MiMo 自有模型	GPT 5.5
额度	偏紧	更充裕
Codex 一键配置	不支持	支持，一条命令
Claude Code 兼容	原生支持	需要 cc switch 中转

总结

• Codex 用户：直接上，零门槛，一键配置。
• Claude Code 用户：多一步 cc switch，但换来的是 GPT 5.5 + 更多额度，完全值得，虽然我已经弃。

如果你也遇到了 MiMo 额度不够的窘境，不妨试试这个方案。