Astra 很强，也真的贵：我从 Codex 会话文件里找到了 3 类可选上下文

最近用 CodeX GPT-6 Astra 写代码时我越来越明显地感觉到一件事模型能力很强但额度掉得也快。这并不只是我的错觉。有人在 Reddit 记录了两项简单任务在1015 分钟内耗尽 5 小时额度Codex 仓库也有用户报告两条 prompt、约 26 分钟就消耗了约 86%对应会话累计约 796 万 Token其中绝大多数是缓存输入。还有 Desktop 用户在几个普通的本地 MATLAB 编辑问题后耗尽了额度。Reddit 讨论、Codex issue #45073、Codex issue #32607、Codex issue #30404这里先澄清一个容易误解的词“5 小时额度”是一个使用窗口现在几乎所有厂商的token plan都设置了这个窗口。 OpenAI 的说明明确写着用户可能在 5 小时真正过去之前就耗尽该窗口同一项任务的消耗还会随模型、输入输出长度、推理强度、Fast 模式和任务步骤数变化。Plus 用户使用 Astra 时官方给出的只是每个 5 小时窗口约 545 条本地消息的估计范围并非固定消息数。OpenAIManaging usage with GPT-6 Astra。但实际上很少有人能在这个窗口内发满45条消息。所以我一直在思考一个问题在不影响我日常本地设计和编码的前提下Codex 每次请求里有没有一部分确定存在、又可以选择不带的重复输入我试过几条路最后选择直接读会话文件最开始想到的办法都很自然降低 reasoning effort、简单任务换便宜模型、把大任务拆小。这些做法有效OpenAI 也建议按任务选择模型和推理强度但它们没有回答“同一个模型为什么每轮要带这么多固定上下文”。我又看了几个更具体的方向精简AGENTS.md。它确实占上下文但里面是项目的测试、安全和代码规范删掉之后省下来的 Token 很可能会用返工补回去。按项目关闭某个 skill。实际测试发现项目层[[skills.config]] ... enabledfalse在当时的 Desktop 链路里并不能可靠地让对应条目从技能目录消失。单独关闭推荐插件列表。Core 独立进程能响应相关 feature gate但真正新建 Desktop task 后推荐列表仍然存在说明还有 Host/Session 层覆盖。只扫描磁盘上的 skills、plugins 和配置文件。这样只能知道“装了什么”不能证明“模型这一轮实际看到了什么”。转折点是 Codex 的 rollout JSONL。一个完整的新 task 会把初始输入按内容种类记录下来response_item告诉我实际发送了哪些文本content_item_kinds告诉我每段文本属于哪个 blockworld_state记录后续上下文状态token_usage_record记录每次模型响应的输入、缓存输入、输出和模型compaction、fork 和 paginated history 也会留下边界提醒我什么时候不能继续外推。Codex 的会话前缀到底装了什么基于codex-cli 0.154.0-alpha.6.2验证。“前缀”不是一整段无法区分的 system prompt。以我 2026-09-13 的一个完整 task 为例Codex 把初始上下文拆成了 10 个有 metadata 的内容块。下表的 Token 使用项目当前的o200k_basetokenizer 对原文估算不是服务端精确计数内容和长度也会随 Desktop 版本、配置和 task 类型变化。JSONL metadata kind作用该样本估算 Token我的处理generic.developer_instructionsDesktop 通用行为、文件与界面约定1,423保留memories.instructions本地记忆的使用说明和已注入记忆3,882纯本地编码时关闭host_skills.instructions可用 skill 的名称、描述与路径目录1,805纯本地编码时关闭permissions.instructions沙箱、审批、可写目录和命令边界1,035保留collaboration_mode.instructions当前协作模式规则250保留apps.instructionsApps/Connectors 的使用规则146按任务保留plugins.usage_instructionsPlugins 的触发和使用规则209与 Plugins 功能一起关闭plugins.recommendations尚未安装的远程推荐插件列表1,310与 Plugins 功能一起关闭agents_md.instructions当前仓库的AGENTS.md1,121保留environments.environment_contextcwd、shell、日期、时区、文件系统范围302保留同一周的其他 task 还出现过multi_agent.role_instructions和multi_agent.mode_instructions另一次验证中出现过tools.deferred_namespaces。企业或受管环境还可能有managed_developer_instructions。因此“Codex 前缀有几个 block”没有一个永久固定的答案应该以目标版本的新 task JSONL 为准。还有一个重要区别host_skills.instructions只是技能目录通常包含名称、简介和SKILL.md路径并不等于所有SKILL.md正文都已加载。真正选中某个 skill 后其完整说明会作为另一段上下文进入会话。关闭目录也不等于删除技能文件更不等于禁止模型在用户明确要求时读取它。关闭哪些留哪些严格测试之后我把这些 block 分成三组。第一组我不关也不建议只为省 Token 而关block技术状态不建议关闭的原因generic.developer_instructions没有面向普通项目的独立关闭项它定义 Desktop 的基本行为契约官方不提供关闭配置肯定是有原因的permissions.instructionsinclude_permissions_instructionsfalse已验证可隐藏沙箱和审批仍会执行但模型不知道边界后更容易发起失败操作、反复试错agents_md.instructionsproject_doc_max_bytes0已验证可去掉这里是项目事实和工程约束对仓库编码而言通常比省下的 Token 更有价值environments.environment_contextinclude_environment_contextfalse已验证可隐藏模型会失去 cwd、shell、日期、时区和文件系统范围命令与路径更容易出错collaboration_mode.instructions/ multi-agent blocks协作说明可隐藏角色块没有在本次调查中验证独立 hide-only 开关会影响模型对委派、并发和协作边界的理解需要 subagent 时应保留apps.instructionsinclude_apps_instructionsfalse已验证可隐藏使用日历、邮箱、云盘等 Connector 时模型需要知道如何调用不用 Apps 时可以关闭tools.deferred_namespacesfeatures.deferred_tool_world_statefalse已验证可隐藏不一定关闭工具本身但会削弱延迟工具发现工具密集任务不值得冒险managed_developer_instructions不是普通项目开关这是组织管理要求不应由项目为了省 Token 绕过其中 permissions、environment、collaboration 和 deferred tools 在技术上确实可以关闭但关闭后的效果我没验证过因此不推荐。第二组能关但必须接受功能损失Plugins 是最典型的例子。当前 Desktop 中没有可靠的“只隐藏推荐列表、功能照常”的开关。以下配置经过新 task 验证能同时去掉plugins.usage_instructions和plugins.recommendations# ~/.codex/config.toml用户级影响本机所有 Codex 项目的新 task [features] plugins false代价也很明确插件工具和插件提供的 skill 发现能力一起关闭已经安装的插件不会被卸载。第三组与我的编码方式匹配可以选择关闭我最终针对纯本地编码场景选择的是3 类开关、4 个 metadata block自动技能目录host_skills.instructions记忆memories.instructionsPluginsplugins.usage_instructions与plugins.recommendations。项目级配置只关当前仓库的自动技能目录# 项目/.codex/config.toml [skills] include_instructions false用户级配置停止在未来 task 注入记忆并关闭 Plugins# ~/.codex/config.toml [memories] use_memories false [features] plugins false这里有四个边界必须说清楚配置只影响新建 task不会改写旧 taskuse_memoriesfalse不删除本地记忆也不关闭所有记忆生成逻辑。这个大家按自己的实际情况来如果你本地只有1个项目目录可以不用关。如果本地的项目较多建议关闭因为占用太多token了include_instructionsfalse不删除 skills需要时仍可明确点名并读取。如果配置文件里已经有[features]、[memories]或[skills]应合并键不要重复创建 TOML table。用我本地最有代表性的一周复算我没有挑一个最好看的单次会话扫描了这个项目全部可读历史按自然周周一至周日分组先比较一周内出现过多少种真实content_item_kindsblock 种类相同时再选活跃 task 更多的一周同一 task 的重复日志按 response ID 去重只统计当前项目精确 cwd归档记录也保留在历史口径中。先分清首次请求和后续请求会话文件通常只在开头写一次完整 header但这不代表它只参与第一次计费。只要这段前缀仍在有效上下文里后面的模型响应仍会处理它区别在于它更可能落入缓存输入。因此使用两个口径来计算首次请求的文本减少量完整初始头里三个目标 block 的 Token 之和。后续请求的累计减少量对每一条响应检查当时仍可追踪的 block再累加该响应的D_i。Token 公式D_i 第 i 条响应中仍可证明存在、且计划关闭的 block Token 之和 累计输入减少 Σ D_i费用不能把所有D_i都按普通输入单价相乘因为本地日志只给出整条请求的输入I_i和缓存输入C_i不能证明某个 block 具体落在缓存的哪一段。I_i已经包含C_i两者不能再相加。我按上下界计算该 block 至少属于缓存的 Token max(0, D_i - (I_i - C_i)) 该 block 至多属于缓存的 Token min(D_i, C_i) API 等价节省_i(R) ((D_i - R) × 普通输入单价 R × 缓存输入单价) / 1,000,000这里的R分别取上述缓存归属的两端。估算只减少输入假设输出、推理、工具调用、重试和任务质量不变如果关闭 Plugins 改变了实际执行路径这个静态估算就不再等于真实 A/B 结果。截至 2026-09-21Astra API 标准价是每百万输入 Token 10 美元、缓存输入 1 美元超过 272K 输入的请求使用更高费率。本周样本的 Astra 输入最大为 235,419且缓存写入均为 0所以这里都使用基础费率。GPT-6 Astra API 模型与价格周收益只报证据覆盖到的部分348 条 Astra 响应中有 211 条至少能持续追踪三类目标中的一类目标有上下文与用量证据的 Astra 响应累计估算输入 Token自动技能目录211364,938记忆41159,534Plugins 说明与推荐4454,361可证覆盖部分合计—578,833各行响应数会重叠合计行是逐响应合并目标后再求和。只有 41 条响应能同时追踪三类上下文它们合计 286,420 Token其余响应要么只能证明其中一部分仍存在要么在压缩/分页后无法重建。578,833 是已覆盖响应的累计估算不是把未知响应当 0 后宣称的“全周完整收益”。按每条请求的真实缓存边界折算这部分相当于约0.753.80 美元的 Astra API 等价输入成本。它不是 Codex 订阅账单也不能换算成“多用多少分钟”或“多发多少条消息”。一个干净样本第一次贵在哪里后面又怎么算这一周有一个新建的纯 Astra task完整保留了三类 block且 37 条模型响应都能追踪阶段响应数目标上下文累计 TokenAPI 等价输入成本第一次模型响应16,988$0.06988后续模型响应36251,568$0.2516$1.1491整个 task37258,556$0.3214$1.2189第一次响应的总输入为 30,770缓存输入为 0所以这 6,988 Token 可以按普通输入精确归属。后 36 次响应的缓存输入都足以容纳这段前缀但只有整条请求的缓存总量没有 block 级命中位置所以我保留区间不伪造一个精确金额。为什么我的本地编码场景会关这三类我的主要工作是单仓库内的 TypeScript 开发读代码、改文件、跑测试、看 diff。项目规范已经写在AGENTS.md和仓库文档里大多数任务使用本地文件、Git 和 shell不需要邮箱、日历、云盘或设计工具。在这个前提下三类取舍分别是技能目录我需要 skill 时会在任务里明确点名或者直接让 Codex 读取对应SKILL.md。每轮自动携带一份 1,7001,800 Token 左右的目录对我收益不高。记忆工程规则应该以仓库文件为准。我宁愿保留可审查的AGENTS.md也不希望旧项目偏好或历史总结在新 task 中自动参与判断。Plugins纯本地编码很少用外部服务。关闭 Plugins 既移除说明和推荐也明确放弃插件工具与插件 skill 发现。我保留 permissions、environment、AGENTS.md和协作/工具说明因为它们直接影响命令是否能成功、路径是否正确、项目规范是否被遵守。省 Token 不是目标正确完成任务、少返工才是。我的判断可以压缩成下面这张表使用场景技能目录记忆Plugins成熟仓库、纯本地编码、会显式点名 skill可关可关可关不熟悉的仓库希望 Codex 自动发现工作流开视情况视情况长期个人项目需要跨 task 保留偏好和背景视情况开视情况Slack/Gmail/Drive/Figma/日历等跨应用任务视情况视情况开探索性任务不确定会用到什么能力开开开如果只想做风险最低的一步优先考虑项目级关闭技能目录Memory 和 Plugins 是用户级设置会影响本机其他 Codex 项目的新 task决定前应逐个检查。手工调查太容易出错所以我做了个工具这次调查最后变成了 Skill Doctor 里的 Codex 优化流程。它不会上传会话也不会修改历史 JSONL它做的是把“看证据、算范围、改配置、建新 task 验证”串在一起。直接运行npx evilstar2025/skill-doctor ui第一步是选 Codex进入“优化建议”先看本周或本月的 task、turn、模型响应、输入/缓存/输出 Token 和 API 等价金额。明细最多显示 20 条但周期总计不会截断。第二步是逐项看影响。工具会显示作用范围、历史 block 证据、覆盖响应数、Token 与费用区间。Plugins 会明确标成全局高影响项。无法可靠控制的项目会单独列出原因例如推荐列表不能在 Desktop 中可靠地独立关闭、项目级单 skill 规则未生效、压缩后的上下文证据已经失效。证据不够时显示未知。确认前可以看原始会话与配置后预览。右侧只移除勾选的 blockpermissions、AGENTS.md、environment 等保留项不会被顺手删掉。最后用户级操作必须确认“影响本机所有 Codex 项目”。写入成功只代表配置已修改页面仍会显示“待验证”需要新建一个同项目 task再读取新的完整会话头确认目标 metadata kind 真正消失。完整路径是选择 Codex 和统计周期先看会话开销与证据覆盖逐项阅读“会失去什么”查看会话前后差异确认项目级或用户级影响并写入新建 task回到工具验证目标 block 是否真的消失。文中截图来自本地 UI 的另一统计时点用于说明操作流程截图金额采用工具内置价格表快照不等于本文 2026-09-07 至 09-13 样本的复算结果也不是订阅账单。如果你愿意试用欢迎把不同 Codex 版本、不同平台的验证结果和反例提到 GitHub Issues也欢迎一起完善 block 映射、价格口径和测试样本。Astra 的深度用户Pro5x, Pro20X还是很值得尝试的