HN threadの中心は、Claude 4.7がどれだけ賢いかではなかった。developer pricingの下にある、もっと地味な会計の話だ。同じworking contextがより多くのtokenになるなら、quota、cache cost、rate limitの体感はどう変わるのか。元記事はCLAUDE.md、prompt、diff、terminal output、stack trace、technical proseなど、Claude Codeに近い素材で4.6と4.7のtoken countを比べた。

方法はinferenceではなく、Anthropicのcount_tokens endpointを使うものだった。つまりmodel qualityではなくtokenizerそのものを見る比較だ。Anthropicのmigration noteは新tokenizerをおおむね1.0-1.35xと説明していたが、記事ではtechnical docsなど一部のsampleでそれを上回る比率が出た。sticker priceが同じでも、実際の消費量が変わるなら運用感は変わる。

コメント欄の読みは割れた。frontier modelはperformance-cost curve上にあり、新しいOpusは単により高いコストの点にいるだけかもしれない、という見方があった。一方でprofessional software workでは、token代よりもAI outputをレビューし、方向修正し、後始末するengineer timeの方が高いという反論もあった。さらに、すべてを最強modelに投げるのではなく、小さなmodelやlocal modelへtaskを振り分けるべきだという声も出た。

HNらしい結論は実務的だ。coding agentの費用はmonthly planやper-token rateだけでは読めない。tokenizer、context compaction、cache hit、model routing、human review timeが全部効いてくる。Claude 4.7が難しいtaskで十分な価値を返すなら追加tokenは払える。ただしcostを見るteamは、model名ではなくper-task token burnを自分たちのworkflowで測る必要がある。

この論点はsubscription buyerにも直結する。plan limitやmodel multiplierはpolicyの表面で、実際のworkflowではrepository context、retained instructions、repeated compaction、cached prefixが積み上がる。だから良い比較はmodel cardだけではない。同じtaskを複数modelで走らせ、token use、latency、修正回数、final diff qualityを一緒に見ることに近い。

#llm-costs

Claude 4.7のtokenizer費用、HNはsticker priceの裏側を見た