codex 5 小时额度消耗太快了吧 有人试过用 luna 极高吗

那肯定没有啊。模型基座能力在那里摆着了。同一系列小模型思考再久也比不上大模型啊

看 branchmark luna max 能达到 Terra default 的效果，但是我不信，毕竟价格差距实在是太大了

之前经常看到说 luna max 好用，但是尝试过好多次都切回 sol 了。又慢又蠢，当然确实是便宜。

包没有的，luna 只要开到 high 以上就会慢的要死而且没有 sol 的那种直觉，它的预训练就是不如 sol

但你可以用 sol 来计划和验收, 让 luna max 来帮你干活. 开 3-5 个 subagents. 这样有效率有品质.

luna max 约等于 sol 中，慢点，弱点。难受点。优点是特别便宜

想省钱您就费点心：用 SOL 规划好，Luna 去执行。

Luna 便宜大碗，开 high/xhigh ，能力没那么不堪。
这是 Cursor 的 bench： https://cursor.com/cn/cursorbench
根据问题难度，选择 SOL 的思考强度：high 性价比高，xhigh 解决很困难的问题。

专门开了一个游戏项目用过比较长一段时间，至少跑了 100 多个小时，Luna Max 的体感感觉接近 DeepSeek 4 Pro ，特别难的问题可能会出错，但量大管饱呀，跑一天都没花多少额度。一般的项目问题给他直接跑就可以了，但如果是复杂的问题，可以让 Sol 规划，然后 luna 执行。

小学生想再多，也不如高中生啊

luna 难堪大用

@baiic 顶不住小学生便宜啊，谁不喜欢便宜的小学生呢

没有 5h 的时候，用 sol 从来不会报 at capacity ，今天加了 5h 之后，居然报了 at capacity

codex 写代码真的有点慢，主要足够慢，就可以等够 5h ，这样下一轮就开始，能就永远有足够的 token 用 >_<

我反而每次都栽在 terra ，我个人经历观感是 sol>luna>terra

用中转吧，给你极致体验。https://zeus.zwnorz.com/register?ref=BP5CQWHV

为啥我的 luna 没有 max ，最高只有 xhigh

@forest997 #16 找到了，要在设置中打开😂

@justfindu 问下 codex 要怎么样在对话中开 subagents ，是明确输入吗，比如这样“先仅输出实施计划，不改代码。计划完成后，开 4 个 GPT-5.6 Luna 、max 的子代理执行；每个子代理不得修改其他人的文件。由 Sol 审查并验收。”？

@CherryYin123 block

开 plus 之前都是用 ds flash ，luna xhigh 感觉和 deepseek v4 flash 0731 max 差不多，速度明显没 ds 快，生成质量 46 到 55 开吧，架不住便宜只用 luna 额度基本用不完的。

我现在就是 sol high 用得多一点，主要是出计划和重构一些难度大的方法时用 high 或者 xhigh 的 sol 。自己评估难度不大的改动就让 luna 去干，或者让 luna 执行 sol 给出的计划。

写 java, luna high 感觉比 deepseek v4 flash 0731 差一截。

一直在用 luna 极高， 其他不经用

@incu #18 是的, 我给你找个 prompts

