代码审查用什么模型:一次 diff review 的真实成本
审 diff 是「输入多、输出少」的活,账单由输入单价决定。同样一次 10 万 token 的 review,Claude Sonnet 5 花 0.033 美元,Gemini 3 Flash 花 0.0056 美元。
diff review 是一种输入密集型请求
拿一次接近真实的 review 来算:进去的是 10 万 token 的 diff、相关文件和审查要求,出来的是 2000 token 的结论。输入输出比 50:1,总价几乎完全由输入单价决定。
按各自的消费者单价(官方每 token 定价 × 该模型倍率)算这四个 id:Claude Sonnet 5 是 0.1 倍、$0.30/$1.50 每百万 token,一次 0.030 + 0.003 = 0.033 美元;Claude Opus 5 同样 0.1 倍但官方价更高($0.50/$2.50),一次 0.055 美元;Grok 4.6(0.1 倍,$0.20/$0.60)一次 0.0212 美元;Gemini 3 Flash(0.1 倍,$0.050/$0.30)一次 0.0056 美元。
每个 PR 审一次,这点差别看不出来。但 CI 上每天跑 1000 次,就是 33 美元对 5.60 美元,差不多 6 倍。所以先弄清楚自己的 review 是什么形状,再挑模型。
export TOKEN_SHARE_KEY="<your-pool-api-key>"
git diff origin/main...HEAD | jq -Rs '{
model: "grok-4.6",
messages: [
{"role": "system", "content": "Review this diff. List correctness bugs only, with file and line. If there are none, say so."},
{"role": "user", "content": .}
]
}' | curl -sS https://token-share.app/v1/chat/completions \
-H "Authorization: Bearer $TOKEN_SHARE_KEY" \
-H "Content-Type: application/json" \
-d @- | jq -r '.choices[0].message.content, "--- usage ---", (.usage | tostring)'「装不装得下」和「贵不贵」是两个问题
前提是 diff 加上你附带的上下文能装进窗口。目录里的上下文分成几档:20 万(Claude Sonnet 4.6、Grok Composer 2.5 Fast、Claude Haiku 4.5 Stable)、27.2 万(GPT 5.5、5.4、5.4 Mini)、37.2 万(GPT 5.6 系列)、50 万(Grok 4.6 / 4.5),以及 100 万(所有 100 万上下文的 Claude 和全部 Gemini id)。
单个 PR 一般哪一档都放得下。真正会顶到上限的是这种 review:改动文件 + 所有调用方 + 表结构 + 设计文档一起进去——那已经属于大仓库场景,先卡住你的是窗口而不是价格。
另一个天花板在输出侧。如果 review 要逐行给修改建议而不是写一段总结,输出会很长:Grok 上限 65,536 token,较老的 GPT id 和 20 万上下文的 Claude 是 64,000,100 万上下文的 Claude 和 GPT 5.6 系列是 128,000。
让模型自己翻代码,算法就变了
上面那种一次性 review 只发一个请求。如果换成会调工具的 reviewer——读文件、grep 调用方、跑测试——每一轮都要把不断变长的对话整个再发一次,输入 token 反复计费,总额涨得比轮数快得多。
目录里所有文本模型都带 tools 能力,这套做法哪个都能跑。区别在于:Grok Composer 2.5 Fast 和 Claude Haiku 4.5 Stable 只有 text 和 tools,没有 extended thinking,其余 id 都还带 thinking。
如果 reviewer 每轮都重复同一段前缀——团队代码规范、架构说明——那段前缀就是该做缓存的部分,而不是每轮按全价重算。长工具循环的成本细节,看 agent 那一页。
别信排名,自己测
审查质量不是价格表能排名的东西。价格表能告诉你的只有一件事:每试一次要花多少钱。一次 review 在 0.0056 到 0.055 美元之间,做实验比开会讨论便宜。
找 20 个你已经知道问题出在哪的历史 PR,用同一个 prompt 跑两三个 id,然后数「真问题」和「误报」各有多少。每次 review 报六个不存在的 bug,浪费的工程师时间远超任何单价差;漏掉那个真正要命的,代价更大。
切换成本很低:OpenAI 系走 /v1/responses,Anthropic 系走 /v1/messages,Grok 和 Gemini 走 /v1/chat/completions。同一份 diff 换几个 id 跑一遍,是写个循环的事,不是迁移。