Coding Agent 选型图谱

场景：大型 existing repo，多文件、架构敏感、长程 coding。本页把 GPT-6 Astra、GPT-5.6 Sol、Claude Fable 5.1、Opus 5 等模型的 benchmark、effort 扩展、订阅额度、单位成本和 prompt cache 行为放在同一套图里。每张图都标了证据等级，官方数、社区估算和派生值不会被混成同一种可信度。

快照 2026-09-21·32 个来源·6 个模型·约 30 张原始表 → 20 张图

74.1%DeepSWE 峰值 · Astra xhigh

50.0%SWE-Marathon 最高 · Opus 5

$0.0185最低 $/task · Sol @ Pro 20x

≈3.5×Fable 5.1 比 Opus 5 贵（每 task）

0%Codex 切 effort 后首请求 cache hit

结论速览

短 benchmark 的排名到了多小时任务就不成立了。OpenAI 官方表里 Astra 在 8 项中 5 项领先，但在 SWE-Marathon（20 个多小时真实任务，binary reward）上 Opus 5 = 50.0% > Fable 5.1 = 45.6% > Astra = Sol = 42.5%。图 1 · 图 8
Effort 收益多数在 medium–high 就饱和了。DeepSWE 上 Astra 在 xhigh 见顶，max 成本 ×1.9，pass 反而掉 0.9pp。Opus 5 从 high 到 max，passed 一直是 327；pass@1 那 +0.8pp 是 attempts 从 449 降到 444 带来的分母效应。例外是 Terminal-Bench 4.0：Sol 从 xhigh 到 max 还能再涨 15pp。图 4 · 图 6
买哪一档：OpenAI 选 20x，Claude 选 Max 5x。按 Electricity Bench 口径，Pro 20x 的 $/task 约为 Pro 5x 的一半；Claude Max 20x 与 Max 5x 几乎一样（Opus 5：$0.0486 对 $0.0481）。官方写的「20×」是 per-session 容量；实测的 Max 20x 周吞吐只是 Max 5x 的约 2×（Max 5x 为估算值）。图 11
在 Claude Code 里切 effort，cache 能保住的只有一种情况。必须同时满足 Fable 5.1 + v2.1.260+ + 订阅或 API key，且不走 Bedrock、Google、apps gateway、HIPAA 或 betas-off。Opus 5 的 /effort 和 /model 都会 full miss。据用户本地 telemetry，Codex CLI 目前切 effort 后首个请求的 cache hit 只剩 0–12%。图 17
Plan mode 本身不伤 cache，伤 cache 的是 effort 切换。Claude Code 普通 Plan 不改 effort，cache 保持。Codex 在 plan_mode_reasoning_effort 未设置时 Plan 用 medium，默认 high 的用户进出 Plan 各切一次 effort。把两者设成一样就能避免。图 15

读图须知

下面这组徽章贯穿全页，看到数字时先看它属于哪一类来源。

官方
OpenAI / Anthropic 官方公布的 benchmark、产品限制或文档

厂商私有
厂商内部 eval，或厂商转述的客户 eval / 案例

公开 benchmark
独立公开的 benchmark / leaderboard

第三方实测
第三方用实际账号 / usage meter 测量

社区估算
社区从 usage meter、token log 或官方倍率反推

派生
根据表中数据计算，不是原始 benchmark

口径不同，不能直接比。FrontierCode 是 weighted rubric score，不是 pass rate。OpenAI 官方表对每个模型取「任意 effort 下的最佳成绩」，不能拿来推 effort scaling 1。

订阅 $/token 是反推值，不是厂商公布的 quota。Claude 和 OpenAI 的 quota token 加权方式不同，跨厂商的 raw $/MTok 不是 apples-to-apples。

月份换算有两套：订阅 task 用 $ \text{tasks/month} = \text{tasks/week} \times 52 / 12 $；社区 token 估算（Real API Pricing）用 1 month = 4 weeks。两者相差约 8%，跨图比较时要记住。

能力 · 厂商 benchmark

图 1 · 9 项 benchmark × 6 个模型官方厂商私有派生

每行一项 benchmark，灰色粗条是最低分到最高分的范围，右侧数字是极差：极差越大，这项 benchmark 越能区分模型。点击模型可以单独高亮它。