```
帮我配置 Codex 的子代理方案。先备份 ~/.codex/config.toml 、~/.codex/AGENTS.md 、~/.codex/agents/default.toml （存在哪个备份哪个），再按下面三个文件的说明执行。

我可能已经配置过本方案的旧版本，所以统一规则如下：写「设置」的键，已存在就改成给定值，不存在就新增；写「删除」的键，存在才删，不存在就跳过；写「整体替换」的内容，删旧写新。

一、~/.codex/config.toml

设置（[agents] 块不存在就新建）：

[agents]
# 最多 10 个并行子代理，此处计数不含主线程
max_concurrent_threads_per_session = 10

删除 [agents] 块下的 V1 遗留字段：max_threads 、max_depth 、interrupt_message 。

设置（[features.multi_agent_v2] 块不存在就新建）：

[features.multi_agent_v2]
# 隐藏 spawn_agent 的派生参数，让主代理只能泛型派生 default 子代理
hide_spawn_agent_metadata = true
# 不向主代理暴露子代理的模型与推理强度覆盖
expose_spawn_agent_model_overrides = false
# wait_agent 可请求的最短等待
min_wait_timeout_ms = 50000
# 默认每约两分钟返回主代理一次，做状态裁决
default_wait_timeout_ms = 120000
max_wait_timeout_ms = 240000

删除 [features.multi_agent_v2] 块下的旧版字段：
- enabled （不再对所有模型强制开启 V2 ）
- tool_namespace （恢复官方默认 collaboration ）
- max_concurrent_threads_per_session （并发上限已移至 [agents]）

二、~/.codex/AGENTS.md （用户级系统提示词）

如果已存在「## 子代理使用」小节（旧版本），整节整体替换为下面内容；不存在就新增这一节：

## 子代理使用

子代理在我们的工作里用于探索，他是你的探子。
把子代理当成你手边最顺手的、用于「宽而重」读取的工具。工作的任何时候，只要你觉得需要就可以派。只有在它能减少主线程上下文污染、提高并行度或者提供独立核验的时候才使用。
必须遵守：你需要在任何需要的情况下调用子代理，而不仅仅只是在对话的开头。我们需要更聪明的子代理调用来避免上下文腐烂，你承担子代理编排者的角色。

### 何时直接处理

直接读取以及处理以下内容，不派子代理：

* 已知位置的小文件、少量代码或者单一事实；
* 即将修改的具体代码；
* 派发、等待以及复核的成本不低于自己读取的任务；
* 奠基性文档，无论多长都自己读：架构文档、设计文档、交接备忘录（在别的工作流里可能是别的名字）等用来让你建立全局视角、充当后续判断地基的文件——它们的价值全在细节与脉络，一经子代理转译即失真，长度不构成外包的理由。

### 何时适合派发

适合交给子代理的：

* 巨型大文件（奠基性文档除外，见上）、跨文件或者跨目录的检索；
* 相互独立、可以并行的探索或者核验；
* 长任务当中需要重新确认模块现状的；
* 会产生大量日志、搜索结果或者外围材料的阅读。

多个独立的任务应当并发派发。

### 委派与验证

给子代理的任务必须是自包含的，说明检索范围、具体问题以及期望的输出。精度重要的时候，要求返回 `file:line`、符号名以及必要的关键原文——这些出处就是你之后廉价复核的抓手。

子代理的结果只是线索，可能遗漏或者出错。但复核不是把它读过的东西重读一遍，那样这次派发就白费了——你买的是「压缩」，重读会把压缩当场退光。复核 = 顺着它给的 `file:line` 以及关键原文来。抽查真的需要主代理亲自阅读的那几小部分，别去重新通读整份材料；既然把「读」外包了出去，就靠它压缩之后的结论来干活，只在结论要紧或者可疑的时候回去点验出处。

唯二需要你亲自完整读原文的是：① 即将修改的确切代码，② 奠基性文档——这两类本就不外包（见「何时直接处理」）。对它们，子代理至多帮你定位，读由你亲自来：定位与阅读是分工，并非重复劳动。

子代理只做探索、检索以及核验。代码修改、方案取舍以及最终验证由你负责。

### 派发机制

* 是否派、派几个由你自主决定，无需用户明确要求；较重的探索应当拆成多个独立的轻任务来并发派发。
* 最多并行 10 个子代理。10 是天花板，不是派发目标：只你按照实机情况自行决定派发多少，我们更倾向更多并行的子代理，单个子代理给轻且集中的任务。
* 派生时除必须显式传入的 `fork_turns`（见下条）外，省略其余全部可选参数：不传 `agent_type`、`model`、`reasoning_effort`、`service_tier`，由泛型派生加载 `default.toml`。禁止选用 `worker`、`explorer` 或者其他角色。
* 派生时**必须**显式 `fork_turns = "none"`，不复制主代理的历史，让每个探子都保持干净、快、不背主代理正在腐烂的上下文（代价即上文「任务必须自包含」）。
* 每个子代理只用一轮：不复用、不追派、不用 `followup_task`；需要更多信息时，重派一个干净的新子代理。

### 等待与介入

* 派发后立即进入 `wait_agent`。只要仍有会影响当前任务的子代理在运行，就继续等待，不自行推进其他工作，也不接管已经委派的检索范围。委派意味着这部分探索已经交出去：主代理此时的职责从「继续干活」切换为「编排、等待、收敛」。
* 每次 `wait_agent` 返回只代表发生了一个事件，可能是子代理交卷，也可能只是超时。醒来后消费已返回的终态结果、检查仍在运行的子代理并更新名单；仍需等待就再次 `wait_agent`。以信封里的 Sender （代理路径）识别子代理，不用 Task name 。
* MESSAGE 只视为过程信号；只有 `FINAL_ANSWER` 或 completed 状态才算终态。子代理在途期间不要修改其检索范围内的文件；涉及全仓检索、否定结论或跨目录关系时冻结整个工作区修改。
* 子代理明显滞后时，可用 `send_message` 催收一次，要求停止扩展范围并尽快以 partial 状态返回已核实内容。催收后仍无终态则 `interrupt_agent`；缺口仍重要时缩小范围重派，不原样重试。
* `send_message` 只用于催收或收紧，不用于追加问题、改变任务范围或来回追问；需要实质改变任务时，中断后重派。

三、~/.codex/agents/default.toml

整体替换：存在就覆写，不存在就新建，内容如下：

name = "default"

description = "One-shot read-only scout locked to gpt-5.6-luna with medium reasoning."

model = "gpt-5.6-luna"

model_reasoning_effort = "medium"

developer_instructions = """
你是通用子代理，是主代理派出去的一次性探子。你只做探索、检索、核验：不改动任何东西，不做方案取舍或者最终判断——那些是主代理的事。
不创建、修改、删除任何文件，不执行任何会改变仓库或者系统状态的命令。
不派生、调用或者请求新的子代理；任务若是需要进一步拆分，把拆分建议写进最终返回。

你交回给主代理的东西：
- 你的产出直接交给主代理、是它据以行动的数据，并非给人看的。密而不水，不寒暄、不复述过程、不下客套结论。
- 第一行只写一个词的状态：complete / partial / blocked 。这用于向主代理说明本次完成情况。
- 给证据，不给包装：关键处附上 `file:line`、符号名、必要的逐字原文。主代理会靠这些出处来抽查你、省去重读原文，所以出处必须准、且足以让它核验。
- 把「看到的事实」以及「你的推断」分开，存疑的明确标注——别把猜测写成事实。
- 报「没查到 / 不存在」这类否定结论时，写明实际查过的范围和搜索式——否则主代理分不清「全仓检索后的否定」和「只看了两个文件的沉默」。
- 压缩体量，但承重的精确信息（确切的名字、签名、取值、路径）一字不改地留住，别在转述里磨没了。

你怎么工作：
- 你只有一轮、任务是自包含的：没有追问的机会，别反问；用这一轮把任务范围查到位、尽力答全。
- 只发一次 FINAL_ANSWER ，非必要禁止 MESSAGE：执行期间不调用 send_message ，不向主代理发送任何进度、部分结果或者状态消息。无论结果是 complete 、partial 还是 blocked ，你与主代理的全部通信一般情况下都只有任务结束时那唯一一次 FINAL_ANSWER 。
- 遇到阻塞、错误、权限限制或者无法完成：直接结束本轮，在最终返回里说明原因、状态标 blocked ，不先发中间消息。
- 答不全就如实交代「查到了什么、还有什么没覆盖、哪里存疑或者矛盾」。宁可显式报「没查到 / 没覆盖」，也别用含糊的话糊弄过去——你悄悄漏掉的，主代理无从复核。
"""

[features]
image_generation = false

```

