很多真正用 Codex 做正经工作的人，都会遇到一个很现实的问题：配额根本不够用。如果你只是偶尔玩玩，Plus 可能就够了。但一旦你开始用 Codex 写代码、调试、拆解任务、做研究或管理项目——而且使用频率上来了——你就会开始琢磨：有没有办法能继续像现在这样用 Codex，但整体花费能少一点？
这正是我最近开源 Codex Third-Party Workers 的原因。我的想法很简单：不要让每个任务都花一样的钱。
在这之前，Codex 处理所有事情——无论大小、无论类型——都走同一条流水线。现在我在 Codex 的工作流里加了一个任务调度层。Codex 仍然是主代理：它理解任务、拆解任务、判断该做什么、审查并做最终把关。但一些适合外包的子任务可以交给更便宜的第三方模型 API。等这些子任务完成后，结果会回到 Codex。简单来说：用户给任务 → Codex 理解并拆分 → 合适的子任务交给第三方 Workers → Workers 完成 → 结果返回 Codex → Codex 复核并收尾。
所以这个项目不是要取代 Codex，而是要解决一个更实际的问题：怎么让你的 Plus 配额更耐用？
对 Plus 用户来说，我觉得这真的很重要。如果你只是偶尔打开 Codex 用一下，那真不用太纠结成本——免费版就够了。但一旦 Codex 成了你的日常主力工具，你怎么分配配额、哪些任务留在 Codex、哪些可以交给更便宜的模型——这本身就变成了一个值得优化的问题。
我的目标是：确保你的 Plus 配额花在你真正想让 Codex 做的事情上。其他能外包的都交给低成本的 Provider API。
这不是说要免费白嫖 Codex——第三方 API 还是要花钱的。你真正在优化的是整个 AI 工作流的平均成本。同样的项目，全部走一个昂贵的流水线，和根据任务类型分流处理——最终账单可能差很多。
所以我一直强调：不要让每个任务都花一样的钱。
目前 Codex Third-Party Workers 已经内置了几个第三方 Provider Pack：DeepSeek V4 Flash、MiniMax-M3 和阿里云百炼 Qwen3.7-Max。
MiniMax-M3 和 Qwen3.7-Max 已经通过真实 API 调用、CLI 和 Codex Desktop 子代理运行验证。DeepSeek V4 Flash 已内置并通过隔离测试，不过我们还在对公开安装包做完整的运行时验证。
为了避免那种经典陷阱——API 调用省了几毛钱，结果换来一堆乱七八糟的 API key 和本地配置——我在安全和安装方面加了一些保护措施。API key 从 macOS 钥匙串读取；默认是 dry-run 模式；必须显式使用 --apply 才会真正生效；第三方 Workers 只处理边界清晰的任务；最终结果仍然回到主 Codex 线程进行审查。当前基线已通过 37/37 项隔离测试。
当然，它还是 Beta 版。目前只支持 macOS，而且你需要 Codex Desktop、自定义子代理支持，以及 Node.js 20+。Windows 正在测试中，应该也能用。另外请记住——第三方 Provider API 是单独计费的。所以这不是什么"装上 Codex Third-Party Workers 之后 Plus 就能永远用不完"的神药。
每个人的使用频率、任务构成和第三方定价都不一样。但如果你是个重度 Codex 用户，我的建议是：看到配额吃紧别慌，别急着升级到更贵的套餐。先认真看看你的任务是怎么消耗配额的。哪些任务必须用 Codex？哪些可以外包？你的 Plus 配额健康消耗节奏是什么？搞清楚这些之后，再加上更便宜的第三方模型 API，你就能用更低的总成本完成更多工作。
这就是我做这个开源项目想解决的真实问题。不是要少用 AI，而是花得更少，做得更多。
项目链接：https://github.com/dhy365-creator/codex-third-party-workers
完全开源，MIT License。如果你也是重度 Codex 用户，可以试试。如果你觉得这个想法有用，点个 Star 就是最大的支持。谢谢！