Codex trace 对每次工具调用携带两种延迟概念：

• 端到端（墙钟）——tool_wall_latency_ms，即从模型 发出函数调用到其输出被记录之间的时间戳跨度。
• 内部——tool_internal_latency_ms，即从工具输出中解析出的 runner 上报的 Wall time: … seconds，亦即命令本身运行了多久。

本实验量化正残差 gap = max(tool_wall_latency_ms − tool_internal_latency_ms, 0)：即 runner 没有归因为 执行命令的那部分端到端时间。在 归一化 trace 中，这个残差是唯一可用于审批 / 用户等待 开销的信号，因为工具输入、输出以及显式审批事件都未被保留， 因此最好将其读作围绕该调用的客户端等待的上界，而非 直接的审批测量。

只有 (provider = 'codex') 且同时具备两种计时、墙钟时间为正、且 内部时间非负的调用才进入残差统计。论文 float tab:codex_tool_e2e_internal（以 codex_tool_e2e_internal.tex / .md 形式发出） 将这些聚合为一个 All timed 行外加每个主要的类执行工具 （exec_command、write_stdin、shell_command、apply_patch）一行，报告调用数、 端到端 / 内部 / 残差小时数求和、平均残差，以及 P50/90/99 残差 秒数。该脚本还写出若干 CSV 分解（逐工具、逐类别、残差 分桶、直接人工墙钟时间、top-gap 示例）和一份 result_analysis.md 叙述。

# released DuckDB, outputs written next to this README
uv run python artifacts/tool_calls/codex_wall_internal_gap/analyze.py --db trace/syfi_coding_trace.duckdb

# default merged trace
uv run python artifacts/tool_calls/codex_wall_internal_gap/analyze.py

标准 trace_db CLI（--db | -i/--input | -o/--output-dir）。实用参数： --top-gap-examples（top-gap-examples CSV 中的行数，默认 50）。

• codex_tool_e2e_internal.tex——论文 float tab:codex_tool_e2e_internal： 逐工具的端到端 / 内部 / 正残差延迟，带均值和 P50/90/99。
• codex_tool_e2e_internal.md——该表的 GFM 镜像（数字相同，无标题）， 用于 web 端详情页。
• headline.json——用于 Overview 画廊卡片的几个 headline 数字。
• result_analysis.md——主要数字、覆盖率以及可解释性 局限的叙述。
• CSVs：codex_tool_timing_coverage.csv、codex_wall_internal_gap_by_tool.csv、 codex_wall_internal_gap_by_category.csv、codex_wall_internal_gap_buckets.csv、 codex_direct_human_wall_time.csv、codex_top_wall_internal_gap_examples.csv。

• 在253k次同时具备两种计时的 Codex 调用中，端到端时间为418.1h vs 341.5h 内部——一个77.8h的残差差距（约 19% 的端到端时间位于命令执行之外）。
• exec_command 承担了其中大部分：184k次调用、64.1h残差（其内部 时间在 97.8h 端到端中仅占 33.8h）。
• 残差通常极小但重尾：在所有计时调用上，中位数0.13s、P90 0.24s、P99 10.0s。