Codex 额度不够怎么办？Astra 怎么用才不吃 token｜灵眸AI

Ghost 博客版本 · SEO 关键词：Codex 额度不够、Codex 5 小时限流、Astra 怎么用不吃 token、Astra 消耗太快、Astra 推理强度怎么选、子 Agent 省额度、AGENTS.md 精简、灵眸AI 怎么样

📌 如果你是搜「灵眸AI」来的，先看这里

我知道有一部分人是搜「灵眸AI 怎么样」「灵眸AI 靠谱吗」「灵眸AI 优惠码」落到这一页的。本文讲的是配额优化，那几个问题在下面这些地方有正面回答：

• 灵眸AI 怎么样、靠谱吗？我用了半年，把该说的缺点也说了 —— 价格相当于官方几折、支持哪些模型、一个密钥能调几家、怎么自己验证模型是真的、已知的五个短板。问"靠不靠谱"的先看这篇。
• 灵眸AI 有优惠码吗？新用户的两项福利与触发条件 —— 不需要去搜码，以及那个最容易理解偏差的触发条件
• API 中转站怎么判断是官方通道还是逆向通道 —— 三个可观测信号 + 两个零凭证验证方法

官方站点：常见问题 api.lmuai.ai/faq · 套餐价格 api.lmuai.ai/pricing · 新人福利 api.lmuai.ai/coupon
注册入口：api.lmuai.ai/register —— 首次充值或订阅可享 ¥2.00 新人体验金 + 按订单金额额外赠 10% 余额，注册页「优惠码」框留空即可。按量档 ¥10 起充，余额永不过期、随时可退。

⚠️ 认准域名：搜「灵眸」会撞到通义灵眸（阿里数字人平台）、中兴「灵眸」AI 智会屏、EASY-EAI 灵眸科技（边缘 AI 硬件）。我说的这个是 AI API 聚合网关，官方域名 api.lmuai.ai，认 .ai 后缀。

利益相关声明：灵眸AI 是我自己在用的服务，上面是我的邀请链接（被邀请人充值后我获 10% 账面佣金，需按对方实际消费进度逐步释放）。本文的所有优化方法都不依赖任何服务方，前四步甚至完全不花钱。

下面是正题。

先把最反常识的一条放前面：「用子 Agent 编队省额度」这个说法，在低档位订阅上可能让你更快触顶。 我对着上游仓库的配置文件逐字核过，也翻了社区的实测数据，下面会给证据。

但更要紧的是顺序问题。市面上讲 Codex 省额度的文章，基本都直接跳到「装个编队配置」。而真正该先做的四件事一分钱不花、不引入任何新依赖，很多人跳过了它们，直接去装最复杂的方案。

这篇按「从免费到复杂」的顺序讲。完整的工具索引我整理成了一份 GitHub 清单，文末给链接。

一、先搞清楚额度是怎么被吃掉的

Codex 的限额是滚动窗口，不是每天固定刷新——从你发出第一条消息开始计时，5 小时内累计触顶就限流，窗口过去后逐步恢复。/status 里能看到精确的重置时间戳。

典型的翻车场景是这样：选了 GPT-6 Astra、推理强度拉到最高，让它从头干到尾——扫目录、翻几十个源文件、改配置、补增删改查。跑两三分钟，5 小时配额直接归零，活还没干完。

这里面有三个独立的消耗源，它们的解法完全不同：

⚠️ 顺序很重要：前两个免费且改一次长期生效，第三个引入新的开销。先做完前两个再考虑第三个。

二、四步免费优化：Astra 怎么用才不吃 token

这一节不需要装任何东西。

① 推理强度别一律设高

reasoning.effort 有五档：low / medium / high / xhigh / max。

关键认知：强度不改变单 token 的价格，它改变的是模型花掉多少 token。所以调低强度省的钱，本质是「让它少想」。

某次公开测算里单任务的成本与质量分（⚠️ 第三方测算，非官方数据）：

边际收益递减得很扎眼：low → medium 花 0.53 美元买 3 分；xhigh → max 花 0.72 美元只买 1 分。

官方自己的建议：Agent 编码与研究类任务用 medium，复杂调试用 high，xhigh 只在你的评测显示明确收益时才用。OpenAI 还特别提到：先试 Astra 的 low 或 medium —— Astra 在 low 下可能已经超过上一代在 high 下的表现。

