我如何避免 Codex 用量额度被快速烧光

我最近跑了两个 Codex 浏览器自动化任务，分别消耗了 170,123 和 110,180 个 token。

任务本身没问题：发布了文章、打开了网站、填好了编辑器，还检查了最终页面。但成本让我吃了一惊。这又不是做了几个月的软件项目，只是两个长时间的浏览器会话，中间访问了几个网站，有重试、有页面读取、有验证步骤。

从那时起，我就不再把 Codex 的使用上限当成一个只由 ChatGPT 套餐决定的神秘数字了。

套餐当然有影响，但模型、推理级别、速度模式、对话长度、工具输出、Agent 数量，以及我交给 Codex 的任务规模，同样有影响。OpenAI 说这些都会影响消耗。[2]

读完 OpenAI 当前的文档，又对照了 Codex 用户的反馈之后，我改了自己的配置，也改了分配任务的方式。这篇文章写的就是这套配置——如果你想让 Codex 撑过真正的一整个工作周，我会把它直接给你。

它不会让用量变成无限，不会重置配额，也不会凭空给你算力。它只是不再把昂贵的模型浪费在更便宜的模型、更短的会话，或者一条普通 shell 命令就能搞定的事情上。

先搞清楚你撞的是哪个限制

大家说“Codex 限制”的时候，往往指的是三种不同的东西。

第一种是 ChatGPT 套餐额度。如果你用 ChatGPT 账号登录 Codex，Codex 消耗的就是这个套餐附带的额度。Codex 和其他 ChatGPT 工作类产品可能共用同一个额度池。[2][3]

第二种是单次对话的上下文窗口。一段长对话会不断累积提示、源文件、命令结果、截图、测试日志和之前的回答。Codex 可以压缩这些历史，但在真正撞到上下文硬边界之前，对话照样可能变得又贵又散。[6][7]

第三种是 API 计费或 API 速率限制。如果你用 API key 而不是 ChatGPT 订阅来认证，用量就按 API 定价单独计费。订阅额度用完之后，切到 API key 能让工作继续跑，但计算量并不会减少，只是把成本挪到了另一张账单上。[3]

本文关注的是：怎么通过合理的配置和更好的任务设计，把 ChatGPT 的 Codex 额度省着用。

省额度，最大头在模型选择

OpenAI 当前的定价页面就能看出模型路由为什么这么关键。对 Plus 和 Standard Business 套餐，它估算的五小时内本地消息数大致是：GPT-6 Astra 约 5-45 条，GPT-6.1 Sol 约 15-160 条，GPT-6 Luna 约 350-3,000 条。这些只是估算，不是保证的消息上限，而且复杂任务的实际消耗可能远超一个小请求。[1]

这个差距改变了我对 Codex 的看法。

重命名变量、改配置文件、提取数据、写个小测试、汇总日志、改一处 CSS，这些我根本用不着最强的模型。GPT-6 Luna 就是为专注、可重复、高频的任务设计的；GPT-6.1 Sol 是处理较大编码任务的日常主力；Astra 留给真正需要前沿级推理的工作。[5]

如果什么都用 Astra，那还没判断出任务难不难，稀缺的额度就已经花掉了。

我的新规则很简单：

常规任务从 Luna 开始。
普通实现、调试和多文件改动用 GPT-6.1 Sol。
只把困难的那一段升级到更高推理级别或更强的模型，而不是整个项目。
难题解决之后，再切回更省钱的配置。

换模型不代表这个项目不重要，只是让工具和工作匹配而已。

快速模式：花钱买方便

快速模式看起来没什么代价，因为它改的是等待时间，不是你能看到的质量设置，多花的额度很容易被忽略。

OpenAI 目前说明，快速模式消耗包含额度时按标准费率的 2.5 倍计算，消耗购买的积分时按标准费率的两倍计算。[1][4] 如果我想省着用每周额度，那在长时间自主运行的任务里一直开着快速模式就没什么道理。

在交互式 CLI 里，/fast 是个开关：运行一次开启快速模式，再运行一次关闭。对于在意用量的配置，我更愿意在配置文件里明确写死标准速度，省得还要记当前开关是什么状态。[4][6]

