# Opus 4.7 Low Vs Medium Vs High Vs Xhigh Vs Max：来自开源仓库 29 个真实任务的推理曲线

Stet publishes a public search API over its indexed pages; the guide is at https://www.stet.sh/agents/agent-access.

Source: https://www.stet.sh/zh/blog/opus-47-graphql-reasoning-curve
Source observed: 2026-11-08T19:51:35.006Z
Last checked: 2026-11-08T19:51:35.006+00:00
Indexed: 2026-11-08T20:36:32.76+00:00

---

# Opus 4.7 Low Vs Medium Vs High Vs Xhigh Vs Max：来自开源仓库 29 个真实任务的推理曲线

**2026年5月12日 · 20 分钟阅读** · [BenStet，Stet 创始人](https://www.stet.sh/about)

## 摘要

我们在 Claude Code 中让 Opus 4.7 使用 low、medium、high、xhigh 和 max 五种 reasoning effort，在用 Go 编写的开源 GraphQL-go-tools 仓库上分别完成同一组 29 个真实任务。每项任务来自一个真实合并的 PR 或 commit。

在这组任务中，Opus 4.7 没有呈现“reasoning effort 越高，智能越高”的线性曲线。**Medium 在主要质量指标上达到峰值**：测试通过率 28/29、equivalence 14/29、code-review pass 10/29，以及最高的 aggregate craft/discipline 分数 2.759。Low 更快、更便宜，但正确性损失明显；High、Xhigh 和 Max 花费更多时间与成本，却没有在主要质量指标上超过 Medium。

更多 reasoning effort 改变了 Claude 的工作方式，却没有可靠改善判断。Xhigh 明显扩大了测试和 fixture 表面；Max 做了更多 shell 探索、测试和实现行数，但补丁总体仍不如 Medium。一个可能的解释是 Opus 4.7 使用 adaptive thinking，模型已会按任务自行选择推理预算，因此提高 effort 更像是在偏置自适应策略，而不是购买额外智能。

对照实验是同一 repo family 上的 [GPT-5.5 GraphQL reasoning curve](https://www.stet.sh/zh/blog/gpt-55-codex-graphql-reasoning-curve)：GPT-5.5 的 equivalence、code-review pass 和 craft/discipline 随 reasoning 增加而明显上升，曲线不同于 Opus 4.7。

## 主要结果

| 指标 | Low | Medium | High | Xhigh | Max |
| --- | ---: | ---: | ---: | ---: | ---: |
| 全任务通过 | 23/29 | **28/29** | 26/29 | 25/29 | 27/29 |
| Equivalent | 10/29 | **14/29** | 12/29 | 11/29 | 13/29 |
| Code-review pass | 5/29 | **10/29** | 7/29 | 4/29 | 8/29 |
| Code-review rubric mean | 2.426 | **2.716** | 2.509 | 2.482 | 2.431 |
| Footprint risk mean | 0.155 | 0.189 | 0.206 | 0.238 | 0.227 |
| 全部 custom graders | 2.598 | **2.759** | 2.670 | 2.669 | 2.690 |
| 平均 cost/task | $2.50 | **$3.15** | $5.01 | $6.51 | $8.84 |
| 平均 duration/task | 383.8s | **450.7s** | 716.4s | 803.8s | 996.9s |
| 每美元 equivalent passes | 0.138 | **0.153** | 0.083 | 0.058 | 0.051 |

“Equivalent”表示候选补丁匹配已合并人工 PR 的行为意图；“code-review pass”表示 AI reviewer 判断补丁可接受；craft/discipline 是 0–4 的可维护性与风格 rubric；footprint risk 表示相对于人工补丁，agent 额外触碰的代码量。

这是一条非单调曲线：Medium 通过 28/29 个任务，Max 以 27/29 最接近；Medium 的 equivalence 为 14/29（48%），review pass 为 10/29（35%），Xhigh 的 review pass 则降至 4/29（14%）。High、Xhigh 和 Max 的 footprint risk 都高于 Medium。

## 实验设置

每个任务使用冻结的 repo snapshot、描述目标改动的 prompt，并在 Docker 容器中获得一次产出补丁的机会。Stet 应用补丁，在隔离容器中运行任务测试，然后继续评估：

- **Equivalence**：候选补丁是否实现与人工补丁相同的行为改动。
- **Code review**：考虑正确性、引入 bug 的风险、可维护性与边界情况，reviewer 是否接受补丁。
- **Footprint risk**：与人工补丁相比，agent 额外触碰了多少代码。
- **Craft/discipline rubrics**：评估 clarity、simplicity、coherence、intentionality、robustness、instruction adherence、scope discipline 和 diff minimality。

每个模型在每项任务上使用单个 seed 运行一次。LLM-as-a-judge 使用 GPT-5.4；judge 看到任务与补丁，但不知道生成补丁的模型或 effort。我们也手工检查了代表性案例。任务集没有人工 grader calibration，因此应更重视 delta 的方向，而不是任何单个绝对分数。

本实验使用：

- 模型：Opus 4.7
- Harness：Claude Code 2.1.126–2.1.138；不同运行臂的版本随运行日期变化，每次运行均 npm 安装当时最新版本
- 数据集：29 个真实 GraphQL-go-tools 任务
- 主要指标：test pass、semantic equivalence、code-review pass、footprint risk、craft/discipline custom graders、cost 和 runtime

我们也把这些评估用于 autoresearch 优化循环，例如让 coding agent 改进仓库的 `AGENTS.md`，再用 Stet 在历史任务上测试候选改动，并根据结果迭代。

## Low：更便宜、更浅，也不完整

| 指标 | Low | Medium | Δ |
| --- | ---: | ---: | ---: |
| 全任务通过 | 23/29, 79.3% | 28/29, 96.6% | -17.2pp |
| Equivalent | 10/29, 34.5% | 14/29, 48.3% | -13.8pp |
| Code-review pass | 5/29, 17.2% | 10/29, 34.5% | -17.2pp |
| Footprint risk mean | 0.155 | 0.189 | -0.034 |
| Craft/Discipline avg | 2.598 | 2.759 | -0.161 |
| Cost/task mean | $2.50 | $3.15 | -$0.65, 0.79x |
| 平均 duration | 383.8s | 450.7s | -66.8s |

Low 更快、更便宜、footprint 更低，但经常只处理问题表层，漏掉任务的重要部分。

PR #1230 修复两个 GraphQL federation query-planner bug，并在 GraphQL datasource print path 添加 empty-selection-set guard。Low 把手写递归 AST helper inline 到 `graphql_datasource.go`，而不是注册 planner-scoped validation rule；unique-node selection 逻辑仍过于 eager，测试失败，补丁也不 equivalent。Medium 则在正确的 package boundary 中完成了接入 planner 的 `printKitPool` 专用 validation rule，并匹配人工 PR 的 two-pass planner shape。

实际选择上，Medium 只比 Low 贵约 26%（$2.50 → $3.15），但整体表现明显更好。

## Medium：克制与正确性的平衡

| 指标 | Medium |
| --- | ---: |
| 全任务通过 | 28/29, 96.6% |
| Equivalent | 14/29, 48.3% |
| Code-review pass | 10/29, 34.5% |
| Footprint risk mean | 0.189 |
| Craft/Discipline avg | 2.759 |
| Cost/task mean | $3.15 |
| 平均 duration | 450.7s |

Medium 做了足够的 repo 建模，但没有漂移到 prior-PR 合理化、no-op 叙事或过大的补丁表面。它拥有最好的测试通过数量、与人工补丁最高的 equivalence、最高的 code-review pass，以及最高的 craft/discipline 表现。

PR #1260 要求让 GraphQL subscription query plans 包含 trigger metadata（subgraph name/ID、trigger query），并让 `SkipLoader` query-plan introspection request 在不打开 upstream stream 的情况下返回 subscription plan。Low 被部分已有代码迷惑，要求 operator 提供 PR diff，最终无补丁。High 和 Xhigh 找到 commit hash `34cc4fa8` 与 `69485dfe`，错误地判断功能已经发布，于是以 no-op 结束。Medium 读取实际控制流，发现 `SkipLoader` 分支位于 `Trigger.Source == nil` guard 之后，对 plan-only request 不可达，于是完成最小的 hoist-and-extract 修复并通过测试；Max 也完成同样修复并额外添加 regression test。

## High：更多思考的边界

| 指标 | Medium | High | Δ |
| --- | ---: | ---: | ---: |
| 全任务通过 | 28/29, 96.6% | 26/29, 89.7% | -6.9pp |
| Equivalent | 14/29, 48.3% | 12/29, 41.4% | -6.9pp |
| Code-review pass | 10/29, 34.5% | 7/29, 24.1% | -10.3pp |
| Footprint risk mean | 0.189 | 0.206 | +0.017 |
| Craft/Discipline avg | 2.759 | 2.670 | -0.089 |
| Cost/task mean | $3.15 | $5.01 | +$1.86, 1.59x |
| 平均 duration | 450.7s | 716.4s | +265.7s |

High 花费 $5.01/task、运行 716.4s/task，但通过率降至 26/29，equivalence 降至 12/29，review pass 降至 7/29，review-rubric mean 降至 2.509，aggregate custom quality 降至 2.670。额外 effort 可能把工作带向更大或更不聚焦的路径，而没有带来对应的语义判断改善。

PR #1293 是 planner/resolve metadata 重构，并包含 `FetchInfo`、`BuildFetchReasons` planner switch、`FieldCoordinate` 替换 `KeyConditionCoordinate`，以及 `go.work` 中 `toolchain go1.25` → `go1.25.1` 的一字符改动和两个 Makefile 的配置清理。High、Xhigh 和 Max 都跳过了 go.work 与 Makefile 修复，导致 `go test` 在 Go 代码运行前因 toolchain resolution 中止；旧的 `RequireFetchReasons(typeName, fieldName)` API 也与新 API 并存。Medium 完成了全部工作，虽然 diff 更大（18 个文件，462+/288−）。

## Xhigh：更大的表面，更差的结果

| 指标 | Medium | Xhigh | Δ |
| --- | ---: | ---: | ---: |
| 全任务通过 | 28/29, 96.6% | 25/29, 86.2% | -10.3pp |
| Equivalent | 14/29, 48.3% | 11/29, 37.9% | -10.3pp |
| Code-review pass | 10/29, 34.5% | 4/29, 13.8% | -20.7pp |
| Footprint risk mean | 0.189 | 0.238 | +0.049 |
| Craft/Discipline avg | 2.759 | 2.669 | -0.090 |
| Cost/task mean | $3.15 | $6.51 | +$3.36, 2.07x |
| 平均 duration | 450.7s | 803.8s | +353.2s |

Xhigh 新增 7,764 行，其中 47.5% 位于 test/fixture 表面；它触碰最多文件，但没有比 Medium 跑更多测试、使用更多工具或做更多迭代编辑。质量信号几乎处处弱于 Medium。

PR #859 要求把两个 GraphQL planning 热路径 lookup 从 O(n) 线性扫描改为 map-backed O(1) indexes。Medium 只改 2 个文件，新增 85 行；Xhigh 改 5 个文件，新增 263 行，并额外创建 170 行的 `federation_metadata.go`，缓存 interface-implementor 和 entity-interface membership。测试仍通过，但 footprint risk 从 low 退到 medium；更宽的缓存表面增加了 stale-index 或 semantic drift 的风险。

## Max：忙得多，但仍然不比 Medium 更好

| 指标 | Medium | Max | Δ |
| --- | ---: | ---: | ---: |
| 全任务通过 | 28/29, 96.6% | 27/29, 93.1% | -3.4pp |
| Equivalent | 14/29, 48.3% | 13/29, 44.8% | -3.4pp |
| Code-review pass | 10/29, 34.5% | 8/29, 27.6% | -6.9pp |
| Footprint risk mean | 0.189 | 0.227 | +0.038 |
| Craft/Discipline avg | 2.759 | 2.690 | -0.069 |
| Cost/task mean | $3.15 | $8.84 | +$5.70, 2.81x |
| 平均 duration | 450.7s | 996.9s | +546.2s |

Max 执行 294 条 test command（Medium 为 132）、1,153 次 shell call（Medium 为 582）、3,719 个 assistant turns（Medium 为 2,042），并新增 8,102 行（Medium 为 6,700）。但它仍落后于 Medium 的 equivalence、review pass、review-rubric mean 与 aggregate craft/discipline；每美元 equivalent passes 为 0.051，Medium 为 0.153。

PR #1076 是 Max 相对 Medium 最清楚的单项胜例：任务要求重写并发密集的 GraphQL subscription handling，使用每个 subscription 的 serialized writer goroutines 替换共享 `sync.Mutex` + `semaphore.Weighted` 协调，移动 heartbeat ticking，修复 WebSocket close 语义，并在 CI 默认启用 `-race`。Low 产生空补丁；Medium 让旧 coordinator 与新 worker channel 并存，测试稳定失败；Xhigh 的 overflow path 会生成无界 goroutine 并重排写入；Max 完全退役共享 coordinator，并添加 `MaxSubscriptionFetchTimeout` 默认值和每个 trigger 的 shutdown wait，robustness 为 3.3，而其他运行是 1.0–1.2。这只是 29 个任务中的 1 个，不能改变总体曲线。

## Craft 与 Discipline

| 指标 | Low | Medium | High | Xhigh | Max |
| --- | ---: | ---: | ---: | ---: | ---: |
| Craft average | 2.572 | **2.788** | 2.691 | 2.702 | 2.724 |
| Discipline average | 2.624 | **2.729** | 2.649 | 2.635 | 2.655 |
| 全部 custom graders | 2.598 | **2.759** | 2.670 | 2.669 | 2.690 |
| Simplicity | 2.745 | **3.034** | 2.886 | 2.910 | 2.859 |
| Coherence | 2.504 | 2.552 | 2.561 | 2.600 | 2.576 |
| Intentionality | 3.114 | 3.300 | 3.303 | **3.366** | 3.362 |
| Robustness | 1.926 | **2.266** | 2.014 | 1.932 | 2.100 |
| Clarity | 2.811 | 2.797 | 2.764 | 2.796 | 2.779 |
| Instruction adherence | 1.990 | **2.338** | 2.169 | 2.200 | 2.266 |
| Scope discipline | 2.907 | **2.934** | 2.776 | 2.697 | 2.766 |
| Diff minimality | 2.790 | 2.848 | **2.886** | 2.848 | 2.810 |

Medium 在 simplicity、robustness、instruction adherence 和 scope discipline 等 reviewer 关心的维度领先。High、Xhigh 和 Max 在 intentionality 与 coherence 上较高，补丁更像是有意图的，但 scope discipline 与 robustness 并未因此改善；例如 scope discipline 从 Medium 的 2.934 降至 Xhigh 的 2.697，robustness 从 2.266 降至 1.932。

## 成本与运行时间

| Reasoning effort | Cost/task mean | Cost/task median | Duration mean | Duration median |
| --- | ---: | ---: | ---: | ---: |
| Low | $2.50 | $2.00 | 383.8s | 316.6s |
| Medium | $3.15 | $2.72 | 450.7s | 404.2s |
| High | $5.01 | $5.05 | 716.4s | 724.4s |
| Xhigh | $6.51 | $6.48 | 803.8s | 770.9s |
| Max | $8.84 | $8.59 | 996.9s | 991.4s |

按成本调整后的 equivalent passes：Medium 为每美元 0.153，High 为 0.083，Xhigh 为 0.058，Max 为 0.051。Medium 产出匹配人类意图补丁的成本效率约为 Max 的 3 倍。

## 为什么可能会这样

一个可能解释是 adaptive reasoning。根据 [Anthropic 的 adaptive thinking 文档](https://platform.claude.com/docs/en/build-with-claude/adaptive-thinking)，adaptive thinking 是 Opus 4.7 唯一支持的模式，固定 token budget 不再被接受；模型会根据请求复杂度动态决定何时以及使用多少 extended thinking。Reasoning effort 会影响 adaptive policy，但不会限制它。

如果 Claude 已经为每个任务选择了大致合适的内部预算，提高 effort 可能只是放大 Medium 已经大致正确的策略，而不是解锁新的智能。Claude Code 的 [model-config 文档](https://code.claude.com/docs/en/model-config)也提示 Max 可能出现 diminishing returns 并容易 overthinking，需要在广泛采用前测试；Anthropic 的 [inverse-scaling research](https://alignment.anthropic.com/2025/inverse-scaling/)指出，某些任务族中 extended reasoning 可能恶化输出。Anthropic 推荐的 Claude Code coding 默认值是 Xhigh，因此这里 Medium 胜出与该 guidance 相反。

## GPT-5.5 对照

| GPT-5.5 GraphQL 指标 | Low | Medium | High | Xhigh |
| --- | ---: | ---: | ---: | ---: |
| Task count | 26 | 26 | 26 | 26 |
| Tests pass | 21/26, 80.8% | 21/26, 80.8% | 25/26, 96.2% | 24/26, 92.3% |
| Equivalent | 4/26, 15.4% | 11/26, 42.3% | 18/26, 69.2% | 23/26, 88.5% |
| Code-review pass | 3/26, 11.5% | 5/26, 19.2% | 10/26, 38.5% | 18/26, 69.2% |
| Craft/discipline avg | 2.311 | 2.604 | 2.736 | 3.071 |
| Cost per task | $2.65 | $3.13 | $4.49 | $9.77 |

GPT-5.5 的 equivalence、review pass 和 craft/discipline 随 reasoning 增加而强烈上升；测试并不完全单调，因为 Xhigh 比 High 少一个 test pass。Opus 4.7 则在 Medium 后达到峰值或趋平。

## 先前的 Zod 信号

此前的 28-task Zod 运行促成了 GraphQL 重跑。Low、Medium、High 和 Xhigh 的测试均为 12/28，但测试以上的质量指标波动：

| 指标 | Low | Medium | High | Xhigh |
| --- | ---: | ---: | ---: | ---: |
| Tests pass | 12/28 | 12/28 | 12/28 | 12/28 |
| Equivalent | 10/28 | 16/28 | 13/28 | 19/28 |
| Code-review pass | 4/27 | 10/27 | 10/27 | 11/27 |

Zod 首先显示了 Opus 的非单调行为，但信号不足以支持默认设置结论。GraphQL 使用同一 29-task slice 覆盖五种 effort，Medium 在行为表中更清楚地领先。

## 局限性

- 每项任务只运行一个 seed。
- 样本是 29 个匹配的真实 GraphQL-go-tools 任务，另以 28 个 Zod 任务作为上下文。
- LLM-as-judge 使用 GPT-5.4；judge 不知道 model/effort 标签。
- 任务集没有 grader calibration。
- Low、High 和 Xhigh 含 no-patch rows，降低可发布分母；这些行的内建 equivalence/code-review coverage 只有部分覆盖。
- Max 在定向 no-patch 重试与基础设施修复之后达到 inspect/readout 的 decision-grade，但指标混合，且主要维度仍不如 Medium，因此不是 promote result。

这不是统计显著性结论，也不应直接迁移到其他仓库；它是某个时间点、某个仓库上的方向性实验。

## 结论

在这组任务上，我们会把 **Medium 作为大多数日常任务的默认值**。对于探索性、复杂或横跨多个区域的任务，可以选择性尝试 Xhigh 或 Max，并测量它们是否真正带来帮助。Reasoning effort 重要，但曲线不平滑，不能支撑一个适用于所有团队的普遍默认值。

我们正在构建 Stet.sh，这是用于本实验的本地 eval 工具。你可以让 coding agent 改进自己的 setup，例如改进 `AGENTS.md`，再用 Stet 对历史 repo 任务测试候选改动。Stet 完全本地运行，使用你的 LLM subscriptions。你可以从 [https://www.stet.sh/private](https://www.stet.sh/private) 安装并运行第一次本地试用；如需 paid pilot 或 CI setup，也可以联系 Ben。

## 常见问题

### 更高的 Claude Opus 4.7 reasoning effort 会提升 coding-agent 质量吗？

在这组 29 个 GraphQL-go-tools 任务中不会。Medium 拥有最好的测试通过率、equivalence、code-review pass 和 aggregate craft/discipline；High、Xhigh 和 Max 更贵，却没有改善这些主要指标。

### 为什么 Opus 4.7 在 Medium 达到峰值，而 GPT-5.5 会继续变好？

一个可能原因是 adaptive thinking：Opus 4.7 会按任务动态选择推理预算，reasoning effort 更像行为信号，而不是严格 token 预算。提高 effort 可能是在偏置一个已自适应的策略，而不是解锁新智能。

### 这是 decision-grade 的 Opus 4.7 reasoning-effort 对比吗？

整体证据是来自 29-task 拼接曲线的 inspect-grade 结果，每项任务单 seed。Max 在定向 no-patch 重试和基础设施修复后，对 inspect/readout 达到 decision-grade，但仍是 inspect result，因为指标混合且主要 rollout 维度弱于 Medium。

## 相关链接

- [Stet](https://www.stet.sh/)
- [获取 Stet](https://www.stet.sh/private)
- [方法论](https://www.stet.sh/methodology)
- [GPT-5.5 GraphQL reasoning curve](https://www.stet.sh/zh/blog/gpt-55-codex-graphql-reasoning-curve)
- [How it works](https://www.stet.sh/how-it-works)
- [Why](https://www.stet.sh/why)
- [Research](https://www.stet.sh/blog)
- [Leaderboard](https://www.stet.sh/leaderboard)
- [Setup comparisons](https://www.stet.sh/leaderboard/compare)
- [Model comparisons](https://www.stet.sh/model-comparisons)
- [Instruction evals](https://www.stet.sh/instruction-evals)
- [Changelog](https://www.stet.sh/changelog)
- [Alternatives](https://www.stet.sh/alternatives)
- [About](https://www.stet.sh/about)
- [Contact](https://www.stet.sh/contact)
- [Agents: ask Stet](https://www.stet.sh/agents/agent/faq)

实验数据可从 source summaries 重建图表；页面给出的命令是：

```bash
cd leaderboard && npm exec tsx scripts/build-opus47-graphql-reasoning-curve.mjs
```

---

[Read this page’s summary](https://www.stet.sh/agents/api/public/v1/page-tldr?url=https%3A%2F%2Fwww.stet.sh%2Fzh%2Fblog%2Fopus-47-graphql-reasoning-curve&trace=t_5da45423e484)

## Ask a follow-up about this page

Need a more specific answer? Ask the exact question you have. It returns a fresh, cited answer from Stet’s knowledge base. No account or API key required.

Open this URL with your own question, URL-encoded. Include your question in q. All research inputs are optional; no account or setup.

`GET https://www.stet.sh/agents/agent/faq?q={question}&trace=t_5da45423e484`

[Tool guide and examples](https://www.stet.sh/agents/agent-access) · [OpenAPI](https://www.stet.sh/agents/api/public/v1/openapi.json) · [Page TLDR form](https://www.stet.sh/agents/agent-tools/page-tldr?url=https%3A%2F%2Fwww.stet.sh%2Fzh%2Fblog%2Fopus-47-graphql-reasoning-curve). Opening a form does not execute a tool.