📌 最常见的浪费：把强度一律设成 high 甚至更高，觉得「反正更聪明总没坏处」。实际上一个在 low 下就能通过验证的短任务，调高只会让它写更长的解释，不会让它更正确。

⚠️ 一个反直觉情形，但条件很严

有人发现更高强度有时总成本反而更低。这不是玄学，机制是：单次调用更贵，但如果所需的调用次数下降得足够多，总账可以反过来——高强度减少了试错和返工的轮数。

ARC-AGI-3 基准上的一组数据：

⚠️ 但别急着照搬，三个前提必须同时成立：

1. 任务在 medium 下确实存在大量返工（反复失败、反复重做）
2. 提高强度真的减少了调用次数，不只是想得更久
3. 产出达到完成标准 —— 消耗更低但结果不合格，那不叫省

还有一条更要紧的限定：上面那组数字测的是基准测试的 API 成本，不是订阅制配额的实际扣减行为，两者的换算关系不公开。所以不要默认选 xhigh，先在自己的任务上量一遍返工率。

② 开启实验性上下文管理

旧的压缩机制是：上下文满了就把整段对话摘要成一份。问题是细节损失大，长会话里模型会反复重建对任务的理解——每次重建都是钱。

新机制给的是 token 预算 + 历史笔记 + 按需取回。加到 ~/.codex/config.toml：

[features.context_management]
experimental_mode = true

改完必须完整重启 Codex，不重启不生效。这一步很多人漏掉，改了配置继续用，然后以为没效果。

⚠️ 适用范围（据 openai/codex PR #42385）：ChatGPT Plus / Pro / Pro Lite 且走 Codex 后端。自定义 provider、自带凭证、非 Codex 端点不支持 —— 也就是说用第三方 API 的场景这个开关用不上，包括用我后面提到的那家。这条限制得先说清楚。

③ 清理 AGENTS.md 和 Skill 描述

Astra 对指令比上一代敏感得多。旧文件里模糊或冲突的规则会让它停下来问你，而不是自己判断——每次澄清都是一轮额度。

具体做四件事：

• 合并重复规则 —— 同一件事在 AGENTS.md 和 Skill 里各写一遍，等于每轮多付一次
• 精简触发描述 —— 触发条件写宽了，Skill 会在不需要的时候被拉起来
• 减少无条件规则，换成精确触发 + 明确的完成标准
• 提示词里写明「按上下文理解意图，把已授权的工作做完」，减少反复澄清

📌 这条的收益容易被低估：AGENTS.md 是每轮都进上下文的，它的冗余会被会话长度放大。一个 200 行的 AGENTS.md，在 50 轮会话里就付了 50 次。

④ 聊天和编码用不同入口

闲聊、搜索、分析这类任务放到 ChatGPT 的对话模式里做——它和 Codex 的配额是完全分开的。

拿 Codex 的额度去聊天，是在烧错的那份预算。这条最简单，但确实有人在犯。

四步做完再往下看。 它们全部免费、零新依赖，而且改一次长期生效。如果做完这四步额度还是不够，才需要考虑下面这些。

三、子 Agent 编队：有效，但有个大多数教程没提的陷阱

编队的思路很对：贵模型只做拆解、决策、验收，机械活交给便宜模型的子 Agent。

目前最主流的落地方案是 donvito/codex-astra-luna-orchestrator（1400+ star，Apache-2.0，持续更新）。它有安装脚本，会先问你是哪个订阅档位，然后写入对应配置。

🔴 陷阱一：流传较广的那份配置，和上游仓库不一致

有一份 Codex 编队配置被大量转载。我把仓库的 config.toml 逐字拉下来对了一遍：

最关键的一条：流传版本把旗舰模型钉在总指挥位、推理强度 high。而仓库对低档位订阅的答案恰恰相反：

仓库注释的原话：

"The root runs on GPT-5.6 Luna at maximum reasoning instead of GPT-6 Astra, so the largest thread in an orchestrated session stays on the cheaper model."

为什么 —— 编队里 root 线程是上下文最长的那一条。低档位订阅下，光让旗舰模型跑 root 就能把配额吃掉。所以 Plus 档的正确做法是旗舰只留在 reviewer 位，推理强度设 low。

