Codex额度指南v0.9：怎么烧额度更合理？
怎么充分利用Codex额度？个人总结：开源、节流、结构化积累。百亿token烧出来的经验。
全文约7500字。部分技巧：
- Claude Code来的用户，考虑多多利用ChatGPT，不占Codex额度，可以连接GitHub。除了常规调研、讨论，还有比Codex更优的生图、Pro模型；
- OpenAI有风控，薅羊毛要有度，越线不仅可能有风控，还可能导致全体用户福利下降；
- 尽可能开新会话。如果任务比较复杂，4轮对话算比较经济的。如果模型出现严重错误，立刻开新会话；
- 考虑到等待时间，Fast实际上没有1.5倍速，对比开与不开Fast的任务，完成时间中位数，Fast速度是1.2到1.3倍；
- 可以用线框图、UML、GPT Image2画图等，初步确认需求。
开源：薅羊毛？额外额度？
ChatGPT
不跟实际用户沟通，我完全没想到有不少用户：
- 只用Codex，完全不考虑用ChatGPT；
- 想用ChatGPT，结果曾经被诱导到工作（Work），没有切换，然后以为ChatGPT网页端也消耗额度；
- 不知道Pro用户可以在ChatGPT网页端用Pro模型，这个模型比5.6 Sol要好一些；或者之前Pro模型被默认路由到5.5 mini，认为这个没什么用，但这个问题不久前修复了，可以试试。
- 不知道ChatGPT可以连接GitHub，可以提PR。结合上一点，可以用目前最好的Pro模型查阅自己的代码，给方案。
前两点的用户，无一例外，之前都用过Claude Code。
怎么利用ChatGPT节省额度呢？
- 简单对话，至少能简单做一些调查工作；
- 画图。网页端生图质量比Codex好，前者GPT Image 2默认参数是高，后者为低。后文会讲一种简单网页的设计方案，会用到这个画图；
- 看到别人的Github，尤其是Skills，直接把链接扔给ChatGPT，然后让它鉴定。指令就只用说「鉴定」两个字，也可以自行微调，比如重点放在安全检查；
-
甚至如果你及时把代码仓库放GitHub，它也能写代码，直接给你PR（包括私有仓，需要配权限）；
- 文档参考：Connecting GitHub to ChatGPT ；
- 后续想卸载或更改GitHub设置，可以去Applications选ChatGPT应用；
- 缺点是思考强度受限，且开发不够方便。
不知道为什么官方文档写着：ChatGPT 的 GitHub App 本身只读；要编辑、提交并推送代码，应使用 Codex。但实测ChatGPT可以提PR。
透支额度、邀请朋友与风控
之前，Codex有个很简单的“透支额度法”，就是额度快归零的时候，选择Full access，开不同会话、同时发送一些以前积累的问题，甚至可以用goal。GPT5.5的时候，已经很轻易能跑Plus 20%周额度。
可惜被人薅没了：
8月21日左右，有人用“透支额度法”钻空子，能稳定透支相当于800美元API的额度（比没有重置的Pro账号周限额高了），并且在社交媒体推广稳定复现方案，引发大规模恶意使用。
这件事很可能直接导致23日策略调整，25日Plus五小时额度回归，且所有人不能再透支Sol模型额度。5小时限额，部分Plus账号有一定量Luna额外额度（Luna Reserve）。
官方的表态是，知道有人会透支额度薅羊毛，不过觉得可以接受，但这次事件太严重。
拜托有Plus的网友验证了一下，5小时额度只有Luna不会主动中断，另有Luna额外额度。
周限额到0%后，直接停任务，至少参与观察的账号，没有官方文档所谓的fair-use limits，至少没多少额度（不过样本不多，这几天重置太频繁了）。
为什么研究这些呢？除了薅羊毛，**很多人日后也是额度提供方，**OpenAI的应对方式，很值得借鉴。善意对待用户，很多用户都会感激，但不能假定所有用户都善意。
OpenAI除了明面上改策略，还可以加强风控。比如，针对各类薅羊毛的中转站，削减了免费用户福利，加强了Codex免费用户的校验。几个月前谷歌甚至把Antigravity的订阅削废了。这些实际上削弱了用户福利，而且可能“误伤”「我就给十几个不同地区的设备/朋友用用」的人——共享账号额度的行为，一直明令禁止，且很好找出。
还有邀请“朋友”获取额度。之前是直接获取重置额度的次数，估计也被某海鲜市场薅羊毛了。你猜购买“海鲜朋友”，风控会不会加分？
OpenAI风控是静悄悄的，包括降智跟降额度。不会事前给你提醒，不会事后给你退款（甚至降智、降额度也不告诉你）。虽然风险邀请“海鲜朋友”相对较低，但风控一般是积分制，一点点做危险行为，说不定哪一天你分数就到了。
珍惜账号、网络IP、时间跟精力。
另外，明明ChatGPT网页应用「不得自动或以编程方式提取我们服务中的数据或输出内容」，但好像每隔一段时间都有人“重新发现”可以用脚本薅ChatGPT网页的羊毛。代价由使用者付。
总之，薅羊毛要有一个度，不能“批量化”。
节流：具体操作、数据分析
一览
- 不要在同一个会话下一直对话，输入缓存不是免费的。一般问题4轮问答应该是“甜心点”，简单问题保持一次解决；
- 中途补充对话（steer）有小概率导致本轮token消耗翻倍，但问题不大，该补就补。
- 思考强度显著增加token消耗；
- Fast模式2.5倍额度消耗，1.5倍速度。但比子代理收益稳定。
几时新建会话
不要在同一个会话下一直对话，输入缓存不是免费的。上下文压缩也并非万能。
有人觉得新会话跟缓存过期后亏，但一轮问答，常见的编程问题中，agent会自行发送几十次请求。无论有没有缓存，缓存输入还是远高于普通输入。
近期数据
如果认为，有大量简单问题拉低了一轮对话的中位数，那么，对一般问题，4轮问答应该是“甜心点”，或者从上下文压缩角度看，压缩后问是相对经济的。
简单问题最好一次解决。
涉及模型GPT 5.6 Sol，「压缩次数」全称是「上下文压缩次数均值」；「普通输入」到「换算API价」列，口径则是按轮平均的中位数。
| 会话轮数 | 会话数 | 压缩次数 | 普通输入 | 缓存输入 | 输出 | 推理输出 | 换算API价 | 峰值上下文 P25–P75 |
|---|---|---|---|---|---|---|---|---|
| 1 | 171 | 0.13 | 9.9万 | 118.76万 | 1.13万 | 5236 | US$1.278 | 5.12万–16.92万 |
| 2 | 105 | 0.44 | 10.09万 | 231.86万 | 1.4万 | 6534 | US$2.087 | 9.51万–22.22万 |
| 3 | 64 | 0.64 | 10.3万 | 221.01万 | 1.35万 | 5854.5 | US$1.885 | 12.53万–22.77万 |
| 4 | 37 | 0.68 | 9.87万 | 206.17万 | 1.05万 | 4574 | US$1.549 | 14.51万–22.68万 |
| 5 | 19 | 1.05 | 9.73万 | 271万 | 1.1万 | 4560.6 | US$1.736 | 17.75万–23.47万 |
| 6 | 17 | 1.88 | 13.92万 | 287.84万 | 1.37万 | 6326.17 | US$2.648 | 21.46万–23.94万 |
| 7 | 12 | 2 | 10.43万 | 271.75万 | 1.46万 | 7453.86 | US$1.805 | 21.5万–22.99万 |
| 8 | 11 | 2.45 | 12.93万 | 451.6万 | 2.21万 | 7523.88 | US$3.026 | 20.75万–24.37万 |
| 9–12 | 9 | 2.22 | 14.49万 | 437.8万 | 1.58万 | 6282.08 | US$3.406 | 22.32万–24.46万 |
| 13–64 | 11 | 7.73 | 14.51万 | 351.38万 | 1.67万 | 5158.81 | US$2.943 | 22.5万–24.38万 |
如果你觉得这个因人而异，也可以考虑使用AIY的拓展「Codex今天努力了吗」来自行统计。
具体案例：Git提交
这块数据就比较脏，不好比较。且应该缺了不少。但至少有初步结论：单独用便宜模型管Git提交，最便宜。
| 场景 | 实际样本 | 每 commit token 中位数 | 估算价 |
|---|---|---|---|
| Sol 含提交任务，跟Sol中位数相减，每提交均摊 | 66 commits | 2.196M | $1.35 |
| 另开 Sol，只做提交 | 26 commits / 4 sessions | 0.697M | $0.412 |
| 同 session，Ultra 单独补提交 | 3 commits | 1.160M | $0.66 |
| 另开 Luna，只做提交 | 32 commits / 9 sessions | 0.235M | $0.0081 |
由于这几天额度比较多，正在顺便做这个干净一些的Git提交实验了。不过结果应该大差不差。
模型犯傻？直接毙掉
模型犯错、犯傻了，考虑直接放弃这个会话。错误上下文会带来严重误导，可能还会让它傻几次，估计大模型也有「路径依赖」。
比方说，下图它写的编辑器状态管理有问题，导致编辑器会莫名快速添加回车，但这个Agent没找出问题，开始怀疑起其他应用，方向完全错误。就算后续排除了一个应用，它还是会怀疑其他应用。想通过几句话将方向调转，也比较难对抗前面的一堆错误上下文，不如新开重新试。
还有自以为没什么问题的，也是“枪毙”会话，换一个。
多开会话还有额外好处：
- 加载速度变快
- 方便换模型跟思考强度
- 不怕缓存过期
坏处也有：不好找对话，Codex应用聊天搜索也很烂。虽然可以用Codex帮忙找，不过考虑到这是节省额度的指南，还是弄个AIY的拓展吧：
当然，应该也有统一管理各类Agent聊天记录的软件。可以自行（让ChatGPT）搜索。
中途插话
仅讨论“本来可以一次发完”的情况，而不是中途看到有问题，纠正方向。
从数据角度分析，主要看插话的时候，Codex在干什么：
- Codex本来就要继续调用工具。看起来没什么影响；
- 如果Codex 已经回答完，用户才补一句本来可以开头说的话，那么会引发一次完整输入，可以视为输入 token 翻倍。发生率估算1.86%（在Codex中）。
从需求角度分析，如果经常一开始想不清楚，或者遗漏信息，那么还是先跟ChatGPT聊一下，补充较为完整后再找Codex。
思考强度显著增加token消耗
跟任务无关。同一会话内，每升一级 effort，总 Token ×1.240、输出 Token ×1.405、reasoning Token ×1.654，均显著。
注意：数据只反映某种总体趋势，不能直接说一定会这样增加。
不过，选择思考强度的最大问题是，用户很难搞清楚，怎样的“模力”才足够解决问题。如果“低模力”没有解决，浪费的时间跟验收精力，又怎么算？
这有点像灯光，弱了容易看不清、对眼睛有害，但太强，不仅没必要，而且有害。比如，想过头、防御性编程。
目前只能尝试。总体来说，需求相当明确的任务，给Luna一般都行。至少前面提到的git提交，可以交给它。（有网友说自己用Antigravity免费额度来做提交）
不过，日后“动态调节思考强度”肯定会成熟（不要说现在就有，自动路由功能基本上是被骂的）。
Fast基本不影响token消耗
Fast提速1.5倍，消耗额度2.5倍。
控制 effort、时间、请求数与上下文后，总 Token 的 Fast/Standard 比为 1.002（90% CI 0.940–1.067）
子代理：收益不明，消耗很大
Sol Ultra可以开子代理去做任务，看起来很高级，实际上一塌糊涂。而且还不好分析收益。
至少，如果你平时不开fast，没有必要用子代理。
比较明显的，爬取信息类，容易重复工作。
Plan模式数据相对好分析一点，都是Ultra，任务难度其实差不多：
| Plan指标 | 无子代理 | 有子代理 | 倍数 |
|---|---|---|---|
| 完成样本 | 52 | 6 | — |
| 平均活跃时间 | 6分49秒 | 20分08秒 | 2.95× |
| 中位活跃时间 | 4分36秒 | 15分03秒 | 3.27× |
| P90 活跃时间 | 16分24秒 | 35分41秒 | 2.18× |
| 平均 Token | 1.78M | 26.06M | 14.64× |
| 中位 Token | 0.467M | 9.20M | 19.72× |
| P90 Token | 5.13M | 16.52M | 3.22× |
| 最大 Token | 9.82M | 105.18M | — |
可惜，5.6 Sol不太需要Plan，有子代理的样本数更少。是个问题。
不管怎么说，我应该不会再主动让子代理出现在Plan。
总之，Ultra子代理很不成熟，尤其刚出的时候，一个简单问题，都能叫上十几个兄弟去干。
类比来说，小强一个人一拳就能把目标打碎；小明Ultra把全家十几位叫上，一起打，时间增加不说，消耗大了十几倍。
印象中还有，Ultra开一个子代理，然后自己在那等……
最后，虽然官方说，Max跟Ultra思考强度一致，但个人体验来说，Ultra比Max更好用一些，犯傻概率更低。只好捏着鼻子用Ultra，然后在Agent.md加一条“不要用子代理”（Plan模式下可能失效），或者每次提问开头说“本会话不要用子代理”。
最后放个Ultra 弱智时刻：
用Git Worktree？
如果直接在同一目录同时改几个需求，那么GPT模型常常会触发「最小增量修改」小连招
我会先逐个看这些文件的现有差异，在其上做最小增量，避免覆盖你正在进行的修改。
有人会说用Git Worktree。这个靠复制目录来并行使用不同分支的方案。
但这肯定不是最佳方案，抛开十几个Git Worktree依赖占据的空间不谈（Rust项目可能得谈），合并版本也有额外工作量，而且明明都在本地文件改动，这样把问题转成异地一样，完全阻隔改动间的交流，肯定有信息没有充分利用。
这种问题，恐怕只有下一代版本控制系统才能解决。
目前主要看场景跟偏好，Git Worktree相对可控，对大型项目更好。
结构化积累
通过实例来讲解“结构化积累”怎么节省token的。
在开源桌面端应用AIY，开发过程中，我模拟了一位开发者，本地没有存任何现成脚手架、方案，只用公开方案，用Codex开发一个桌面端应用。
一个「开发循环」
就算没有任何积累，可以直接套用：
- 表述
- 小试
- 确认
- 开发
- 验收
如果你懂表述跟验收，加上足够时间与额度，很多问题你都能通过大模型解决。
表述、需求与价值
大模型对表述的要求，会越来越低。比如以前一些人在推的Prompt工程，现在只剩下少数人在干；而现在GPT 5.6能处理比较模糊的表述，反观公认的编程最佳模型，Claude Fable 5在这方面却不太行。
结合同样套餐下，ChatGPT+Codex用量更多、试错空间更大，我个人更推荐新手用Codex，而不是Claude Code。
言归正传，表述不需要多“会表达”，它跟需求质量强相关。
甚至一开始不用表述得很好、需求不用一开始就想好，可以“迭代”完善。比如，通过下一节「小试跟确认」。
在开发之前，至少需要什么呢？
-
明确需求价值；
- 一个很简单的检验方式：是否能几句话说清楚；
- 先确定需求是否必要做，是否已经完善，是否要现在做。需求无价值、变更、延期，会带来很多问题，远不止token消耗。维护工作也相当磨人。
- 形成概念设计，标志是产出一份术语表，以及概念关系的初步模型；
- 有基本的界面、交互设计；
- 明确技术选型。
需求相关话题超过了本文范围，不便展开。但这几点应该算一个起点。
做需求不需要「完美出发」，可以做中练；辅助完善需求的循环。
小试与确认
为什么要先让模型小规模试验？
GPT5.6有个特点，在常见领域，能快速理解用户的模糊需求，并且立马加油干。
但如果是不常见的领域，比较特别的需求，这将会快速跑偏。甚至有时你让它先设计，它也会自作主张帮你实现完，只好说：
“谁让你改了？先设计方案……”
怎么试试呢？
- 大模型反问
- 搜索、调研
- UML图表
- 线框图
- GPT Image 2
大模型反问：计划模式（Plan）
Codex分析比较模糊的部分，然后列出问题来问用户。最后形成后续执行报告，让你去确认。
整体思路不错，但至少对于GPT5.6 Sol，我觉得有点呆：
- 必须有一份报告，必须确认报告，让它稍微改一点然后执行，还是会返回报告；
- 反问有时很慢，且不知道要多少批反问才结束，一批一般3个问题，目前最多4个；
- 还会顶掉一些AGENTS.md的提示词（比如Ultra不要用子代理）。
可能比较快的方式，「逐一列出需求跟我确认，单独列出有争议、模糊的需求。」
话题、调研
这块话题比较庞大，技术的单独放下一节「调研技术选型」。
图表、UML
UML一开始是想着完成需求直接到程序的转变。显然这是妄念，但确实有一些图表相当优秀。
我最常用的是，类图、活动图、时序图跟状态图。
如果你要深入参与数据库、程序设计，可以用对象关系图等……
线框图
原教旨主义的线框图是这样的：
用文本写一段文本构成的线框图。示例（公众号直接放会错版，只好放截图）
Codex默认出的线框图是这样的，是个简化版HTML：
GPT Image 2
Codex用的GPT Image 2，低质量模式，只算出图，一张API价约四美分。如果你想用一张约一美元的高质量，可以参考前述——用ChatGPT。下图是低质量：
如果Codex画得不行，它生成提示词，指出相应资产，转到ChatGPT。我现在试着在自己做的软件AIY，实现Codex到ChatGPT的流程。目前本地实现是Codex调用AIY命令行工具，创建贴图，然后触发“给浏览器”，通过AIY浏览器插件，打开浏览器，填好ChatGPT网页。当然，为了遵守ChatGPT的规则，最后发送键还是用户自己点。
确认
按你的理解判断就行。发现AI理解错了，立马让它输出必要上下文，纠正后，开启一个新会话，而不是在一个会话反复纠错。另外，5.6 Sol虽然已经能实现部分模糊要求，但在比较复杂、特殊的项目，还是没有办法。
调研技术选型
虽然现在大模型很厉害了，但技术选型偏好特别明显、局限。搜索可以略做弥补，也有很大加成，尤其是在风评跟相对冷门的领域。
搜索框架、脚手架
调研现有成熟框架，比如跨端桌面软件，一通对比下，排除了GPUI、Tauri，力挺Electron。
我故意说，想用GPUI试试，它列了理由1、2、3、4说不适合。
那行吧，调研现有脚手架，找到GitHub上Electron-vite-react，不过还是比较简陋。后续我简单指导，让它补充：
- formatter；
- shadcn，作为UI基建（你赶潮流的话，可以考虑StyleX）；
- 维护策略与文件组织。起码有最基本的组件化，避免一个文件就上千行代码；
- 中英双语（或者说国际化、i18n）。
中英双语一开始弄出来titleZh、titleEn这种字段，感觉偷懒刻入GPT的底层代码了。
实践下来，有些事情，只有靠迭代才能做到。
积累需要迭代才能产生的东西。这不是收藏、或随意让大模型帮忙DIY就能做到的。
如果你有相关技术积累，不仅能节省调研的额度、还能节省踩坑的时间、节省反复迭代的精力。
搜索适用算法
AIY的大纲线动态绘制，一开始GPT 5.6 Sol做不到，找了一些论文才写出来，而且只是补充了计算思路而已。这是比较“奇葩”的需求，应该没有类似的公开实现。
第二个例子：字幕翻译与对齐。有一网友，做AI视频剪辑软件，想优化字幕翻译加自动放置的过程，结果Fable 5解决起来也比较困难，但其实网上是有论文的：
小结
最后，那些想着“随便Vibe”就替代别人的，有彻彻底底的妄念。
验收与测试
总体原则
GPT 5.6 Sol设计测试的能力很差。如果毫无指引，写的根本不叫测试，最多叫复读代码实现。类比写代码水平，最多GPT 4的水平。下图是一个典型例子。
真要让它写，每个需求，一开始最多考虑一条端到端「冒烟测试」，跟少量单元或组件测试，让大模型能自己给自己反馈，至少做出来的东西不“冒烟”——能成功跑起来。
检查测试代码。测试不应当是开发思路的二次实现，而是从「用户角度」正交地去验证。注意这个「用户」不一定是产品用户。对组件，是用组件的开发者；对API，是API调用方。等相关需求完善、稳定了，再慢慢补相关“自动”测试，不然很容易遇到需求变更，然后不仅要改代码，还要改测试。
测试覆盖率可以做个参考，GPT 5.6 Sol写一堆测试，覆盖率20%。不过也为了提高这个指标，强行堆测试数量。
考虑到有人想着AI干活，自己同时用电脑摸鱼。可以考虑让AI：
e2e默认静默，不要弹出界面干扰电脑使用。但有选项可以让用户一起观察。省钱的测试
- 用挡板或mock模拟外部付费API，先跑通内部流程；
- 有时大模型喜欢看测试代码作弊，浪费额度不说，还要花精力把它们纠出来，然后重做。
第二点可以考虑用“明/暗测试”：在开发阶段，就用轻量的、模型可见的测试集。每积累一些改进后，就跑模型不可见的、更全面的测试，只反馈问题，不告诉模型怎么测的。
如果暗测试反复出错，说明程序编写已经超出模型能力之外，或者需求出了问题。
操作上，如前文「几时新建会话」所述，建议开新会话迭代需求，比如：建议模型搜索相关问题跟解决方案，并用相关UML分析。
测试的极限与权衡
最后，要明白测试的极限与权衡。
- 不存在“全自动化”。不存在一种通用方法，能把任意程序全自动实现后，再全自动校验。根据停机问题，甚至不存在一个通用算法，能对任意程序和输入都提前判断它最终是否会崩溃、会在哪里崩溃。
- 至于真实的权衡。开发中的测试。要考虑性价比，不能说改一点，就要跑两分钟的测试。
- 还有生产缺陷。漏出缺陷的代价，要比修复的成本大得多。
这跟行业有关。比方说，互联网软件，漏出缺陷代价一般较小、能在线修复，准出门槛会轻很多，尤其是前端；但对汽车来说，漏出缺陷可能导致伤亡。后者就要有比前者更严密的测试、更严厉的准出条件。
也跟受众有关。比如公众号后台英文界面，以前更糟，印象里，左侧边栏的文字直接溢出：
版本说明
这篇文章很早就有草稿，想着实验完善一些再发，结果中途「透支额度法」惨遭削弱。也因此，想着先发一个版本出来吧。这个版本也足够有价值。
后续变更，在“阅读原文”处更新，且阅读体验更佳。