指摘上限は11回とも指定どおり

上限が効く余地を残すよう、テストは意図的に設計された。6つの不具合を仕込んだ41行のcart.pyを、34行追加・2行削除の差分として提示している。実行はすべて同じモデルclaude-sonnet-5-5、バージョン2.1.296で、1回の呼び出しにつき1プロセス、各条件はテストフォルダの新しいコピーで行った。ただし上限が持ち越されるかどうかの確認だけは同じフォルダを再利用した。

最も興味深いのは正確な件数そのものではなく、その出どころだ。同じ不具合が毎回先頭に来たこと、20件の上限でも実在する8件しか返さなかったことから、上限はモデルが従う指示ではなく応答に適用される天井のように見える。所要時間も同じ構図を裏付ける。上限ありの最も遅い回が8,208msだったのに対し、上限なしの最も速い回は11,769msからで重なりがなく、出力の長さも桁が違った（366〜446文字対2,746〜3,245文字）。

著者はこの設定で決着できなかった点も挙げている。機能がバージョン2.1.288で追加されたという主張は、2.1.296しか試していないため未検証だ。上限が対話セッション内でも維持されるか、最初の指摘の後に行番号が1〜3行ずれる理由、上限なしの件数が7と8の間で揺れる理由はいずれも未解明のままだ。サードパーティ製プラグインの計測は、取得時の403と外部コードを遮断する環境ガードにより中止された。