title: "Codex 五小时额度 7 分钟耗尽：一个 53 万 Token 旧会话留下的上下文管理课" slug: codex-530k-token-old-session-context-lesson date: 2026-09-22 category: 智能体与 Harness tags: Codex,上下文管理,Token,额度,/compact,AGENTS.md,MCP summary: 一位 Plus 用户只用 Codex 干了两件几分钟的小事，五小时额度却宣告耗尽——排查发现旧会话每步带入约 53 万 Token 输入上下文。OpenAI 官方文档确认长会话会推高每条消息的消耗。这不是 bug，是所有 AI 工作流都要面对的成本结构：上下文不是免费的。

Codex 五小时额度 7 分钟耗尽：一个 53 万 Token 旧会话留下的上下文管理课

这是每个重度使用编码 Agent 的人都可能撞上的场景：一位 Codex Plus 用户只让 Agent 干了两件事——审查一段新代码（3 分 52 秒）、推送到 GitHub（3 分 35 秒）——然后发现五小时的额度已经在 7 分钟里用完了。

谜底在 Reddit 帖子的后续补充里：这位用户一直沿用一个很久以前开建的旧会话，每一步操作都带着约 53 万 Token 的输入上下文。哪怕新指令只是「把一个页面元素居中」，前面累积的全部内容也会跟着进任务。9 月 22 日，另一位付费用户也报告了类似的额度消耗加速——他用 Agent 做任务协调，感觉新一轮额度比上次掉得快得多。

一、为什么「只问了两句」会烧掉五小时额度

OpenAI 的用量说明把这件事讲得很直白：长会话需要 Agent 保留更多上下文，每条消息的额度消耗随之上涨。你发出去的是一句短指令，但模型处理任务时携带的是整个会话的相关内容、文件和工具结果。官方列出的计费影响因素包括：模型选择、上下文长度、推理深度、工具调用、检索和缓存。

换句话说：按请求字数或「只花了几分钟」来估算消耗，从根上就是错的。额度烧在哪，要看任务记录里的实际输入规模，而不是你的主观感受。53 万 Token 的常驻上下文意味着每一次轻量交互，都在为一个臃肿的历史买单。

二、官方给出的减负清单

OpenAI 建议中的几条，值得直接抄进日常工作流：

1. 只提供相关文件，收窄来源或日期范围——别把整个项目史喂给一个单模块修复；
2. 把必须完成的工作与可选改进分开，说明需要的输出长度；
3. 用 /compact 压缩旧会话：把较早对话整理成摘要、释放上下文空间，适合任务还在继续、前面的决定仍有用的场景；
4. 分清 /new、/resume、/fork：新任务开新聊天并只给必要文件，别惯性沿用旧会话；
5. 给 AGENTS 文件瘦身，按目录组织项目说明——常驻输入每次都会重新计费；
6. 关闭用不到的 MCP 服务器——每个服务器的工具说明和 schema 都会增加每条消息的上下文。

个人和 Business 用户可以在桌面端 Settings 的 Usage & billing 里把额度分析拆到任务、子代理和单条聊天级别。

三、这不是 bug，是 AI 工作流的成本结构

这件事最值得写进团队规范的一点是：上下文是一种需要主动管理的成本，而不是无限免费的背景。很多团队已经在这样做了——Spotify 用上下文工程把 Claude Code 的 Token 用量砍掉 90%，本质就是同一道题的工程化解法。

Agent 时代的新带宽账单有两个隐蔽特点：一是滞后性——消耗发生在每一次你以为很轻的操作里，账单月底才疼；二是复利性——旧会话越长，后续每一步越贵，形成正反馈的吞噬循环。给团队的落地建议只有一条：给每个任务一个干净的会话起点，把「续着用」变成显式决策而不是默认行为。

结语

53 万 Token 的旧会话不是一个个人用户的操作失误，而是所有 AI 工作流都会遇到的成本暗礁。当 Agent 越来越能干、单任务越跑越长，「上下文卫生」会从个人习惯升级为团队的基础设施问题——谁能把上下文管得又瘦又准，谁就在同样的额度里多干十倍的活。