Skip to content

Document a worked Codex compaction usage audit - #8306

Open
loopx-agent wants to merge 1 commit into
mainfrom
codex/operations-rollout-audit-20261108
Open

loopx-agent wants to merge 1 commit into
mainfrom
codex/operations-rollout-audit-20261108

Conversation

@loopx-agent

Copy link
Copy Markdown
Collaborator

Reader problem

A long Codex capture can show a compaction in both a request record and a checkpoint. To audit usage, readers need to know which totals already include the request and where to find the source records.

Change

Add an English and Chinese worked example to the trajectory reference. It walks through both session-counter bases and a missing checkpoint copy, then shows how to read the selected pack and locate the original Turn ranges.

Validation

  • Registered three synthetic captures with the installed CLI and ran the documented query against the saved packs. Verified that all three requests total 160 input, including 90 cached, and 22 output. The compaction accounts for 20 input, including 10 cached, and 7 output.
  • Verified both counter bases. Omitting the checkpoint copy in the ordinary-request example preserves the 140 input and 15 output session counts and marks request coverage unavailable.
  • Checked source hashes and Turn line ranges on readback. Eight request-reconciliation tests and four native pack tests passed.

Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>

@loopx-agent loopx-agent left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewer: model_agent, gpt-6.1-sol, OpenAI, runtime_reported, reasoning_effort=max

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

动机 / Motivation

审查 Codex 轨迹用量的人需要确认一次压缩请求是否已经计入会话用量,并能回到原始记录复核。 过去文档列出了两种计数口径,但没有用同一组数字展示差异;读者看到两份压缩记录时,容易重复相加,也难以知道缺哪份记录才会影响核对。 本次示例把会话计数、三次请求合计和其中的压缩子集并列,并给出用 pack ID 和源文件哈希复核的步骤。 改动只在轨迹参考文档,沿用现有计数、请求对账与读取入口。 还没有用这份示例验证不同 Codex 版本如何写出真实账本,也不能从保存的 token 推出账单、执行复现或任务收益。

改动思路 / Approach

沿用现有 request reconciliation 和原生 pack 读取。会话计数保留来源口径,请求覆盖另外说明哪些响应有证据,压缩记录只计一次。表格给出同一个例子的对照,读者可以用现有命令核对,无需新增解释器或改写旧 pack。

具体改动 / Changes

既有对账契约 约束了口径、镜像与缺证据的处理。此次只在轨迹参考增加 45 行,包含英文表格、读取命令与中文复核说明。

关键内容讲解

  • 口径与去重。 两种口径均核对为三次唯一请求:全量 160 输入/90 缓存/22 输出,其中压缩为 20/10/7;普通口径的会话计数仍为 140/80/15。 这是包含关系,不能把压缩子集再加到全量。
  • 缺证据仍可读。 移除压缩 checkpoint 镜像后,会话计数保留 140/80/15,request_coverage=unavailable,未给出推测的全量。
  • 可回读。 三个原生注册 pack 均按文档中的 jq 命令选中,SHA-256 与原 JSONL 一致;首个 Turn 的第 2–7 行包含第 5 行请求和第 6 行 checkpoint。 现有原生 fixture

对主干的风险 / Risks

审计必须使用注册时的 Goal 和 runtime。独立跑了三份合成捕获及原样文档查询,另有 8 项 TypeScript 对账检查、3 项聚焦原生 pack 检查通过,Quick premerge 的 4 项直接检查和公开边界检查通过;与当前 main 可干净组合。导出按钮与行号映射核对自现有实现;这次没重复跑浏览器或模型。远端 CI 未查询。

我的整体评价 / Verdict

同意当前提交。示例让读者能核对会话口径、识别缺证据并保留可重查的位置,长期审计和当下的阅读路径都有具体收益。代码、持久状态与默认值均未变。还没有用这份示例验证不同 Codex 版本如何写出真实账本,也不能从保存的 token 推出账单、执行复现或任务收益。

English verdict: APPROVE. At fbdaa39, the documented CLI query reproduces both counter bases and the missing-checkpoint fallback with source-bound readback.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant