很多真正用 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 密钥和本地配置——我在安全和安装方面加了一些保护措施。API 密钥从 macOS Keychain 读取；默认执行 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 就是最大的支持。谢谢！