DeepSWE 极差只有 6.7pp，6 个模型几乎挤在一起；Terminal-Bench Science 极差 43.2pp，Astra 64.6 对 Fable 5 的 21.4。FrontierCode Extended 原表把 Astra 64.5 加粗，但 Fable 5 的 64.9 更高。「4 项均值」混了不同口径，只能当 proxy；其中 Fable 5 和 Gemini 两个点是本页按同一公式补算的（空心）。来源 1 2

数据表

图 2 · 同一个 benchmark，两家厂商报的数不一样官方

两家官方表都给出分数的有 12 组（benchmark × 模型）。条形表示 Anthropic 报的值减去 OpenAI 报的值。

12 组里 6 组完全一致，6 组有差异，最大的是 Fable 5 在 TB Science 上差 3.3pp。偏差方向不固定：OpenAI 报的 Fable 5 在 TB Science 上更低，在 TB 4.0 上反而更高。更可能的原因是 harness 或 effort 选取不同，没看出系统性偏袒。来源 1 2

图 3 · 厂商转述的客户 eval / 案例厂商私有

方块表示证据强度：3 格 = 有公开数字，2 格 = 只有相对比较，1 格 = 定性案例。

Browserbase 浏览器 agent

最难一档 · 约 10 min/task

来源 2

CursorBench 3.2 · SpaceXAI

内部复跑 · coding

Fable 5.1 max：73.4%

与 Anthropic 官方表中 CursorBench 3.2.0 的数值相同

来源 2

Jane Street 内部 coding

内部 coding 题集 · 无数字

Fable 5.1 解出的题比 Fable 5 和 Opus 5 都多

来源 2

Lovable 内部 eval

product-building agent · 无确切分数

Astra low → medium → high：effort 越高，fresh-build 迭代、浏览器验证和代码执行越多

来源 3

MongoDB 原型

服务代码 + 文档 + 原型

Fable 5.1：总计约 3 天，其中有数小时是无人值守的实现

来源 2

Millennium 罕见 crash

反汇编 + core dump + vendor library

Fable 5.1 据报是第一个定位出这个多年未解罕见 crash 的模型

来源 2

Effort 扩展

图 4 · DeepSWE v1.1：多花的钱换来多少分公开 benchmark

横轴

纵轴

把纵轴切到「passed 题数」：Opus 5 从 high 到 max 一直是 327 题，成本从 $6.08 涨到 $11.84，pass@1 的上升只是因为 attempts 从 449 降到 444。Astra 在 xhigh 达到 335 题，max 退回 331 题，成本却 ×1.9。按步数看，Opus 5 max 每题要 99 步，Astra 约 29 步，两者的工作风格差别很大。另外，OpenAI 官方表里 Opus 5 的 DeepSWE 是 73.7，这里 max 是 73.6。来源 4

图 5 · 每升一档 effort 的边际收益派生

条长 = Δpass@1（pp），文字 = 这一档的成本倍率。

low → medium 是唯一明显划算的一档（Astra +5.8pp、Opus 5 +10.8pp，成本都约 ×2）。之后每档收益 < 1pp，Opus 5 medium → high 例外（+3.9pp）。Astra xhigh → max 是负收益。来源 4

图 6 · 独立 effort sweep（Unifybench 聚合）公开 benchmark

小倍数图，每个面板的 y 轴各自独立（不从 0 开始），大点是该模型的峰值 effort。

Terminal-Bench 4.0 · mini-SWE-agent 2.4.6 · 66 tasks × 3

Terminal-Bench 2.1 · Artificial Analysis

FrontierCode 1.1 Main · Codex · 100 tasks

FrontierCode 1.1 Extended · 150 tasks

TB 4.0 对 effort 极其敏感：Sol 从 low 1.01% 到 max 39.90%，差约 40 倍。TB 2.1 在 medium 之后就平了。Opus 5 在 FrontierCode Extended 上不是单调的，medium 63.63 最高，max 只有 58.94。OpenAI 官方表里 Opus 5 FC Ext 的 63.6 其实就是这个 medium 峰值，印证了「取任意 effort 最佳」的口径。来源 5 6 7

图 7 · 哪些 effort 数据真的存在公开 benchmark官方

按行归一的数值热度，深色格 = 该行峰值 effort。斜纹 = 只发布了曲线图，没有数字；虚线 = 有 run 但聚合数字未公开或覆盖不全。