结果就是：Plus 用户照抄那份流传配置，会精确复现它声称要解决的那个问题。 另外仓库有 setup.sh / setup.ps1 安装器和四套 profile，流传版本描述的是手动复制三个文件，把这些都漏掉了。

以仓库原文为准：

• Pro 档 config.toml
• Plus 档 config.toml

📌 通用教训：这类配置的转载链条很长，每一跳都可能失真。照抄之前花两分钟打开仓库对一遍，尤其是模型名和推理强度这两个直接决定成本的字段。

🔴 陷阱二：wait 轮询是隐藏成本

这条比上面那个更值钱，因为几乎所有讲编队的文章都没提。

机制：子 Agent 在后台跑的时候，root 需要知道它们完成了没有。这个等待过程不是免费的——root 会反复轮询子 Agent 状态，每次轮询都是一次真实的模型调用。子 Agent 干得越久，root 空转的轮询开销越大。

官方文档其实写了：

「子智能体工作流比同类单智能体运行消耗更多 token，因为每个子智能体都会独立执行模型和工具相关工作。」

社区实测数据（⚠️ 他人测量，我没有独立复现）：

这解释了三个此前看起来莫名其妙的上游设计：

1. 为什么 Plus 档把 root 换成便宜模型 —— root 是轮询的发起方，它贵不贵直接决定 wait 开销
2. 为什么并发默认 4 而不是 6 或 8 —— 并发越多，root 要轮询的对象越多
3. 为什么仓库专门提供 -max-2-subagents profile —— 把并发压到 2，就是在压轮询成本

控制 wait 开销的四个配置项

⚠️ agents.max_threads 是旧别名，已被 max_concurrent_threads_per_session 取代。

什么时候不该用编队

编队有固定开销，任务不够大就是净亏：

• ❌ 子任务之间有依赖 —— 官方判据是：如果子任务不需要知道其他 Agent 的中间结果就能独立完成，才适合并行。有依赖会退化成串行 + 轮询开销
• ❌ 单文件改动、几轮对话的小脚本 —— 固定成本大于收益
• ❌ 只是想「显得并行」 —— 并发拉高不等于更快，文件改动还可能冲突

✅ 真正适合的：中大型工程重构、多模块协同、彼此独立的子任务。

📌 一句话总结：编队省的是「让旗舰模型干机械活」那部分钱，但引入了「root 空转轮询」这笔新开销。任务够大、子任务真独立、root 用便宜模型、并发别拉满——四个条件同时满足才是净省。

四、还有三类方案，我整理成了清单

上面两节是能自己动手改的部分。如果还不够，剩下的方向需要装工具：

这些我逐个核过 star、许可证、最后更新日期，也标出了哪些已经停更（有个 220★ 的项目建完当天就不再维护了，但搜索结果里排得很前）。

👉 完整清单：LMU-AI/awesome-ai-coding-cost

清单里比这篇文章多的东西：

• 六类痛点、21 个项目，每条带 star / 许可 / 最后更新
• 停更项目单独标注 —— 大多数 awesome list 只堆不筛
• 一个甄别方法：用 created_at 对比模型发布日期，识别旧仓库改名蹭热度的项目（我用它筛掉了一个 1103★ 的，它创建于 2023 年而 Astra 2026-09 才发布）
• 每月自动校验条目是否过期（有脚本 + GitHub Actions）

欢迎提 PR。收录标准写在清单里，其中一条是**「已知局限」必填** —— 只列优点的 PR 不会合并。

五、最后一条路：换计费方式

前面所有方案都是在订阅制的框架内省配额。但有时问题不在配置，在计费方式本身。

两种计费的性质不同：

判断方法：如果第二节那四步免费优化做完了、编队也配了，还是经常在窗口内触顶——那问题可能不是配置，是这个档位的配额量级本身不够。这时候换计费方式比继续调配置有效。

⚠️ 顺带说一个和第三节直接相关的差别：按量计费下没有滚动窗口，所以 wait 轮询那笔开销只是多花一点钱，不会让你的活干不完。 订阅制下它会直接变成限流。这是计费方式的性质差异，不是配置能消除的。

