📍 真實場景
剛把 AI 編程助理串上公司 AWS 帳號的新創技術主管
為了用公司內部的 AWS 額度省錢，把 Codex 這種 AI 編程代理直接接到 AWS Bedrock 上的 GPT 模型，讓它整天自動幫忙寫程式、跑測試、修 bug
😖 卡住的地方：月底一看帳單才發現，本來該幫忙省錢的「快取」功能完全沒起作用，短短4天就在快取相關費用上燒掉超過1,182美元（約合台幣3萬7），而且完全沒有跳錯誤訊息，看起來一切正常運作
💡 讀完你會知道去哪裡查自己有沒有中招、怎麼先把出血點止住、以及該怎麼跟社群或廠商反應
⚡ 一句話講清楚
什麼是提示快取(prompt cache)就像請AI「記住」一段固定不變的長文字（例如你每次都要給它看的公司規範、工具說明），先付一次「建立記憶」的錢，之後只要內容沒變，AI用「讀記憶」的方式看過去，通常比整段重新讀便宜很多？這對「AI編程代理」特別重要，因為它是一種agentic coding讓AI自己規劃步驟、自己呼叫工具、自己做決定的自動化寫程式模式，跟你一問一答完全不同，會非常頻繁地重複呼叫模型，每一次呼叫都要把整套「你是誰、能用什麼工具」的指令重新塞給AI看一遍——如果這段話能被快取住，就能省下大量重複的錢。
這次的問題出在哪？Codex（OpenAI出的AI編程CLI工具）可以直接接上AWS Bedrock亞馬遜的雲端服務，讓企業不用自己買機器，就能在自己的AWS帳號裡直接呼叫各家AI模型，這裡指的是Bedrock裡的GPT-5.6 Sol模型，但這條直接串接的管道，並沒有把「請幫我把這段標記為要建立快取」的開關傳過去給模型。結果就是每次呼叫，AI模型都以為內容是全新的，不斷重複做「快取寫入(cache write)第一次把一段內容存進快取，通常單價比普通輸入還貴，目的是換取「之後」能用比較便宜的價格重複讀取」，卻幾乎沒有機會做到真正省錢的「快取讀取(cache read)用已經存好的快取內容回應，通常只要一般輸入價格的一小部分」。
有工程師實測4天燒了超過1,182美元在快取寫入上，佔該模型總花費的85%；本機一次session裡累積了670萬個快取寫入token，對應到的快取讀取token卻是「零」——等於每一次都在付「建立快取」的貴錢，卻從沒享受到「用快取」的便宜，而且過程中系統完全沒有跳出任何錯誤訊息，帳單暴增前你根本不會發現異狀。
🏃 快速上手三步（今天就能做）
1
先查帳單有沒有中招登入 AWS 主控台 → Billing and Cost Management → Cost Explorer，依「服務」篩選出 Bedrock，再依「使用類型」細看有沒有大量標示 CacheWrite 字樣的項目；如果你是用 Codex CLI 接 Bedrock，先在終端機執行 `codex --version` 確認版本號（這次回報問題的版本是0.147.0），並確認你的設定是不是走「native amazon-bedrock」這條串接路徑。
▼
2
先繞開，別讓它繼續燒如果不是非用這條路徑不可，暫時改用 Codex 官方本來就有妥善快取控制的串接方式（例如直接接 OpenAI 官方 API），而不是走「native amazon-bedrock」；同時把原本掛著整天自動跑的 agentic 排程任務先停掉，改成手動、短時間測試，一邊觀察 Cost Explorer 或 CloudWatch 裡快取寫入的 token 數字是否還在持續飆升。
▼
3
判斷是否嚴重、要不要出聲有兩個判斷標準：(1) 快取寫入token數字很大，但快取讀取token幾乎是0；(2) 同一個模型的帳單裡，快取寫入費用佔比超過一半以上。只要符合，就到 GitHub 的 openai/codex 專案下的 issue #37674 留言附上自己實際量測到的數字，回報的人越多、附的實測數據越具體，官方越有動力提前修。
🧠 工程思維透鏡（資深工程師看到的是什麼）
🔭 為什麼「快取」這個原本要省錢的功能，反而變成燒錢兇手？
快取寫入通常比一般輸入貴，它划算的前提是「這段內容之後真的會被重複讀取很多次」。當串接方式沒辦法明確標記「這段是穩定不變的內容，請幫我做快取」，每次呼叫都會被系統當成全新內容處理，於是只會不斷「寫入」卻沒機會「讀取」——你付了比正常更貴的錢，卻完全沒拿到快取該有的折扣。這是典型的「功能本身存在、但串接層沒有把設定開關暴露出來」的工程債，越自動化、呼叫越頻繁的場景（例如agentic coding）踩到的代價就越大。
🔭 這種問題不會跳錯誤訊息，怎麼提前發現？
因為這不是「程式報錯」，而是「花更多錢但功能一切正常」，CloudWatch上的錯誤指標(client errors)完全顯示為0，系統看起來很健康，只有帳單數字會說實話。這提醒我們：任何串接第三方付費API的自動化代理，上線前都該額外設定「用量或預算警報」，而不是只看log裡有沒有error——尤其是agentic這種「代理會自己不斷重複呼叫模型」的模式，失控起來的速度遠比人工手動使用快得多，等到人發現通常已經燒了不少錢。