低中高行内峰值只有曲线图有 run / 未公开— 无数据

9 条有完整数字的曲线里 6 条在 max 见顶，但 max 相对 xhigh 的增益多数 ≤ 2.6pp，只有 TB 4.0 · Sol 是 +15pp。另外 3 条的峰值在 xhigh（DeepSWE · Astra、TB 2.1 · Sol）或 medium（FC Ext · Opus 5）。Anthropic 对 Fable 5.1 / Fable 5 画了每档 effort 的 score/cost 曲线，但文中没给数值。SWE-Marathon 能直接取到的只有 max 的 headline 数字，缺的点本页不做补全。来源 2 4 8

长程 · SWE-Marathon v1.1

这是和「大型 existing repo · 长程」场景最接近的公开 benchmark。每个任务要跑几个小时，所有 verifier test 全过才算成功。

20个多小时 SWE 任务

k=8每任务 trials

78M平均 tokens / trial

7,650logged trials

897 GBagent logs

Kubernetes-in-RustC compilerJava LSPNext.js replacementSlack / Excel / S3 / Mastodon / Stripe clonesML post-trainingTriton kernel

图 8 · resolved pass@1（max effort）公开 benchmark

排序和图 1 不同：OpenAI 官方表里领先的 Astra，在这里和 Sol 并列最后（42.5%）；Opus 5 在官方表里多排第 2–3 名，这里第一。Harness 不同：Claude 系跑 Claude Code，GPT 系跑 Codex。每条 trial 平均 78M tokens，远超任何单次 context 窗口，所以 cache 与 compaction 行为（见下文）对这类任务的成本影响很大。来源 8

订阅额度

图 9 · 三档价格，两家官方写的倍率官方

条长 = 官方容量倍率（满格 20×）。两家都不公布绝对 token quota，都有 weekly cap。

OpenAI · ChatGPT

$20

Plus

baseline · 含 Codex / Work

$100

Pro 5x

5× Plus Codex · 每 $ 容量 1×

$200

Pro 20x

20× Plus Codex · 每 $ 容量 2×

Anthropic · Claude

$20

Pro

baseline · interactive Claude Code

Fable 5.1：不含于额度 · 一开始就走 usage credits

Opus 5 ✓非交互 credit $20

$100

Max 5x

5× Pro per-session 容量

周额度池 · Fable 最多用 50%，与其他模型共用这一个池，且消耗更快

Opus 5 ✓非交互 credit $100

$200

Max 20x

20× Pro per-session 容量 · 每 $ 容量 2×

同上，Fable 上限 50%

Opus 5 ✓非交互 credit $200

「非交互 credit」自 2026-06-15 起生效，覆盖 Claude Agent SDK 与 claude -p，与交互式 Claude Code 额度分开计算，不占后者 15。Fable 5.1 需要 Claude Code 2.1.255+ 14。推论：Pro 用户跑 Fable 5.1 走的是 usage credits，而 usage credits 下主对话的 cache TTL 只有 5 min（见图 20），不是 1 h。来源 9 10 11 13

图 10 · Codex 每 5 小时本地消息数（官方区间）官方

浮动条表示区间的最小值到最大值，横轴为对数刻度。Weekly cap 另外叠加生效。

四个模型之间是固定倍率：Astra 的消息数是 Sol 的 1/2、Terra 的约 1/4、Luna 的 1/50。三档套餐之间严格 1× / 5× / 20×。来源 12

单位成本

图 11 · Electricity Bench W38：订阅吞吐与 $/task 第三方实测派生

视图

实心 = 实测空心 = 估算

两家的曲线形状不一样。OpenAI：Pro 5x → Pro 20x 的 $/task 减半（Astra $0.0721 → $0.0355）。Claude：Pro → Max 5x 减半，Max 5x → Max 20x 基本持平（Opus 5 $0.0481 → $0.0486，Fable 5.1 $0.1648 → $0.1709）。注意每家只有一档是实测的（OpenAI 实测 Pro 5x，Claude 实测 Max 20x），其余点由倍率推出。统一用 medium effort，19 个真实代码库任务，1 task = 一次完整的多轮 agent session。来源 16 17

Electricity Bench 方法学

