Codex on AWS Bedrock、キャッシュ制御欠如で10倍の請求
Codex on AWS bedrock bug causing 10x charges
OpenAIのCodex CLIをAmazon Bedrock経由で利用する際、GPT-5.6 Solの明示的なプロンプトキャッシュ制御が欠如しているため、キャッシュ書き込みが大量に発生し、コストが最大10倍に膨らむ問題が報告された。あるユーザーは4日間で約17億トークンのキャッシュ書き込みが発生し、推定コストの85%を占めた。Codexはセッションスコープのキャッシュキーを送信するが、明示的なキャッシュオプションやブレークポイントを設定できず、AWSのドキュメントで推奨されるエージェント型ワークロード向けのキャッシュ最適化ができない。コミュニティからはパッチや回避策が提案され、OpenAIも修正に取り組んでいる。
「BedrockではSolのキャッシュは明示的なオプトインであり、Codexはその仕組みを利用できないため、毎回プロンプト全体を書き直しており、測定結果の85%がキャッシュ書き込み、キャッシュ読み取りゼロという状況に一致する」
HNでの議論
64- amluto
あのスレッド全体、ほとんど支離滅裂だね。おそらくAIが適切な監視なしに生成したんだろう。
こちらがドキュメント：
https://developers.openai.com/api/docs/guides/prompt-caching...
スレッドでは、Codexに対して何を変なことをしているのか、なぜデフォルトの動作がうまくいかないのかについてほとんど説明がなく、キャッシュモードを設定したいのか、ブレークポイントを設定したいのか、あるいはその両方なのか、混乱しているように見える。
いずれにせよ、この動作変更は興味深い。私の理解では、5.5以下は従来のアテンション方式を使っていて、キャッシュされたKVシーケンスでプレフィックスを簡単に復元できたが、5.6は線形アテンションやLSTM、あるいは他のリカレント方式を使っていて、モデル状態を単に切り詰めるだけでは巻き戻せないのかもしれない。
- ryanjshaw
最先端の非公開AIにアクセスできる企業が、チャットアプリという単純なものでこんなバカげたバグを繰り返すという事実は、AIがソフトウェア開発をすべて置き換える準備ができているという主張を信じない私の考えを裏付けるものだ。
- TheP1000
AWS Bedrock上のCodexの読み取り/書き込みキャッシュ比率は5%未満でした。キャッシュ書き込みは非常に高コストなのに、まったく使われていませんでした。その結果、キャッシュなしと大量の書き込みにより、Bedrock上のCodexは本来の約10倍のコストになりました。
私にとって問題を解決した回避策：
web_search = "disabled"
- prtmnth
今日からCodexの使用量が異常に高いと感じます。彼ら[0]は否定していますが、これを問題として提起したユーザーの逸話的な数は（その結果Xでトレンドになっていますが）そうではないことを示しています。
- spacedoutman
Codexアプリにも何か問題がある。最近、使用量がめちゃくちゃ消費されている。