【要約】Claude Fable 5.1、2ターン目のキャッシュに12回中8回乗り損ねた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がClaude Fable 5.1の低コストなキャッシュ機能を利用しようとした際、その挙動が極めて不安定であるという問題に直面した。キャッシュの恩恵を期待してセッションを継続しても、期待通りに動作しないリスクがある。
- ・キャッシュ読みが$0.25/Mと安価だが、2ターン目のヒット率が安定しない。
- ・検証では12回中8回がキャッシュミスとなり、ヒット率が約40%まで低下した。
- ・ミス時には約5万トークンの書き直しが発生し、コストが約$1.00増大する。
- ・Opus 5等の他モデルで見られる安定したキャッシュ動作が確認できない。
// Approach
検証者は、Claude Codeを用いてプロンプトキャッシュの挙動を定量的に測定するアプローチをとった。実験環境はWindows 10、Claude Code 2.1.258である。
- ・
--output-format jsonを使用し、キャッシュトークン数を正確に取得した。 - ・初回入力から継続セッションへの遷移を繰り返し、ヒット率を算出。
- ・Opus 5やSonnet 5との比較、および待ち時間による影響の検証を実施した。
- ・キャッシュミス時の書き直しトークン数と、それによるコスト増を算出した。
// Result
検証の結果、Fable 5.1のキャッシュ挙動は「ヒットするか、書き直すか」の二値的な特性を持つことが判明した。
- ・ヒット時は約99.6%のキャッシュ利用が可能で、コストを大幅に抑えられる。
- ・ミス時は約39%まで低下し、大量のトークン再生成を伴う。
- ・待ち時間を45秒空けても改善せず、むしろヒット率が低下する結果となった。
- ・原因は特定できておらず、公開直後の不安定な状態である可能性がある。
Senior Engineer Insight
> キャッシュの「二値化」は、実戦的なシステム設計において極めて高いリスクとなる。コスト予測が困難であり、予算管理を複雑化させる。また、キャッシュミス時のレイテンシ増大が、リアルタイム性を求める用途には致命的だ。本番投入時は、キャッシュミスを前提としたリトライ戦略や、コストのバッファ設計が不可欠である。表面的な単価の安さに惑わされず、挙動の決定論的な側面を厳格に評価すべきだ。