用途
Codex 会记录每次模型调用的输入上下文、缓存拆分、输出大小以及每次压缩（compaction）事件。这些数据足以测量 Agent Task Cost 成本模型的参数，进而从模型本身推算出一个任务最少消耗的上下文窗口大小，而不是靠猜测。
本技能读取用户的本地会话历史，为三种任务规模计算最不浪费的窗口大小，与用户当前实际运行的窗口进行对比，并询问是否修改该设置。
用户看到的一切都以“相对最优窗口下任务消耗量的倍数”呈现。这在订阅制和 API 计费下读法一致，因为计量的消耗方式与价目表加权方式相同——用量和账单是同一个量。
所有内容使用 Python 标准库在本地运行。唯一离开本机的是用户可能选择打开的 URL。
回复应使用用户书写所用的语言。脚本输出为英文，但这不限制你的回复语言——把结论翻译成用户的语言，而不是把原始输出直接粘贴给他们。
工作流程
1. 运行分析
python3 <skill_dir>/scripts/advise.py --json /tmp/context-window-advice.json
可用参数：
--include-archived— 同时扫描~/.codex/archived_sessions。数据更多，扫描时间约翻倍。当~/.codex/sessions中会话较少时值得使用。--since YYYY-MM-DD— 限制为近期历史，当用户近期更换了模型或 harness 设置时有用。--limit N— 抽取 N 个会话文件，用于在大量历史中做快速检查。--quiet— 不显示进度条。
对几十 GB 的完整扫描只需数秒，不要预先限制。
请读取 JSON，而不是解析 stdout。其结构：
measured— 八个校准参数（W0, B, rho, omega, theta, Sc, oBar, dBar）evidence— 会话数、模型调用数、日期范围、观察到的窗口current— 模型、窗口，以及 config.toml 设置时的配置键值recommendations[]— 每种任务规模：optimal_W、usage_multiple、wasted_share、verdict、window_gapurls— 每种任务规模的可视化链接overall_verdict— "ok" | "advise" | "strong"suggested_config— {model_context_window, model_auto_compact_token_limit}，无需更改时为 null
若未找到任何会话，应如实说明并停止。不要编造推荐。
2. 向用户汇报
按以下顺序给出：
- 当前窗口及其来源——若两个配置键任一被设置则来自 config.toml，否则来自会话记录。
- 每种任务规模的最不浪费窗口，用平实语言说明 usage_multiple：“一个小任务当前消耗量是其 98K 下的 1.35 倍”。这句话是重点，应放在最前面。
- 最相关任务规模的可视化 URL，让用户用自己的数字看到曲线。把链接交给用户，不要代为抓取。
明确说明 β——即任务需要同时保留的既有信息量——没有校准值，因此三种任务规模使用的是示例值。φ₀ 和 Y 也无法测量，但它们只缩放账单，不会移动最优窗口，因此推荐不依赖它们。
3. 提供更改，然后询问
overall_verdict 是三种任务规模中最差的判定：
ok— 每种任务规模都在阈值内：如实说明，不做更改。advise— usage_multiple ≥ 1.5×：提及并询问是否更改。strong— usage_multiple ≥ 2.0×：优先说明，建议更改。
用倍数说话，而不是金额。usage_multiple 是同一任务在当前窗口下的消耗量倍数——“此任务当前消耗量是其所需量的 2.1 倍”。无论用户是订阅制（配额以 2.1 倍更快消耗）还是 API（账单为 2.1 倍），这一说法都成立，因为消耗计量方式与价目表加权一致，它们是同一个量，而非两个。不要换算成美元：模型的美元数字取决于 Y 和 φ₀，这些是任意值，只有比值有意义。
wasted_share 是同一事实的另一面——当前消耗中最优值本不会花费的比例。哪个读起来更清楚就用哪个。
阈值基于倍数，绝不用窗口大小。消耗在最小值附近是二阶平坦的，因此当前窗口与最优窗口之间的距离几乎说明不了什么——81K 的窗口差距可能只意味着 1.04×。window_gap 仅供参考，不得作为决策依据。
在 min_calls_for_advice 次模型调用以下，判定会被强制为 ok：测量太薄弱无法据以行动，且使用频率低到无关紧要。应说明这一点，而不是给出推荐。
有可更改之处时，在改动任何东西前先询问用户。suggested_config 使用中等任务的最优值，因为 Codex 只接受一个 model_context_window 值。若用户主要做单一规模的工作，则提供该规模的最优 W。
4. 仅征得同意后应用
Codex 需要两个顶层键，且必须一起移动：
model_context_window = 1000000 # 总上下文预算
model_auto_compact_token_limit = 900000 # 自动压缩开始的起点
第二个值是该模型的 θ·W——压缩触发的绝对 token 数——因此直接写入，无需猜测比例。只设置窗口会导致压缩仍在 harness 默认位置触发，成本预测将不再描述实际情况。
JSON 中的 suggested_config 已包含这两个值；压缩上限使用从用户自身会话测得的 θ，因此其压缩节奏会延续到新窗口。
python3 <skill_dir>/scripts/advise.py --apply <window> --compact-limit <tokens>
两个键会写在第一个 [section] 标头之上（否则 TOML 会把它们读作属于该节），文件其余部分保留，原文件复制为旁边带时间戳的 .bak- 文件。告知用户备份路径，以及需以新会话重启 Codex 后设置才生效。
省略 --compact-limit 会回退到官方示例使用的 0.9 比例并会说明；优先传入测得的值。
切勿手动编辑 config.toml——脚本会处理位置和备份。
结果解读
推荐在两种相反方向的效果之间权衡：
- 更大的窗口意味着每个请求重新读取更多上下文。输入主导账单，因此这上升很快。
- 更小的窗口意味着更多压缩，每次压缩既花费一次模型调用，又丢弃智能体随后必须重建的上下文。
最优值位于两者之间，并随任务需要常驻的信息量移动——而不是随仓库大小。大型 monorepo 中的局部修复想要小窗口；小型仓库中的跨切面重构想要大窗口。
若推荐落在搜索范围边缘，脚本会说明；真实最优值可能位于 48K–1M 之外。
独立校准报告
要获取完整测量细节——按模型的 ō、按工作区的 d̄、压缩统计，以及实际估计 β 所需的跨窗口对比——直接运行分析器：
python3 <skill_dir>/scripts/calibrate.py --include-archived
要求
Python 3.9+，仅用标准库。不使用也不需要网络访问。