快速模式也不是完全没用。我坐在终端前等一个简短又紧急的答案时，可能会用它。但浏览器任务可能跑二十分钟、翻很多页面、失败操作还要重试，这种我默认不会开快速模式。

我的经济型配置

当前 Codex 版本支持配置文件，Windows 上放在 %USERPROFILE%\.codex，其他系统放在 $CODEX_HOME。用 codex --profile economy 可以选中名为 economy.config.toml 的文件。[8][10]

小改动、格式转换、摘要、简单测试和直接的浏览器操作，我推荐用这个配置：

# %USERPROFILE%\.codex\economy.config.toml

model = "gpt-6-luna"
model_reasoning_effort = "low"
model_verbosity = "low"
service_tier = "default"

[agents]
enabled = false

[features]
fast_mode = false

在 PowerShell 里运行：

codex --profile economy

然后检查当前生效的设置：

/status

/status 命令会显示当前模型、上下文用量、速率限制和会话的其他信息。[6]

这个配置做了四件有用的事：选高效模型、压低推理强度、要求输出简洁，以及防止任务悄悄膨胀成好几个并行代理。

model_verbosity = "low" 主要是控制输出风格。我用它是因为干完活通常想要一份简洁的报告。但我不会说光靠这一行就能稳定省下额度，因为 OpenAI 并没有公布固定的 token 到订阅百分比的换算公式。[2][9]

我的平衡型配置

有些任务太大或者太模糊，经济型配置扛不住。日常开发我会用 GPT-6.1 Sol，同时把贵的设置控制住。

# %USERPROFILE%\.codex\balanced.config.toml

model = "gpt-6.1-sol"
model_reasoning_effort = "low"
model_verbosity = "low"
service_tier = "default"

[agents]
enabled = true
max_concurrent_threads_per_session = 2
default_subagent_model = "gpt-6-luna"
default_subagent_reasoning_effort = "medium"

[features]
fast_mode = false

这样运行：

codex --profile balanced

这基本就是我希望 Codex 大多数时候的表现：主代理用更强的日常模型；如果它要委托搜索或代码检查，子代理从 Luna 起步，而不是自动复制一套昂贵的配置。并行线程上限设为两个。

子代理有用，但它们确实会把模型和工具的工作拆开。OpenAI 提醒，多代理工作流比同等的单代理任务消耗更多 token。[11] 社区也有人报告过意外的扇出、重复检查文件，以及代理之间互相重复对方的工作。[15][19]

我在平衡型配置里启用它们，是因为并行调查能省人的时间。我限制数量，是因为“代理开得越多越好”并不是一个免费的性能开关。

单个难任务单独升级，而不是改全局默认

任务需要更多思考时，我更愿意用一次性的命令行覆盖：

codex --profile balanced `
  --model gpt-6.1-sol `
  --config 'model_reasoning_effort="high"' `
  --config 'model_verbosity="medium"' `
  --config 'agents.max_concurrent_threads_per_session=2' `
  --config 'service_tier="default"' `
  --config 'features.fast_mode=false'

非交互式任务：

codex exec --profile balanced `
  --model gpt-6.1-sol `
  --config 'model_reasoning_effort="high"' `
  --config 'agents.max_concurrent_threads_per_session=2' `
  --config 'service_tier="default"' `
  --config 'features.fast_mode=false' `
  "Fix the failing payment reconciliation test. Change only the relevant service and tests. Run the focused test suite and report the root cause."

Codex 里命令行标志和 --config 覆盖的优先级高于配置文件和用户设置。[8][10]

提示词和这些标志一样重要。这个例子里点明了失败现象，从概念上限定了文件范围，要求做针对性的测试，并给 Codex 一个停止点。对比一下这个：

Audit the whole repository, fix anything wrong, improve the architecture,
and run all tests.

第二个提示词可能让你探索好几个小时，而“完成”的标准始终没有共识。

一个线程只做一件事

社区里最常见的建议，恰恰也是最不技术的一条：别再把一个 Codex 会话当成常驻办公室。

