Claude Opus 5 開發者基準與路由清單
這篇教你先做基準測試，再用成本與延遲決定何時把 Claude Opus 5 用在難題上。
97%+ 的 HumanEval 表現，仍需要用成本路由把簡單工作分給更便宜的模型。
這篇給要評估 Claude Opus 5 的開發者看，目標是把「值不值得用」變成可重複的測試流程。照做完，你會拿到一份可比對的 benchmark 清單、一張自己的成本表，以及一條清楚的模型路由規則。
你也會知道它最適合放在什麼地方：高難度程式題、延伸推理、以及需要長時間思考的 agent 工作。本文資料來自 Anthropic 的 Claude docs 與 Anthropic SDK repo，並參考官方與社群整理的 benchmark 結果。
開始之前
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
- Anthropic 帳號，且已開通 API 存取
- Claude Opus 5 API key
- Node.js 20+ 或 Python 3.11+
- 一份可安全測試的程式碼庫或題目集
- 預算可支應 premium 模型呼叫，尤其是啟用 extended thinking 時
- 可選：OpenAI 與 Google API key，用來做對照測試
Step 1: 釘住基準題集
目的：先做出一份和你日常工作一致的測試集，後面所有模型都用同一批題目比。請挑 20 到 50 題，涵蓋 bug 修正、code review、重構、架構判斷，並固定題目內容不變。
export BENCHMARK_SET=benchmarks/dev-workload.json
export MODEL=claude-opus-5驗收：你應該看到一份固定的 prompt 清單，並且每題都有分類與預期輸出。如果每次執行題目都不同，結果就不能比較。
Step 2: 跑出便宜模型基線
目的：先取得 Sonnet 4、GPT-4.1 這類較便宜模型的基準分數，作為品質、延遲與 token 成本的參考。所有模型都要用相同 prompt、temperature 與輸出格式。
curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-d '{"model":"claude-sonnet-4","max_tokens":1024,"messages":[{"role":"user","content":"Review this diff for logic bugs"}]}'驗收：你應該看到完整回應，外加 API metadata 裡的 token 使用量。把這份輸出存起來，後面才能和 Opus 5 做同題對照。
Step 3: 測 Opus 5 難題表現
目的：只在真正需要深度推理的題目上看 Opus 5 是否有優勢，例如多步驟除錯、跨檔案分析、或工具使用。官方與社群 benchmark 常把它放在 SWE-bench Verified、LiveCodeBench、GPQA 類型任務上觀察。
{
"model": "claude-opus-5",
"thinking": {"type": "enabled", "budget_tokens": 4096},
"max_tokens": 1024,
"messages": [
{"role": "user", "content": "Explain why this distributed job sometimes double-runs"}
]
}驗收：你應該看到更完整的推理內容，而且通常會比非 thinking 執行更慢。如果在最難的題目上沒有明顯進步，代表 premium 成本不一定划算。
Step 4: 記錄延遲與 token 成本
目的：把「好不好」換成「每題花多少錢、花多久」。官方資料提到 Opus 5 的價格是每 100 萬 input tokens 15 美元、每 100 萬 output tokens 75 美元，context window 為 200K；非正式測試中，time-to-first-token 約比 Sonnet 4 慢 2 到 4 倍。
請量測每次呼叫的 input tokens、output tokens、time to first token 與總 wall time，然後改用「每個任務的成本」比較，而不是只看每百萬 tokens 的單價。這樣你才知道真實工作流裡的花費。
驗收：你應該看到一張可對照的成本表。若一般題目上差距很小，就把這些請求分流到更便宜的模型。
Step 5: 寫出路由規則
目的：把測試結果變成可上線的模型選擇策略。高難度推理、資安審查、複雜重構交給 Opus 5；autocomplete、短程生成、高量批次任務交給 Sonnet 4 或 Haiku。
if task in {"deep_debug", "architecture_review", "security_analysis"}:
model = "claude-opus-5"
else:
model = "claude-sonnet-4"驗收：你應該看到整體花費下降，而且常見工作不會明顯掉品質。若路由正確，只有最難的 prompt 會打到 Opus 5。
Step 6: 驗證 context 上限
目的：確認你的工作負載是否真的適合 200K context window。Opus 5 的上下文對多數檔案級或模組級任務已足夠，但比起 1M window 的 GPT-4.1 與 Gemini 2.5 Pro，超大倉庫分析更可能需要 retrieval 或 chunking。
請測一個低於 100K tokens 的 prompt，再測一個接近上限的 prompt，觀察答案是否開始漏細節。不要直接假設 200K 在所有位置都表現一致。
驗收：你應該看到小 prompt 的回答更穩定，大 prompt 較容易出現漂移。如果模型開始忽略前段資訊，就改成 retrieval-augmented workflow。
| 指標 | 基準／優化前 | 結果／優化後 |
|---|---|---|
| HumanEval pass@1 | 多數前沿模型落在高 90% | Opus 5 約 97%+ |
| 延遲 | Sonnet 4 作為基線 | Opus 5 約慢 2 到 4 倍 |
| Input pricing | Sonnet 4 每 100 萬 tokens 3 美元 | Opus 5 每 100 萬 tokens 15 美元 |
| Context window | GPT-4.1 與 Gemini 2.5 Pro 為 1M | Opus 5 為 200K |
常見錯誤
- 把 Opus 5 用在每一個請求。修法：先把例行生成與 autocomplete 分流到便宜模型，再保留 Opus 5 給難題與審查。
- 用不同 prompt 或不同 temperature 比模型。修法：先鎖定 benchmark 題集、sampling 參數與輸出格式，再開始測。
- 只看 input 成本，忽略 output 成本。修法：同時追蹤 input 與 output usage，因為 Opus 5 的輸出單價明顯更高。
接下來可以看什麼
等你的 routing 與 benchmark harness 建好後，可以把同一套方法套到其他 frontier model，並加上 latency、cost、answer quality 的 regression check，讓升級流程變成可重複的工程步驟。