很多真正把 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 包：DeepSeek V4 Flash、MiniMax-M3 和阿里云百炼 Qwen3.7-Max。
MiniMax-M3 和 Qwen3.7-Max 已经通过真实的 API 调用、CLI 和 Codex Desktop 子代理运行验证。DeepSeek V4 Flash 已内置并通过隔离测试，不过我们仍在公共安装程序上做完整的运行时验证。
为了避免经典陷阱——在 API 调用上省了几毛钱，结果却换来一堆 API 密钥和本地配置的混乱——我在安全和安装方面设置了一些防护措施。API 密钥从 macOS 钥匙串读取；默认执行试运行；必须显式使用 --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 许可证。如果你也是 Codex 的重度用户，不妨试试。如果你觉得这个想法有用，点个 Star 就是对我最大的支持。谢谢！