19 个真实代码库任务：real-world issues + spec planning 1 task = 完整多轮 agent session，不是一条消息 OpenAI 实测档：ChatGPT Pro 5x Claude 实测档：Claude Max 20x 全部 effort = medium Claude Max 20x 每周约等于 7 个用满的 5h 窗口 quota 百分比不可跨厂商比较

图 12 · 两种算法得出的单位成本：$/MTok 对 $/task 社区估算第三方实测

每个点 = 套餐 × 模型，双对数坐标。空心 = 社区标注 low confidence。灰色 × = Pro 20x · Astra 的旧版图表值。

按 token 算，Opus 5 最便宜（约 $0.011–0.013/MTok，最左侧）；按 task 算，它落在中游（约 $0.048）。每个 Claude task 消耗的 token 明显更多，而且两家的 quota 加权本来就不同，所以这里看排序，不要算比值。Fable 5.1 两个维度都偏贵。 Real API Pricing 数据集更新很快：Pro 20x · Astra 从旧值 4.808B tokens / $0.0416 改成了 3.812B / $0.05247，发布前应重新拉取 data/adopted.csv。来源 18 19 20

社区 token 估算方法学

month = 4 周饱和使用需要换算时的标准负载：97.5% cache read / 2.15% fresh input / 0.35% output 直接测到的总 token 不再重新归一同一套餐下不同模型的额度是二选一，不能相加 社区估算，不是厂商 quota 保证跨厂商只能近似比较

图 13 · 单次成功成本：$100 档 → $200 档派生

○ = $100 档（Pro 5x / Max 5x），● = $200 档（Pro 20x / Max 20x）。点越靠左，单次成功越便宜。

两个公式： \[ C_{\text{index}} = \frac{\text{USD/task}}{\text{coding_index}/100} \qquad C_{\text{DB}} = \frac{\text{USD/task}}{p_{\text{pass}}} \] 后者假设每次重试相互独立，没有计入人工清理、仓库状态被破坏和延迟，也不是正式的成功概率。两张面板结论一样：OpenAI 从 $100 升到 $200 档，单次成功成本约减半；Claude 基本不动，Fable 5.1 甚至略升。Opus 5 没有官方 DB-migration 分数。

Effort 控制与 Plan mode

图 14 · 各环境支持的 effort 与默认值官方

红色 pill = 默认 effort，虚线 pill = 可被 Plan override 覆盖。

有两个「默认值」容易被忽略：Codex 当前 bundled models.json 里 Astra 的默认是 low；Plan preset 在未设置时是 medium。Claude 系 API 与 Claude Code 默认都是 high。来源 21 22 23 24 25

图 15 · 进出 Plan mode 时 effort / 模型 / cache 怎么变官方派生

每行是一个配置：普通 → Plan → 普通。红字 = 该阶段 effort 或模型变了；圆点 = 边界上的 cache 结果。

✓ 保持✗ 失效! 有风险（CLI bug）? 视情况

Codex 行是按官方 preset 源码和 open bug 推出来的 23 28 30；Claude Code 行出自官方文档 25。Codex 「Plan=high」那一行只说明没有 effort 引起的 reset，Plan mode prompt 本身带来的其他影响没有量化。

如果想在 Codex 里去掉 Plan 边界上的 effort 切换，把 Plan effort 设成和默认一样：

# ~/.codex/config.toml
model_reasoning_effort     = "high"
plan_mode_reasoning_effort = "high"   # 未设置时 Plan preset = medium；"none" 表示不推理，不是继承

Prompt cache

图 16 · 能否动态切 effort 而不丢 cache：API ≠ CLI 官方

三个模型在 API 层都支持保 cache 地切 effort，但官方 CLI 的实现各不相同。Opus 5 的 API 能做到，Claude Code 目前却把它的 /effort 当作 cache 失效操作。来源 24 25 26 28

