实测 Codex 请求：16 字提示为何膨胀为近万 token

OpenAI 的 Codex CLI 在用户输入一段极短提示时，实际发往模型的请求体积远超输入本身。研究者搭建了一个本地 HTTP 代理，把 Codex 的每一次请求原样落盘，再用 o200k_base 编码器估算文本 token，直观展示了请求内部各模块的体量与加载机制。测试使用 Codex CLI 0.145.0 与 gpt-5.6-sol 模型。

实验方法

研究者利用 Codex 支持自定义模型提供方的能力，把客户端指向一个本地 recorder 服务。该服务保存请求正文、对敏感头进行脱敏，并返回一个固定假响应，全程不调用任何外部模型。

测量两个维度：

原始请求字节数：HTTP JSON 正文脱敏前的实际大小；
近似文本 token 数：用 o200k_base 对脱敏后的 JSON 进行本地编码得到。

需要注意的是，token 数仅为本地估算，并非 API 用量或计费口径；请求正文本身是精确值。

基础请求的 token 构成

在一段空仓库、禁用项目指令、CODEX_HOME 指向空目录的隔离环境下，输入 16 个字符的 Reply with pong.，最终请求体积达到 42,980 字节，约 9,435 个 token。其中用户原文仅占约 25 个 token，占比 0.3%。

三项内容占据了主要开销：

additional_tools：包含 exec、wait、request_user_input 及一个含 6 个子工具的 collaboration 命名空间，16,741 字符，约 3,942 token；
Developer message：Codex 主指令，17,730 字符，约 3,729 token；
User message：用户原文，16 字符，25 token。

由于启用了 5 个内置系统技能，这次测量是「隔离 home 基线」，而非理论最小请求。

项目指令的传播规则

Codex 会从仓库根目录向启动目录逐层查找 AGENTS.md，层级越深的文件越靠后追加。实测中：

在仓库根目录启动，仅加载 100 个根目录 marker；
在子目录启动，200 个 marker 全部加载；
在根目录启动后再 ls child，并不会自动追加子目录指令。

指令在请求中是完整传输的，不是节选或摘要。使用高熵合成 marker 时，250 个 marker 让首请求从 9,435 token 涨到 11,965 token；1,000 个 marker 则使首请求达到 20,465 token。在两次请求的 trace 中，250 个 marker 都完整出现在两轮请求里。

Skills 与 MCP 工具的延迟加载

仓库内 .agents/skills/ 下的技能在首请求中仅贡献名称、描述与路径，SKILL.md 正文不会自动加载。每个含 12 词描述与 200 词正文的合成技能，单个约带来 481 字节、125 token；10 个技能叠加约 4,810 字节、1,250 token，且正文 marker 不会出现在首请求中。

MCP 工具描述同样被延迟：配置 1 个本地 MCP 服务（3 个工具）+ 2 个本地服务（共 7 个工具）时，初始请求仅 46,582 字节、约 10,410 token，且不包含自定义工具名或描述，只在 exec 提示里加入通用 MCP 发现指引。直到通过 exec 触发相应工具，描述才会进入历史：

单服务、3 个工具（各 40 marker）：新增 120 个 marker，约 5,894 字节、1,522 token；
双服务、7 个工具（3×40 + 4×60）：新增 360 个 marker，约 15,970 字节、4,210 token；
服务被白名单限定为单工具时，仅引入 1,522 token 级别开销的子集。

当单个工具描述膨胀到 5,000 个 marker 时，Codex 会对描述做截断，保留首尾样本（约 1,046 marker），后续请求增加约 40,607 字节、9,631 token。

对使用与优化的启示

实测表明，Codex 首请求的体积主要由系统指令、工具定义和技能元数据构成，用户输入占比通常可以忽略。当仓库内 AGENTS.md、Skill 或 MCP 工具描述持续膨胀时，请求成本会线性增长；而 skills 与 MCP 描述的延迟加载机制，则能在一定程度上控制首请求体积。

对于希望控制 token 开销的开发者，实测给出的建议是：精简 AGENTS.md 内容、控制 MCP 工具描述长度、合理拆分 skills，而非假设「短提示就一定便宜」。