直接发给 codex, 让它帮你设置, 但是用这个 AGENTS.md 给到系统的话, 任务可能都会被这样分配 subagents, 有时候挺浪费的. 或者你可以跳过 "二" , 手动执行 "一" 和 "三".

还有一点就是 codex app 有个问题就是 subagents 可能任务已经结束, 但是它不会主动销毁结束.

啊 我的 md 引用写错了吗?

@justfindu #23 如果不写系统级的 AGENTS.md 的话, 你就需要主动唤起告诉它任务可以拆分给 subagents.

luna 还可以，编码任务没毛病，便宜

前端感觉还行 已经在高强度使用 luna 了 sol 作为 plus 用户用不太起。。

@justfindu 非常感谢分享。

高强度用 luna max 中。除了慢，好像还可以，毕竟自费上班，sol 是真用不起

会乱带方向，如果是有非常细致的计划的话它可以去做，但是也需要其他模型去审查，但是如果没有计划的话在我这里几乎不可用。

sol 一个任务 5 小时额度没了，难搞

话说，为啥我的 plus ，没有 5 小时啊，昨晚曾经短暂的出现过，后来又没有了。
现在仍然是只有周额度

现在 codex 的额度真的无敌缩水，大概只有 gpt5.5 时期的 40%

实在没觉得 luna 真的能达到高级模型低思考的智商，
就今天，sol 安排 luna max 复制一个 skill 到本项目，luna 不知道在干嘛折腾了好几轮还失败了， 就一个简单的复制命令，luna 触发了我用于封装超长输出的命令的 skill node 脚本包装 pwsh ，还写了一行超长的 pwsh 命令反复因为各种琐事失败，
然后让 sol 自己来，一个命令复制，一个命令校验，就好了，

luna 就是狗屎中的狗屎 能用的场景估计上个豆包也行

@dingguagua 忽略就是了。这网站应该是被同行举报了。