GPT-6 Astra：子代理 30 秒轮询造成额度消耗的可复现遥测

一句话结论

一次 Astra 父代理编排中，47 次没有状态变化的 30 秒轮询处理了 713 万输入 token，占父代理输入量约 68%，说明短间隔轮询会把高价父模型的上下文成本放大。

适用场景

• 适合的任务：Codex 多代理编排、长时间运行的 Luna worker、额度异常消耗排查、wait_agent 间隔设计和缓存权衡。

• 不适合的任务：据此推断所有 Astra 任务的配额倍率，或把订阅用量百分比直接换算成 API 美元成本。

• 适用的模型版本：父代理 GPT-6 Astra；worker 为 GPT-5.6 Luna XHigh；对照会话为 GPT-5.6 Luna Max。

• 适用的客户端、Agent 或 API：带 rollout telemetry 和子代理协作工具的 Codex。

• 推荐的推理档位和参数：文章没有公开 Astra effort；作者建议实验约 20–25 分钟的等待间隔，以低于其假设的约 30 分钟缓存 TTL。该建议在发帖时仍在测试，不能当作已验证结论。

测试环境、输入与配置

• 同一个 Plus 账户上的 Astra 编排会话和当天较早的 Luna Max 对照会话。

• Astra 父代理等待 Luna workers，观察到 47 次连续的 30 秒 timeout poll，47/47 都没有返回新的 worker 状态。

• 两个 Luna XHigh workers 执行实际任务；第一个 worker 被父代理中断两次，第二次中断后发现已经产生 2 个文件修改、127 行新增、6 行删除，之后由替代 worker 继续。

• 对照组是连续 127 分钟、12/12 turn context 都为 Luna Max 的真实工作会话。

• 文章提供 telemetry 汇总，但没有公开完整 rollout 文件、原始任务 prompt、父代理 effort、仓库内容或账户限额算法。

原始数据

• 每次空轮询平均处理约 151.7K 输入 token。

• 7.13M / 10.46M ≈ 68%，即父代理原始输入量约 68% 来自没有新状态的 timeout polls。

• 两个 Luna XHigh workers 的输入量约为 Luna Max 对照的 2.05 倍。

• 作者用线性比例作上限式估算：8 × (19.514M / 9.538M) ≈ 16.4 个百分点。即使接受该简化，仍不能解释观察到的 +47 个百分点；但订阅额度算法未公开，所以这不是严格成本归因。

结论与适用边界

最强证据是轮询次数、每次上下文规模和父代理 token 汇总之间可以相互校验；它支持“短轮询造成大量重复上下文处理”。缓存输入占比极高，说明延长等待还要考虑缓存过期风险。评论者指出更长等待可能使上下文变成未缓存输入；作者提出 20–25 分钟只是待验证的折中。

这份数据不能证明 +47 个百分点全部由 Astra 父代理造成，因为 workers、账户限额权重、Fast/Standard 状态和服务端计量公式没有完全公开。也不能把 Luna Max 的每 token 额度变化线性外推到 Luna XHigh；文中的 16.4 只是敏感性估算。

复现步骤

1. 在同一账户和客户端版本中，固定父/子模型、effort、任务、仓库、上下文、并发数和服务模式。

2. 保存完整 rollout telemetry，逐次记录 wait_agent 的开始、超时、返回状态、输入/缓存/输出/推理 token 和父代理重入次数。

3. 做至少三组：30 秒轮询、20–25 分钟等待、事件驱动唤醒；worker 任务和运行时间保持一致。

4. 分别报告父代理与每个 worker 的 token、用量百分比、墙钟时间、完成度、中断/替换次数和缓存命中。

5. 重复多次并记录客户端版本，以区分模型行为、harness bug、缓存策略和临时服务端计量变化。