Livenerf: Opus 5.5はまだ弱体化されていませんか？

livenerfは、フロンティアモデルがリリース後に静かに悪化しているかどうかを検出するための、長期間にわたる、可能な限り決定論的なベンチマークです。計画・結果・仕組み・事前登録・Discord。 livenerfは、1つの質問に対する小さく、退屈で、追記のみのベンチマークです。モデルは出荷後に悪化するのか？数ヶ月にわたり、Anthropicがモデルをある日または数週間後に「弱体化」させているという報告がありました。それは、量子化、同じ名前のより小さなモデル、労力の低下、またはルーティングの変更を意味する可能性があります。あるいは、何も起こらず、人々がノイズにパターンマッチングしているだけかもしれません。比較するためのクリーンな発売日（Day 0）のベースラインを持っていた人は誰もいないため、すべての議論は「雰囲気対雰囲気」になってしまいます。 Claude Opus 5.5は2026年9月22日にリリースされたため、これは発売日に時計をスタートさせ、それを実行し続ける機会です。現在、v0はヘッドレスClaude Code（claude -p）を介したClaude Maxサブスクリプションで実行されており、APIキーは不要です。これらのモデルを決定論的にすることはできません。サンプリングパラメータは削除され、思考をオフにすることはできません。そのため、livenerfは他のすべてを決定論的にします。固定されたプロンプト、ピン留めされたCLI、正確な評価基準、永遠の生のログです。その後、数千のサンプルにわたって統計的にドリフトを測定します。これは、英国AIセキュリティ研究所のオープンソース評価フレームワークであるInspectに基づいています。統計は、Anthropic自身の「Adding Error Bars to Evals」に従っているため、議論するような自家製のものは何もありません。各日のスコアはLiveNerf Discordに投稿され、そこで結果と方法について議論されます。リポジトリに関する質問は、DiscussionsタブのスレッドまたはIssueを開いてください。 ステータス。シリーズは実行中です。1日目は2026年9月24日22:10 UTCで、発売から約2.5日後でした。1日1回、30日間実行されます。1〜10日目がベースラインで、その後2つの10日間のウィンドウがあるため、最初の可能な呼び出しは約2026年10月24日です。最初の結果行は20日後に表示されます。パネルは、事前登録されたプロトコル（v2）の下で選択、確認、ロック、検証されました。以下のすべての数値は、docs/CALIBRATION.mdのログから生成されています。 進捗（2026-10-03）：30日中10日を収集済み、欠落なし。これによりベースライン（1〜10日目）が完了しました。最初の決定ウィンドウは11日目から始まります。すべての10日間、同じハーシュ（461391b6fce64167）とピン留めされたCLI（2.1.280）でフル90サンプルが実行されました。5日目は、予算ガードが一度オーバーライドされて実行されました（逸脱ログを参照）。 パネル。2,336のGPQA Diamond、MMLU-Pro、competition-math、AIME 2025–26の質問がそれぞれ4サンプルでスクリーニングされました。Opus 5.5は、最初の試行で約93％を正しく回答し、質問の97％は常に正解または常に不正解でした。78の質問は時々正解であり、それらがパネルを形成します（docs/DESIGN.md）。選択バイアス、測定済み。「時々正解」として選ばれた質問は、実際よりも50/50に近いように見えます。新しいサンプルでは、正解率は54.7％から62.0％に上昇したため、パワー計算では新しいレートを使用します。 検出できること。パネル全体の1日1回の実行で、10日間のウィンドウあたり約7.5ポイントの精度変化を検出できます。これは週次計画の約3.6％に相当します。検証（docs/VALIDATION.md）は、事前登録された基準をパスしました。労力の低下は、精度よりもトークン数にずっと明確に現れます。労力低下：出力トークン-62％、精度-8.3 ± 4.5ポイント。労力中程度：トークン-26％、精度-4.2 ± 3.9ポイント。 限界。Opus 5への切り替えは、99％（-3.8 ± 6.3ポイント、トークン-23％）ではOpus 5.5と区別できませんでした。このインストゥルメントは、そのサイズの同ファミリーモデルの切り替えを、検証期間のサンプル数では検出できません。10日間のウィンドウは約2.5倍のサンプル数がありますが、それが十分であるとは示されていません。 質問自体。78の質問と、その後除外された2つの質問のレポートのみの監査により、間違っていると思われる回答キーが8つ、曖昧な質問が30個見つかりました。これは、強力なモデルが時々しか「正解」できない質問に期待されることです。何も削除されませんでした。事前登録された感度分析では、それらを除外して結果を再実行します。 サービングパス。安全分類器は、Opus 5で回答したり、生物学や一部の数学の質問を拒否したりすることがあります。それらのサンプルは拒否されカウントされ、それが触れた質問は除外されます。 結果。このリポジトリが主に維持するのは、キャリブレーションされたベンチマークパネルでのOpus 5.5の性能が発売週のベースラインと比較してどうであるかの、継続的な10日間のテーブルです。マイナスのデルタは、発売週よりも悪いことを意味します。テーブルは、後退と同様に改善も大きく報告します。 # ウィンドウ サンプル スコア Δ vs baseline ± SE 出力トークン（中央値） コントロール Δ CLI 決定 0 日 1–10（2026-09-24から） - - ベースライン - ベースライン ピン留め ベースライン（収集中） 主要なメトリックは、キャリブレーションされたパネルに対するアイテムごとのペア化されたスコア差であり、クラスター化標準誤差を使用するため、アイテムの難易度は除外されます。PREREGISTRATION.mdを参照してください。私が最も気にかけている二次信号は、サンプルあたりの出力トークン数です。モデルが静かに思考を減らし始めると、これが最初に現れます。精度が動く前にしばしば現れます。 開始方法。 セットアップ。Python 3.11+、uv、およびログイン済みのClaude Codeインストールが必要です。v0はMaxサブスクリプションを中心に構築されましたが、claude -pを実行できるものであれば何でも機能します。Linux、macOS、Windowsはすべてサポートされています。 git clone https://github.com/ninjahawk/livenerf cd livenerf uv sync これにより、ピン留めされたInspectがインストールされ、claudecodeモデルプロバイダーが登録されます。プロバイダーは、ハーメチックなclaude -p呼び出しをラップするため、InspectはMaxサブスクリプションを他のAPIと同様に扱います。 CLIをピン留めします。これはオプションではありません。Claude Codeのアップデートはハーネスを変更し、変更されたハーネスは変更されたモデルとまったく同じように見えます。自動アップデートをオフにし、ピン留めするバージョンを書き留めます。 export DISABLE_AUTOUPDATER=1 # ~/.claude/settings.jsonにも追加します "env" claude --version | awk '{print $1}' > CLAUDE_CLI_VERSION ランナーは、claude --versionがそのファイルと一致しなくなった場合に実行を拒否します。Claude Codeは自分で更新することもできるため、ピン留めされたバイナリのコピーを、アップデーターがアクセスできない場所に保管してください。 livenerfはそれを自動的に使用します（またはLIVENERF_CLAUDE_CLIを任意のパスに設定します）。 mkdir -p ~/.local/share/livenerf cp ~/.local/share/claude/versions/$(cat CLAUDE_CLI_VERSION) ~/.local/share/livenerf/claude-$(cat CLAUDE_CLI_VERSION) # Windows：コピーの名前をclaude-<version>.exeにします。 プランにおける予算。Maxプランはトークン数を公開していません。livenerfは、ローカルのClaude Codeログイン（読み取り専用リクエスト）を使用して、/usageが表示するのと同じパーセンテージメーターを読み取ります。 python -m livenerf.usage # {"five_hour": 14.0, "weekly": 12.0, ...} 以下のすべての予算は、週次メーターのポイントで表されるため、ベンチマークはプランの固定シェアを占め、通常の利用と競合することはありません。 1. キャリブレーション、2. デザイン、3. 検証。 python -m livenerf.benchmarks.calibrate run --weekly-points 12 # 再開可能。予算で停止します。 python -m livenerf.design --max-weekly-points 10 --write # パネル、スケジュール、MDE python -m livenerf.design --max-weekly-points 10 --lock # フリーズします。日次ランナーは変更されたパネルを拒否します。 python -m livenerf.validate run --weekly-points 8 # ポジティブコントロール + A/Aチェック。 python -m livenerf.validate report キャリブレーションサンプルは、モデルが時々見逃す候補質問を見つけるために、各候補質問をサンプリングします。デザインは、そのような質問すべてをパネルに入れ、新しい確認サンプルから日次スケジュールの最小検出可能効果を予測し、docs/DESIGN.mdを記述します。検証は、結果が信頼される前に、リグが既知の劣化を検出できることを証明します。docs/VALIDATION.mdを記述します。 コミット、その後収集。デザインと事前登録をコミットし、プッシュしてから、最初のシリーズを実行します。公開Gitタイムスタンプが、事前登録に意味を与えます。次に、すべてが配置されていることを確認します。CLIピン、メーター、ロックされたパネル、パスした検証、クリーンにプッシュされたツリー、およびライブハーメティシティプローブ。 python -m livenerf.preflight --probe # READYまたは失敗したチェックを出力します。 その後、時計をスタートさせます。パネル全体は30日間、1日1回実行され、さらにコントロールアームが追加されます。週次メーターが75％以上、または5時間メーターが60％以上の場合、試行はスキップされます。