「コーディングにはどのモデルを使うべきか」という問いの答えは、たいてい勘です。私は線を探したかった。安いモデル（Claude Haiku 5.5）が初めて遅れを取る点、つまりSonnetやOpusにお金を払うべき点です。
そこでWindowsノートPC1台で、コーディングエージェント5つを163回実行しました。課題は段階ごとに難しくなり、結果はすべて隠しテストで採点しました。
エージェント： Claude Code（Haiku 5.5、Sonnet 5.5、Opus 5.5）、Codex（gpt-6-luna）、GoogleのAntigravity CLI（Gemini 4 Argon）。すべてeffort medium、毎回空のフォルダから開始。
段階
| 段階 | 課題 | 隠しチェック |
|---|---|---|
| L2 | 5レベル、一時停止、レベルスキップ、進行保存付きブロック崩し | 9 |
| L3 | CSVモジュールと集計モジュールを持つ複数ファイルの家計簿 | 12 |
| L4 | モジュール5つ、画面3つ、予算、レポート、50段階のUndo付き家計簿 | 23 |
| L5A | 既存の1,032行のアプリにバグ6つ（症状だけ伝える）＋機能3つ追加 | 38 |
| L5B | スプレッドシートエンジン：演算順序、関数、循環参照検出、$絶対参照コピー、Undo | 38 |
| L6 | Markdownパーサーmarkedで2026年9〜10月に実際に修正されたバグ3つ | 本家修正のテスト＋全スペック |
L6は本家の修正直前のコードから始め、ユーザー風のバグ報告だけを渡しました。採点はメンテナーが修正と一緒に追加したテストとmarkedの全スペック（約1,900件）で行い、モデルが変更したsrc/だけを戻すので、テストを書き換えても点にはなりません。
L2〜L5：線はなかった
| エージェント | L2 | L3 | L4 | L5A | L5B |
|---|---|---|---|---|---|
| Haiku 5.5 | 5/5 | 5/5 | 5/5 | 4/4 | 2/2 |
| Sonnet 5.5 | 5/5 | 5/5 | 5/5 | 4/4 | 2/2 |
| Opus 5.5 | 5/5 | 5/5 | 5/5 | 4/4 | 2/2 |
| Codex | 5/5 | 4/5 | 4/5 | 3/4 | 1/1 |
| Gemini 4 Argon | 5/5 | 5/5 | 5/5 | 2/2 | 1/1 |
（満点だった回数 / 実行回数）
仕様がはっきりしていれば、Haikuは一度も失敗しませんでした。 循環参照を検出するスプレッドシートエンジンも作り、L5Aでは症状だけからバグ6つを直し、機能3つを追加し、既存テスト23件をひとつも壊しませんでした。L6の易しいバグと中くらいのバグもほぼ全実行が解き、HaikuとSonnetは14〜20秒で直しました。
難しいバグ：ここでモデルが分かれた
L6の難しいバグは、`C:\Users\`のようにバックスラッシュで終わるコードスパンがあると、同じ行の後ろの**太字**が効かなくなる問題です。メンテナーのテストには7ケースあり、修正前のコードでも3ケースは通ります。
完全に直した実行はひとつもありませんでした。ただし失敗の形はモデルごとに違いました。
| モデル | テスト | 実行ごとの通過ケース（7件中） | 他のテストを壊した |
|---|---|---|---|
| Haiku 5.5 | なし | 5, 5, 5, 5, 5 | 1回（15件） |
| Haiku 5.5 | 許可 | 5, 6, 5, 5, 5 | 0 |
| Sonnet 5.5 | なし | 6, 6, 5, 6, 6 | 0 |
| Sonnet 5.5 | 許可 | 6, 6, 6, 5, 6 | 0 |
| Opus 5.5 | なし | 6, 6, 6, 5, 0* | 1回 |
| Opus 5.5 | 許可 | 6, 6, 5, 5, 6 | 0 |
| Codex | なし | 3, 3, 4, 4, 4 | 3回（各2件） |
| Gemini 4 Argon | なし | 3, 3, 3 | 0 |
* このOpusの実行はソースに不正な正規表現を残したため、markedが読み込めなくなり全テストが失敗しました。
全実行が報告にある例は直しました。残ったのは、コードスパンの中にバッククォートを含むケース（_`_ など）で、報告には書かれていませんでした。Sonnetは10回中8回、Opusは10回中6回で7件中6件を通し、Haikuは10回中1回でした。 報告にない境界ケース1つ、これが探していた線です。
「テストを実行できなかったからでは」という反論
最初の測定では、どのエージェントもmarkedのテストを実行できませんでした。パッケージは入っておらず、Claude Codeはシェルを使えませんでした。実際の開発者はテストを回しながら直すので、Claudeの各モデルをさらに5回ずつ実行しました。依存関係を事前にインストールし、node、npm test／npm run、読み取り専用のgitを許可しました（インストールとネットワークは引き続き禁止）。
この15回はすべて実際にスペックテストを回し、多くは再現スクリプトも自分で書いて確かめました。それでも通ったケース数は変わりませんでした。 変わったのは被害です。テストなしのClaude 15回のうち2回が他の部分を壊しました（スペック15件を壊したHaiku、markedを読み込めなくしたOpus）が、テストを許可した15回では0回でした。
つまりこのバグでは、テストは残りのコードを守りましたが、報告に書かれていないケースに気づかせてはくれませんでした。
Codexもテストを許可して実行しましたが、Windowsのサンドボックスがesbuildによるmarkedのビルドを5回とも止めたため除外しました。Geminiは利用上限に達していました。
コスト
Claude Codeは実行ごとにAPI価格ベースのコストを出します。1回あたりの平均：
| Haiku 5.5 | Sonnet 5.5 | Opus 5.5 | |
|---|---|---|---|
| 全段階 | $0.026 | $0.19 | $0.45 |
| 難しいバグ・テストなし | $0.012 | $0.12 | $0.39 |
| 難しいバグ・テスト許可 | $0.031 | $0.22 | $0.48 |
全段階で見ると、HaikuはOpusより1回あたり約94%安く済みました。
Antigravityについて
Antigravityのヘッドレスモードは、コマンドが1回拒否されるとターン全体が終わります。読み取り専用の許可ルールだけでは、Geminiが数分コードを読んだあとnode -eで確かめようとした瞬間に止まることが何度もありました（Windowsでは引用符を含むコマンドに完全一致のルールが必要）。全権限で再実行すると易しいバグと中くらいのバグも解けましたが2〜11分かかり、難しいバグの1回は30分の制限を使い切って編集なしでした。
限界
- モデル間の差は、1プロジェクトの難しいバグ1つ、Claudeの各モデル10回に基づいています。
- L2〜L5はセルごとに1〜5回だけで、プロンプトにテストが使うidと関数名がすべて書いてあり、実際の仕事より簡単です。
- テスト許可の比較はClaudeの3モデルのみです。
- ツールにはモデル以外の違いもあります（サンドボックス、権限、拒否されたコマンドでの止まり方）。
データ（163回、実行ごとの点数・テストケース・時間・トークン・コスト、CC BY 4.0）：https://tokensave.app/data/ai-coding-limit-line
開示：この測定を公開しているTokenSaveを運営しています。Anthropic、OpenAI、Googleからの資金やクレジットは受けていません。