Evaluate Ultra reasoning and automatic delegation support for Luna and third-party models

[NOirBRight]

背景

当前模型目录中，Sol/Terra 提供 low / medium / high / xhigh / max / ultra，而 Luna 只提供到 max。第三方模型通常也只暴露到 max。

模型目录对两个等级的描述是：

• Max：Maximum reasoning for the hardest problems
• Ultra：Maximum reasoning with automatic task delegation

用户希望评估是否应当让 Luna 或其他第三方模型支持 Ultra，以及需要满足什么条件。

需要讨论的问题

1. Ultra 与 Max 的准确行为差异是什么？
   • Ultra 是否只是更高的推理预算，还是额外启用“模型自主拆分任务并委派子任务”的策略/权限？
   • Max 是否也能在用户明确要求或运行时允许时使用 Collaboration/子代理工具？
2. Ultra 的能力边界由哪一层决定？
   • 模型本身的推理能力与稳定性
   • Responses/Chat API 对 reasoning effort 的支持
   • Codex 的 Collaboration V1/V2、并行调用、取消/超时、结果汇总等运行时能力
   • 模型目录、账户/套餐和服务端授权
   • Provider/gateway 对 ultra 的透传与错误处理
3. Luna 是否具备技术能力但尚未获得产品授权，还是需要不同的模型/运行时支持？
4. 第三方模型应如何声明 Ultra：需要独立的 capability 字段，还是仅允许模型目录在验证通过后列出 ultra？
5. 如果上游只支持 max，客户端应该隐藏 Ultra、明确拒绝，还是允许显式降级？不应把 max 静默伪装成 Ultra。

建议的评估方向

• 用官方 Sol/Terra 建立 Max 与 Ultra 的可观测行为对照：是否自动产生子任务、并行度、预算/延迟、失败和取消语义。
• 建立 Luna 与第三方模型的能力矩阵，区分“模型推理等级”和“自动任务委派/编排能力”。
• 定义第三方 Ultra 的最小契约：服务端接受并执行 ultra，支持所需的 Collaboration 运行时能力，并由模型目录显式声明且通过回归测试。
• 在契约和验证完成前，继续只对已声明支持的模型展示 Ultra；不要仅通过本地配置添加一个选项。
• 明确降级/错误提示，避免用户以为已经获得 Ultra 级别的委派或推理预算。

验收标准（讨论完成后）

• 形成 Max/Ultra 的产品语义和运行时行为说明。
• 给出 Luna 是否可支持 Ultra 的结论及依据。
• 给出第三方模型的 Ultra capability contract 和验证清单。
• 决定 UI、模型目录和 gateway 在不支持 Ultra 时的显示及错误策略。
• 如决定实施，再拆分为模型目录、运行时、Provider/gateway、UI 和测试等独立任务。

本 Issue 是评估/设计讨论，不要求通过修改元数据来伪造 Ultra 能力。