长线程看起来高效，因为智能体什么都记得。问题在于，它可能把旧的对话、文件内容、工具结果和指令一遍遍带进后续调用。有位用户审计了数百次 Codex 运行记录，发现反复检查和大量输出之后，活跃输入上下文在大约十一分钟内就从 16,700 tokens 涨到了 158,300 tokens。[14] 这只是单个用户的监测数据，不是官方计费公式，但这种模式很容易辨认。

我现在把每个线程当成一张工单：

调查一个问题。
写出或实现结果。
跑相关验证。
把重要状态存进仓库，或写一个简短的交接文件。
工单完成，就结束这个线程。

下一个任务如果无关，我就开新会话；如果还是同一个目标但聊天记录已经臃肿，我就用 /compact；如果想试另一条路又不想丢掉当前进展，我就 fork 会话。[6][7]

压缩没有通用规则。一些有经验的用户说，自动压缩在长期项目里效果不错；也有人说它删掉了自己还需要的信息，导致重复劳动。[18] 我在阶段边界压缩，不会在脆弱的浏览器流程或调试会话中途动手。

适合压缩的时机是调研做完、还没开始实现的时候。不适合的时机，是临时 ID、选择器、还没落盘的决策或失败测试的细节只存在于对话里的时候。

别再往模型里灌原始输出

日志会在不知不觉间变成编码会话里占比最大的部分。

一条命令打印 20,000 行，Codex 可能收到这些输出、对它推理，然后把某个版本带进后续轮次。压缩过的 JSON、整个仓库的文件列表、截图、浏览器无障碍树、完整测试套件，都是同样的道理。

我尽量在 Codex 看到结果之前先过滤：

# Instead of dumping every test result, run the focused test.
npm test -- payment-reconciliation

# Search for the error instead of opening the entire log.
Select-String -Path .\logs\app.log -Pattern "reconciliation failed" -Context 3,8

# Ask Git for the files that changed instead of rereading the repository.
git diff --name-only

具体命令因项目而异，原则不变：机器擅长过滤，模型只该拿到需要判断的那部分。

截图也一样。浏览器智能体如果反复截整页、读庞大的 DOM 树、对不确定的点击反复重试，消耗会远远超过改一小段代码。我自己那些六位数 token 的运行，都是浏览器任务偏重。现在我把这类工作拆成清晰的阶段，每到一个验证过的目标就停下，而不是让一个会话同时扛下所有网站和所有文章正文。

让 AGENTS.md 实用，而不是百科全书

持久化指令很有价值。我希望 Codex 知道怎么跑这个项目、测试在哪、哪些文件不能改，以及我怎么定义完成。

但我不希望每次会话都从一本迷你员工手册开始。

OpenAI 建议在 AGENTS.md 里减少不必要的上下文，限制源文件范围和时间跨度，收紧提示词，并关掉任务用不到的 MCP 服务器。[1] 讨论上下文工程的开发者也是同样的观点：庞大的通用指令文件，反而会把真正重要的那几条规则埋掉。[17][20]

我偏好的 AGENTS.md 包含：

真正能用的构建、测试和 lint 命令；
项目的重要目录；
一份简短、不可协商的约定清单；
给密钥、生成文件和破坏性操作划清边界；
Codex 说完成之前，该做哪些验证。

不常见的工作流我会单独放到别的文档里，任务需要时再提。

插件和 MCP 服务器也一样。每启用一个集成，就可能多出工具、说明和选项。与其让每次请求都背上整个开发环境的词汇量，不如只开当前任务需要的工具。

给 Codex 一个停止条件

自主编码的提示词应该告诉智能体什么时候停。

我现在会写清五件事：

Goal: Fix the duplicate invoice bug.
Scope: Billing service and its tests only.
Constraints: Do not change the database schema or public API.
Verification: Run the focused billing tests and show the result.
Stop: Finish after the test passes and summarize changed files.

这不是什么提示词魔法，只是减少我没让它做的探索。

没有范围，Codex 可能会把应用翻好几层。没有约束，它可能会重做本来只需小修的地方。没有验证，它会一直找所谓的信心。没有停止条件，能力强的智能体总能给自己找出更多“有用”的后续工作。

最好的提示词不一定长，但一定把结果说得很具体。

在用量变成意外之前盯住它

