你是不是常常觉得 Codex token不够用？
有什么办法可以使用ChatGPT的免费额度？
本文提供一个被多方验证的思路：把业务数据以受控的只读接口接入 ChatGPT，让 GPT-6 Pro 先分析并提出方案，再由 Codex 验证和实施。
为什么把规划放在 ChatGPT 里
OpenAI 将 Chat 中 GPT-6 Pro 的消息额度与 Work、Codex 的使用额度分开。按当前帮助文档，Pro 100 美元档每周有 50 条 GPT-6 Pro 消息，且与 GPT-5.6 Sol Pro 共用这 50 条；Pro 200 美元档每周有 200 条 GPT-6 Pro 消息。两种额度都不是无限量，用之前应查看自己账户显示的剩余额度和重置时间。这里说的是订阅档位与 Chat 消息数，不是 API 调用次数或可兑换的 Codex token。(OpenAI：Chat 中的模型与额度，Work 与 Codex 额度说明)
图 1｜依据 OpenAI 的 Chat 模型额度与 Work/Codex 用量说明绘制；显示的是截至 2026 年 10 月 3 日的套餐规则，不是账户实时余额。
卡兹克经营 AIHOT，称自己需要分析接近 2000 个信息源带来的成本、请求量与缓存表现。他此前在 Codex 里用高强度模型做规划，估计一次复杂分析可能耗去个人账户约 10% 的周额度。这是作者的使用记录与估算，不能套用到其他账户。
规划质量取决于给它什么数据
代码和 PR 能说明系统如何设计、怎样一步步修改，却未必能回答昨天某项模型调用花了多少钱，或高峰期的缓存命中率是多少。卡兹克因此用 Codex 为 AIHOT 做了一个连接生产数据的只读 MCP 服务，并通过飞书身份认证限制使用者。他在 ChatGPT 对话中同时接入自建应用和 GitHub，让 GPT-6 Pro 对照业务指标、代码与修改记录提出降本方案。
这一步的关键不是把整台服务器“开放给 AI”。先列出决策所需的指标，再只开放对应的查询能力。例如按天汇总调用费用、请求峰值和缓存命中率；只返回必要字段，限制查询范围、频率与耗时，并记录访问。密钥、个人信息和无需用于分析的明细不应随查询返回。
OpenAI 的文档说明，Pro 用户可以在开发者模式下连接具备读取或获取权限的自定义 MCP 应用；ChatGPT 连接的是远程 MCP 服务，本机或私网服务不能直接接入。OAuth 授权还需要考虑令牌续期。能否在你的账户里选到应用，也取决于套餐、界面和权限。(OpenAI：开发者模式与 MCP 应用)
图 2｜依据 OpenAI 的 MCP 应用说明及原作者流程绘制的示意图；并非 AIHOT 实际部署图。
方案回到 Codex 后，先验证再动生产环境
流程是：在桌面端的 Quick Chat 里选择 GPT-6 Pro 和相关应用，提出降本需求；拿到方案后用“添加到 Codex”继续开发。
这次分析花了约 40 分钟，随后 Codex 的实施又消耗了约 4% 的周额度。这些时间、额度和方案质量均为作者自述，未见可供独立复核的完整任务记录；界面入口也可能随版本变化。OpenAI 当前文档确认桌面端 Codex 可打开 Quick Chat。(OpenAI：ChatGPT Work 与 Codex)
真正值得保留的交接物是可检查的方案：每条建议对应什么数据，预计改善什么指标，怎样验证，失败时如何回退。把这些交给 Codex，要求它先核对数据与代码，再逐项实施、测试和评审。涉及生产发布时，让有权限的人审核结果与变更。一个“把所有优化统一上线”的提示词，不能替代这些判断。
值得试的前提
如果你已有 Pro 订阅，且规划经常要同时参考私有业务数据与代码，这种分工可能让 Chat 中尚未使用的额度承担一部分分析工作。它并不保证节省 10%，也不意味着 MCP 只读就“没有风险”：查询仍可能泄露敏感数据、拖慢生产库，外部内容也可能带来提示注入。接入前还应检查数据设置：OpenAI 说明，个人 Pro 账户若开启“为所有人改进模型”，应用访问的信息可能用于训练。自定义应用的适用性仍需使用者自行审查。(OpenAI：MCP 应用安全说明，应用数据使用说明)
可以从一个小问题开始：只开放一项聚合指标，让 ChatGPT 给出可验证的分析，再与原来在 Codex 中完成同类任务的结果和额度消耗比较。若判断质量足够、数据边界也可控，再扩大范围。