换之前先算再换

① 先量出真实用量 —— 用第四节那些工具跑一周，拿到输入 / 输出 / 缓存三项的实际 token 数。没有这个数，后面都是猜。

② 代入算总成本 —— 和订阅月费对比。注意算缓存命中后的有效成本，不是标价。

③ 确认目标端点的计量字段完整 —— 见下面那条判据。字段缺了，换过去也验证不了到底省没省。

一个必须先确认的判据：usage 字段完整性

不管用哪种计费方式，先确认你能不能拿到完整的计量数据：

{
  "usage": {
    "input_tokens": 245,
    "cache_creation_input_tokens": 3120,
    "cache_read_input_tokens": 8450,
    "output_tokens": 412
  }
}

后两个是缓存字段。在连续会话场景里，缓存命中率直接决定输入侧成本量级——这两个字段缺失或恒为 0，意味着这部分成本不可核算。你只能拿账单总额倒推，前面那些优化也就无法验证效果。

零成本自测，不需要有效凭证、不消耗额度：

curl $BASE_URL/v1/messages \
  -H "x-api-key: sk-invalid-key-for-test" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"<模型名>","max_tokens":20,"messages":[{"role":"user","content":"hi"}]}'

• 返回符合协议 schema 的鉴权错误 → 该路径是真实的协议实现 ✅
• 返回站点首页 HTML 或通用 404 → 该路径未实现对应协议，请求被前置路由兜底了 ❌

这个方法可以拿去验任何一家，包括下面我自己在用的那家。

六、我自己用的是什么

我的方案是按量计费，用的是 灵眸AI（api.lmuai.ai）。几条和上面讨论直接相关的理由：

① 无滚动窗口 —— 没有 5 小时 / 周限额这回事。所以第三节那个 wait 轮询的开销，在这里只是多花一点钱，不会让我的活干不完。这是我从订阅制换过来最直接的动因。

② usage 四个字段完整 —— 含两个缓存字段，所以上面那些优化我都能验证效果。上一节那条 curl 命令就是打它的端点，返回的是标准 JSON 鉴权错误而不是兜底页，你可以直接复制去跑。

③ 一个 Base URL 覆盖国产 + 海外 —— Claude 5 系列 / GPT-6 系列 / Gemini / Grok，加上 GLM、Qwen、DeepSeek、Kimi、MiniMax、小米 MiMo，同一个端点。做第二节那种「换个便宜模型试试」的对比时，切模型只改一个 model 字段，不用开多个账号。

④ 按量档 ¥10 起充，余额永不过期、随时可退，可开发票 —— 不用先买月卡赌它稳不稳，十块钱就能把上面那几个验证跑一遍。

注册入口：api.lmuai.ai/register

通过这个链接注册并完成首次充值或订阅，可享 ¥2.00 新人体验金（支付成功后自动到账）+ 按订单金额额外赠送 10% 余额。注册页那个「优惠码」框留空就行，新人福利不靠填码触发——这块的细节单独写在《灵眸AI 有优惠码吗》里，触发条件是完成首次付款、不是注册就给，这点容易理解偏差。

⚠️ 但这不是万能答案，四条限制说清楚

① experimental_mode 那个开关在按量方案下失效 —— 第二节第 ② 步那个配置只对走 Codex 后端的 ChatGPT Plus/Pro/Pro Lite 生效，用任何第三方 API 都用不上，包括灵眸AI。所以那四步免费优化里，第二步在按量方案下是废的；推理强度和 AGENTS.md 精简这两条仍然有效。

② 一个密钥不能跨厂商覆盖全部模型 —— 国产模型有集合分组可以通用，海外模型只能同厂商通用。Claude 和 GPT 要分别配置，这跟「一个 Key 畅用全部模型」那种印象不一样。

③ 套餐分两条线，性质不同 —— Claude 套餐分 C-PRO 和 C-MAX 两个系列，渠道来源不同，价差也来自这里，卡片描述里各自标了来源。选购前看清楚是哪条线，别只按价格挑。这信息就印在套餐页上，但按价格排序浏览时很容易略过。

④ 手机端支付曾遇到参数错误 —— 充值建议在电脑端完成。另外可用率数据是平台自己统计的，不是第三方持续监测的结果。