以前我都是等 Codex 把我拦住才去看用量。现在我会在大型任务开始时查一次，在开销大的阶段结束后再查一次。

在 CLI 里：

/status

当前的 Codex 版本还可能根据客户端和灰度情况，提供每日或每周用量等账户用量视图。ChatGPT 的用量仪表板仍然是账户级别的事实来源。[2][6]

我还会查看已安装的版本：

codex --version
codex update

我在 2026 年 10 月 5 日写这篇文章时，独立的 Windows CLI 报告版本是 0.156.1，而 OpenAI 的更新日志显示最新版本是 0.160.0。OpenAI 的文档还提到，GPT-6 Astra 需要 Codex CLI 0.153.0 或更高版本。[3][12][13]

版本差异很关键，因为配置语法、模型可用性、斜杠命令和代理设置都会变。如果某个有效的配置键看起来没起作用，我会先检查版本，而不是直接认定账户不支持。

我不会从随便一篇帖子里照搬的设置

一些社区指南建议手动调小模型的上下文窗口，或者改自动压缩阈值。

Codex 确实有用于模型元数据和压缩行为的配置项，但我都保持不设置。手动填 model_context_window 并不会扩大模型真实的上下文。填错反而会让 Codex 在不该计入上下文或压缩的时候动手。过于激进的 model_auto_compact_token_limit 要么保留太多历史，要么压缩太频繁，导致代理反复重新发现细节。[9]

在基础配置里，我也不会碰那些实验性的上下文管理和发布预算标志。实验性控制项拿来测试可能有用，但作为要撑过好几个 Codex 版本的建议基础并不靠谱。

我的目标是控制稳定的输入：模型、推理、速度、代理、任务规模、上下文和输出。

额度已经用完时怎么办

没有任何配置项能合法地重置 ChatGPT 额度。

OpenAI 表示客服不会手动重置 Codex 限额。[2] 能选的只有等对应窗口重置、账户符合条件时购买积分、换到容量更大的套餐，或者改用单独计费的 API 访问。[1][3]

我不觉得 API 回退算省钱手段，它更像是保连续性的手段。活继续干，只是成本从订阅额度转到了按量计费的 API 账单上。

升级套餐能加容量，但解决不了工作流本身的问题：启动太多智能体、日志巨大、默认开 Fast 模式，或者每个小任务都丢给最贵的模型。

我现在的工作流

我现在的做法很无聊，可能正因如此才管用。

开始之前：

日常任务我选 economy，正常开发选 balanced。
我先跑一遍 /status，确认模型、推理级别、速度档位和剩余用量。
给 Codex 一个明确的结果、合理的范围、验证方式和停止条件。

任务进行中：

日志和搜索结果先过滤，再喂回模型。
除非任务确实需要更多子智能体，否则最多开两个线程。
只在真正困难的阶段才上调推理级别。
如果目标没变，完成一个阶段后就做一次压缩。

任务结束后：

把需要长期保留的决策写进代码、测试、文档，或者一份简短的交接文件。
下一个不相关的任务，开新线程。
浏览器、调研或多智能体任务跑得特别久之后，再检查一次 /status。

这些步骤都不起眼，但合在一起，就把 Codex 从一个随时在线、胃口未知的天才，变成了一套我能主动调配的工具。

我的结论

我不觉得避免 Codex 用量限制的最好办法，是死抠每一个 token。

更好的做法是，别再让一个昂贵的推理系统去扛它根本不需要扛的活。

重复性的活交给 Luna。除非等待时间真的重要，否则别开 Fast 模式。正常开发交给 Sol。遇到困难阶段再上调推理级别，过了就调回来。智能体数量要有上限。一个线程只干一件事。工具输出太大就先过滤。指令写短一点。跑长任务之前先看一眼 /status，别被用量吓一跳。

Codex 还是会有上限，这是用共享的昂贵服务必然要面对的。但看到两个浏览器任务消耗了多少之后，我宁愿把额度花在判断、调试和实现上，而不是花在旧的聊天记录、重复搜索和更快的加载动画上。

参考文献

原文首发于 https://blog.jenuel.dev/blog/how-i-stopped-burning-through-my-codex-usage-limit