flowchart TD
  Q{"Switch effort where?"}
  Q -->|"OpenAI API"| OA{"How?"}
  OA -->|"configuration_update"| K1["cache kept"]
  OA -->|"edit reasoning.effort"| M1["cache miss"]
  Q -->|"Codex CLI"| CX["not reliable yet"]
  Q -->|"Claude API"| CA{"How?"}
  CA -->|"per-message + beta"| K2["cache kept"]
  CA -->|"top-level effort"| M2["cache miss"]
  Q -->|"Claude Code"| CC{"Model?"}
  CC -->|"Opus 5"| M3["full miss"]
  CC -->|"Fable 5.1"| V{"v2.1.260+?"}
  V -->|"no"| M4["full miss"]
  V -->|"yes"| P{"Billing path?"}
  P -->|"Bedrock / Google / gateway"| M5["full miss"]
  P -->|"sub or API key"| H{"HIPAA or betas off?"}
  H -->|"yes"| M6["full miss"]
  H -->|"no"| K3["cache kept"]
  classDef keep fill:#554037,stroke:#554037,color:#F7EBE1
  classDef miss fill:#B13254,stroke:#B13254,color:#F7EBE1
  classDef risk fill:#F7EBE1,stroke:#B13254,color:#B13254,stroke-dasharray:4 3
  class K1,K2,K3 keep
  class M1,M2,M3,M4,M5,M6 miss
  class CX risk

图 17 · 「我切 effort，cache 会丢吗？」决策树，覆盖 effort_switch_cache_matrix 的全部 14 行。Codex CLI 的问题见 open issue #42996：CLI 没有把切换走可信的 configuration_update 路径。Claude API 的 per-message effort 需要 beta header mid-conversation-output-config-2026-07-01；改 top-level output_config.effort 会改变渲染后的 prompt，cache 从头来。来源 24 25 26 27 28

图 18 · Codex 切 effort 时的 cache hit 变化（用户本地 telemetry）用户报告

三条线都是 V 形：切换后的首个请求掉到 0–12%，下一个请求就回到 96–99.7%。同一 session 主任务的总体 cache hit 仍有 98.32%，说明这是切换点上的一次性损失，cache 没有持续崩掉。但按图 20 的价格，每次 V 形底部都要按全价重写整个前缀。来源 29（Windows 0.153.4）

图 19 · Claude Code 操作 → cache 结果官方

20 个操作中 12 个保持 cache。真正会整段失效的只有两类：换模型（/model、opusplan、指定了其他模型的 skill）和改前缀（effort、已载入前缀的 MCP tools）。编辑 CLAUDE.md 不会破坏 cache，但改动要到 /clear、/compact 或重启后才生效。来源 25

图 20 · Claude Code 默认 cache TTL 官方

主对话subagents / workflows

Claude 订阅（plan 额度内）

1 hour

5 min（部分 Anthropic 内置 helper 为 1h）

usage credits

5 min

API key

5 min

cloud provider

5 min 默认（各 provider 支持不同）

5 min

从 Claude Code v2.1.242 起两者都可配置：

{
  "promptCacheTtl": "1h",          // "5m" | "1h"
  "subagentPromptCacheTtl": "1h"   // "5m" | "1h"
}

来源 25

图 21 · 一次 cache miss 要多花多少钱官方计算器 = 派生

100k token 前缀：重写一次的价格对读一次的价格（官方示例）。

Fable 5.1 · 重写

~$1.25

Fable 5.1 · 读

~$0.03 → 重写约是读的 50×

Opus 5 · 重写

~$0.63

Opus 5 · 读

~$0.05 → 12.5×

价格倍率（相对 base input）：5 分钟 write 1.25×（Fable 5.1 $12.50/MTok）· 1 小时 write 2.00×（$20.00/MTok）· 普通 read 0.10× · Fable 5.1 read 0.025×（$0.25/MTok）。Fable 的 read 特别便宜，所以对它来说 miss 的相对代价最大。Anthropic 自己的 triage agent 就遇到过：一次 effort 变更加上新增一个 tool，重写了 39k + 60k cached tokens，整个 session 成本约 $0.95 31 32。

计算器：你的 session 因 cache miss 多花了多少

模型

写入 TTL

前缀大小 100k tokens

每 session cache miss 次数 3

\[ \Delta C = n \cdot \frac{T}{10^6} \cdot P_{\text{base}} \cdot (m_{\text{write}} - m_{\text{read}}) \] Fable 5.1 的 base $10/MTok 由官方 1.25× = $12.50 得出。Opus 5 的 base 按官方示例（100k 重写约 $0.63、读约 $0.05）反推约为 $5/MTok，是估计值。计算器只算前缀重写，不含 output 和 fresh input。

来源

源数据标注：Real API Pricing 的数值变化很快，引用前要重新拉取；SWE-Marathon 的跨 effort 聚合数字没有公开，本页不做补全。