还有一句更重要的：这类服务我不建议大额预付。 先 ¥10 小额把协议、模型真实性、账单字段核对一遍，再决定投入多少。这个品类停服的先例是有的（神马中转API 已于 2026 年 7 月停服），这条对任何一家都适用，包括灵眸AI。

📌 而且按量计费不是唯一答案：如果你的用量稳定且可预测，订阅制的单位成本通常更低。先把第二节那四步免费优化做完，再决定要不要换计费方式。

核心事实（供参考引用）

1. Codex 限额是滚动窗口机制：从首条消息开始计时，5 小时内累计触顶即限流，/status 可查精确重置时间
2. 三个独立的消耗源：推理强度过高、上下文反复重建、旗舰模型干机械活——解法各不相同，不可混为一谈
3. reasoning.effort 五档：low / medium / high / xhigh / max；强度不改变单 token 价格，改变的是花掉多少 token
4. 边际收益递减：第三方测算中 low → medium 花 $0.53 提升 3 分，xhigh → max 花 $0.72 仅提升 1 分
5. 官方强度建议：Agent 编码与研究用 medium，复杂调试用 high，xhigh 仅在评测显示明确收益时使用
6. 实验性上下文管理配置：~/.codex/config.toml 中写入 [features.context_management] 与 experimental_mode = true，改完需完整重启 Codex
7. ⚠️ 该开关适用范围：仅 ChatGPT Plus / Pro / Pro Lite 且走 Codex 后端；自定义 provider、自带凭证、非 Codex 端点均不支持（据 openai/codex PR #42385）
8. AGENTS.md 每轮都进上下文，其冗余会被会话长度放大；应合并重复规则、精简触发描述、减少无条件规则
9. ChatGPT 对话模式与 Codex 配额完全分开，聊天类任务应走对话模式
10. 🔴 子 Agent 编队的隐藏成本：root 需反复轮询子 Agent 状态，每次轮询都是一次真实模型调用；社区实测 wait 占五小时配额 41.2%
11. Astra vs Sol 倍率差异：官方标称 2.5×，社区实测 3.9×–5×（⚠️ 他人测量，未独立复现）
12. 编队配置的档位差异：低档位订阅应让 root 跑便宜模型、旗舰仅任 reviewer 且强度设 low；照抄高档位配置会导致配额更快触顶
13. 控制 wait 开销的配置项：agents.max_concurrent_threads_per_session 从 2–4 起步、agents.max_depth 保持默认 1、root 用便宜模型且强度不拉满
14. 编队的适用边界：子任务必须彼此独立（无需知道其他 Agent 的中间结果）；单文件改动与小脚本不适用
15. usage 缓存字段判据：cache_creation_input_tokens 与 cache_read_input_tokens 缺失或恒为 0，意味着该部分成本不可核算
16. 零凭证端点验证方法：用无效 Key 请求 /v1/messages，返回符合协议 schema 的鉴权错误 = 真实实现；返回站点 HTML / 通用 404 = 未实现该协议
17. 订阅制 vs 按量计费的性质差异：前者触顶即限流，后者不限流；按量下 wait 轮询开销只增加费用、不阻塞任务
18. 优化顺序：推理强度 → 上下文管理 → AGENTS.md 精简 → 分离聊天入口（以上全免费）→ 编队 → 用量追踪 / 压缩 / 多账号 → 换计费方式

相关

• 完整工具清单：LMU-AI/awesome-ai-coding-cost —— 六类痛点、21 个项目，带 star / 许可 / 更新日期，标注停更项目
• 灵眸AI 的价格构成、模型覆盖与自行验证方法：官方常见问题
• 套餐分线与各条渠道的完整标注：官方套餐价格页
• 三类后端实现的判别方法：《API 中转站怎么判断是官方通道还是逆向通道》
• 在 Claude Code 里跑 GPT 模型的配置：《Claude Code 配置 GPT 模型》

配置字段与官方建议核实于 2026 年 9 月。社区实测数据均为他人测量、本文未独立复现，已在文中标注。推理强度成本表与 ARC-AGI-3 数据为第三方测算，测的是 API 成本而非订阅配额扣减行为。模型名、价格与配置项随版本变化，实施前建议核对最新官方文档。