HNが見たOpus 4.7の違和感: 入力トークンは平均38%増

議論の中心はモデル名ではなくメーターだった

Hacker Newsで注目されたTokenomicsの投稿は、Claudeユーザーが普段は体感でしか分からない部分を測ろうとしたものだった。同じtranscriptをOpus 4.6とOpus 4.7のrequest tokenとして数え、差分を匿名で集計する。サイトはprompt本文を保存せず、匿名submission IDと比較用の集計値だけを残すと説明している。確認時点では541件のsubmissionがあり、Opus 4.6の平均は349 request tokens、Opus 4.7は466 request tokensだった。平均の変化率は+38.1%と表示されていた。

この数字が刺さったのは、コメント欄にすでに同じ体感があったからだ。Opus 4.7では5時間枠やdaily/weekly limitが以前より速く減る、と複数のユーザーが書いていた。特にcoding agentやIDE内の利用では、ファイル、ログ、tool output、過去の文脈が何度もrequestに入る。tokenizerの差は、そのままquotaの減り方として見えやすい。

ただし上位コメントは単純な結論を避けていた。total costを見るにはoutput tokenやreasoning tokenも含める必要がある、という指摘があった。Opus 4.7が入力を多く数えても、出力が短くなったりreasoning側が軽くなったりすれば、総額は別の見え方になる可能性がある。一方で、このデータはrequest tokenizerの変化を切り出しているからこそ有用だ、という受け止めも多かった。

このスレッドの面白さは、モデルの賢さだけを比べていない点にある。コミュニティは、モデル差し替えがbilling meter、IDEの利用制限、agent loopの反復回数にどう効くのかを見ようとしていた。LLMが一日中開いている開発環境になるほど、tokenizerは裏側の実装ではなく、ユーザーが直接向き合う製品仕様になる。

結論は限定的だが重要だ。モデル比較はbenchmarkや回答品質だけでは足りない。実際のworkflowを続けられるかどうかは、同じ作業がどの単位で課金・制限されるかにも左右される。

Source: Tokenomics leaderboard and Hacker News discussion.