livenerf：用於檢測 Claude Opus 5.5 發佈後能力衰退的確定性基準

TL;DR – livenerf 的作用與重要性

livenerf 持續對 Claude Opus 5.5（透過 Claude Code Max）運行一組 78 個「有時正確」的問題，並報告其準確率或輸出 token 數相對於發佈首 10 天基線的統計顯著變化。此專案提供了第一個公開、可重現的時間序列，可驗證或否認 Anthropic 在模型發佈後「削弱」其能力的說法。

核心貢獻：確定性、僅追加的漂移檢測器

livenerf 排除了除模型自身隨機性以外的所有非確定性來源。它鎖定 Claude Code CLI 版本，凍結系統提示，使用精確匹配評分器，並記錄每個請求層級的資產（提示、回應、使用量、延遲、測試框架 SHA 等）。透過每日運行相同測試面板 30 天，基準測量每項的配對分數差異，並使用聚類標準誤差，遵循 Anthropic 的《為評估添加誤差棒》（Miller 2024）的統計框架。此設計消除了提示、工具或環境變更所導致的漂移，使任何觀察到的變化皆可歸因於模型或服務堆疊本身。

基準的建構方式

1. 校準以識別有資訊量的項目

僅保留模型「有時正確」（約 50 %–70 % 通過率）的問題。完全正確或完全錯誤的項目無法提供退化資訊。校準階段採樣了 2,336 題 GPQA‑Diamond、MMLU‑Pro、競賽數學與 AIME 2025‑26 問題，每題四次樣本，共產生 78 個測試項目（後續排除兩個）。這些項目在修正選擇偏差後，新樣本通過率為 62 %。

2. 配對每日運行以消除項目難度影響

每天評估相同的測試面板，並將結果與發佈首 10 天中相同項目的基線分數進行比較。由於比較是針對每項進行，難度會相互抵消，主要指標變為各項之間的平均配對差異。

3. 兩臂設計以控制平台效應

主臂：透過 Claude Code Max 使用 Opus 5.5。 對照臂：Claude Opus 5（前一代）運行相同的 GPQA 子集。若兩臂同步移動，則變動歸因於測試框架或基礎設施，而非新模型。

4. 預註冊驗證證明敏感度

在收集基線數據前，系統先執行已知退化（努力程度中對高）與 A/A 檢查。驗證顯示，26 % 的 token 使用量減少對應 –4.2 ± 3.9 分的準確率下降，而 62 % 的 token 減少則導致 –8.3 ± 4.5 分。這證實儀器能檢測真實的努力相關退化。

實驗執行：時間軸與目前狀態（截至 2026‑09‑29）

階段	天數	樣本數	狀態
基線	1–10（發佈 2026‑09‑24）	90 樣本/天	已收集 6 天，無遺漏
第一個 10 天視窗	11–20	–	待處理
第二個 10 天視窗	21–30	–	待處理

所有運行皆使用鎖定的 CLI 版本 2.1.280（雜湊 461391b6fce64167）。第 5 天需一次性的預算保護覆蓋，已記錄於偏差檔案中。

可檢測的效應大小與限制

單日完整面板運行可在 10 天視窗內檢測到約 7.5 分的準確率變化（約為每周計畫統計效能的 3.6 %）。
此儀器無法可靠區分 Opus 5 與 Opus 5.5：觀察到的差異為 –3.8 ± 6.3 分，在 99 % 信賴水平下不具統計顯著性。
token 使用量是更敏感的早期指標；小幅努力減少會在準確率變動前就顯示出明顯的 token 下降。

如何重現此基準

環境 – Python 3.11+、uv，以及登入的 Claude Code Max 訂閱。
鎖定 CLI – 關閉自動更新，記錄 claude --version 至 CLAUDE_CLI_VERSION，並將二進位檔複製至 ~/.local/share/livenerf。
安裝 – git clone https://github.com/ninjahawk/livenerf && cd livenerf && uv sync。
校準與設計 – 執行 python -m livenerf.benchmarks.calibrate …，再執行 python -m livenerf.design … 以產生 data/standard_panel.json 並鎖定測試面板。
驗證 – 執行 python -m livenerf.validate run … 以確認系統能檢測已知的努力退化。
預飛行檢查 – python -m livenerf.preflight --probe 必須輸出 READY 才能排程。
排程 – 將提供的 scripts/daily.sh 加入 cron（Linux/macOS）或工作排程器（Windows），每日執行一次，並遵守每周使用量限制（若超過 75 % 週使用量或 60 % 5 小時使用量則跳過）。
分析 – 每完成一個 10 天視窗後，執行 python -m livenerf.analysis 以取得配對差異、聚類標準誤差，以及自動決策（Δ > 3 分，99 % 信賴區間不包含零，對照臂穩定）。

所有原始日誌均以 Inspect .eval 檔案形式儲存在 logs/ 中（僅追加，永不編輯）。

社群在 Hacker News 上的反應

@jug – 「BridgeBench 的 Nerf Bench 檢測到 Opus 4.6 的退化，Anthropic 後來在部落格中承認了。」

@johnfn – 「大多數『削弱』報告都是感知偏誤；一張圖表解釋了『蜜月效應』——新模型剛上線時感覺無所不能，直到使用者觸及複雜度極限才發現限制。」

@Cider9986 – 「我昨晚在 Claude Code 聊天中看到一次削弱；快速用 Nitter 搜尋，發現同樣的說法。」

@zeroonetwothree – 「如果這個基準無法區分 Opus 5 與 Opus 5.5，那它就沒用。」

@nomilk – 「好主意；它讓服務提供者負起責任，也讓人有點尷尬——竟然需要這種工具。」

這些評論反映出對「削弱」的主觀經驗與對系統性測量可能性的懷疑之間的分歧。livenerf 直接回應後者，提供預註冊、統計嚴謹的協定。

局限與開放問題

模型特定性 – 此基準僅測量透過 Claude Code Max 提供的 Claude Opus 5.5，而非原始 API 模型。在 Azure 或 Bedrock 部署上的結果可能不同。
測試面板隱私 – 個別問題文字保持私密（僅公開雜湊值），以避免洩漏專有評估資料。
檢測上限 – 同家族替換（Opus 5 → 5.5）的變化低於目前統計效能；需更大樣本或更長視窗才能檢測。
外部因素 – 負載相關的服務變更、安全分類器拒絕或配額限流可能影響 token 使用量，並已記錄，但未完全釐清。

未來方向

將協定擴展至其他前沿模型（如 GPT‑6 Astra）及僅 API 部署。
發布公開的合成測試面板，供社群重現，同時保留私密校準項目。
自動化跨提供者比較（Azure、Bedrock），以測試『削弱』是否為特定提供者獨有。
探索更細粒度的 token 使用訊號（如每步思考時間）作為早期警報指標。

如何貢獻

貢獻應僅限新增純函數評分器、合成生成器或分析工具。更改凍結的測試面板或提示會產生新版本，必須搭配新的預註冊提交。所有 PR 必須揭露任何由 LLM 生成的內容，因本倉儲本身部分由 Claude 撰寫。

引用

@misc{livenerf,
  author = {ninjahawk},
  title = {livenerf: tracking post‑launch capability drift in frontier models},
  year = {2026},
  publisher = {GitHub},
  url = {https://github.com/ninjahawk/livenerf}
}

livenerf：用於檢測 Claude Opus 5.5 發佈後能力衰退的確定性基準