Claude緩存策略引發(fā)爭議：關閉遙測致性能驟降，開發(fā)者集體聲討
4月13日，一條推文在開發(fā)者群體中迅速發(fā)酵。
開發(fā)者Can Vardar發(fā)文質疑：
Claude Code會因為關閉遙測而“懲罰”用戶嗎？
關閉遙測后，Anthropic將緩存時長從1小時縮減至5分鐘，隱私保護竟要付出12倍的性能代價……這是真的嗎？
該推文轉發(fā)量很快突破萬次。
這并非技術漏洞，而是Anthropic以隱私換取性能的隱性規(guī)則。
你以為關閉數據收集只是保護個人信息？
事實是，Claude Code會直接影響長上下文會話體驗。Pro用戶原本5小時的使用時長僅剩2條提示詞額度，月付200美元的Max訂閱者1.5小時就會耗盡額度。
這種情況令人匪夷所思。
Claude性能持續(xù)下滑！
從緩存縮短到成本激增
實際情況清晰可見。
開發(fā)者發(fā)現，只要在環(huán)境變量中添加DISABLE_TELEMETRY=1，Claude Code的提示詞緩存生存時間（TTL）就會從1小時驟減至5分鐘。
數據顯示，緩存時長直接縮短了12倍。
在GitHub上，Claude Code用戶分享的日志顯示：開啟遙測時，ephemeral_1h_input_tokens輕松超過3萬；關閉遙測后，1小時緩存數據直接歸零，全部使用5分鐘緩存。同一段代碼的緩存未命中率飆升12倍。
緩存對長上下文會話至關重要。
當啟用提示詞緩存發(fā)送請求時，系統(tǒng)會先檢查：從指定緩存分隔點往前的提示詞開頭部分，是否在最近請求中已被存儲。
如果命中緩存，直接調用現成版本，時間和成本大幅降低。
未命中的話，就需要完整處理整個提示詞，在生成回復時將開頭部分存入緩存。
緩存一旦過期，系統(tǒng)就得重新處理，寫入成本是讀取成本的12.5倍。5分鐘的TTL意味著用戶稍作停頓（比如思考思路、泡咖啡），回來就需要重新處理，成本驟增。
更嚴重的問題還在后面。
另一位開發(fā)者Sean Swanson提供了更詳實的證據。
他分析了2026年1月11日至4月11日的119,866次API調用日志，清晰展示了緩存策略的變化：
2月，1小時TTL全面應用，緩存浪費率僅1.1%；
3月6日左右，系統(tǒng)悄然回退到5分鐘TTL，浪費率飆升至25.9%。
結果是，同一會話中cache_create操作頻率暴增5-12倍。
cache_create寫入成本更高，5分鐘緩存寫入成本是基礎輸入的1.25倍，1小時緩存是2倍，但頻繁重建導致總token消耗大幅增加。
Pro用戶抱怨：以前一天能輕松用完額度，現在1.5小時就耗盡了。Max計劃每月200美元，修兩個bug、寫個計劃就把額度用完了。
企業(yè)團隊面臨的問題更嚴重。
Hacker News上有用戶表示，3月底后Claude性能“肉眼可見地下降”，長會話頻繁卡頓，token額度消耗極快。
4月13日，國外科技媒體直接發(fā)文《Anthropic在削弱Claude嗎？》。
Anthropic的回應
并非懲罰，而是技術架構問題
面對大量質疑，Anthropic的兩位關鍵人物作出回應。
Claude Code的創(chuàng)造者Boris Cherny在回帖中承認，關閉遙測會導致實驗性優(yōu)化失效，使緩存回退到5分鐘默認值。
簡單來說，機制是這樣的：
1小時緩存是“實驗性”優(yōu)化，通過客戶端實驗網關推送。只有開啟遙測，網關才能獲取最新策略。
但他強調這并非刻意懲罰，而是架構設計中的耦合問題。
Cherny同時解釋了緩存策略的設計邏輯：Anthropic在后臺持續(xù)測試不同緩存策略組合，目標是優(yōu)化整體緩存命中率、Token消耗和延遲表現。
關閉遙測后，客戶端會直接讀取默認值——5分鐘。
這不是惡意行為，而是“技術副作用”。
5分鐘緩存在某些場景下更經濟，比如子智能體調用，這類請求通常是一次性的，緩存很少被重復讀取，用1小時TTL反而會浪費2倍寫入成本。
不過，他也承認：“大量技能、多個智能體或后臺自動化任務同時運行時，Token消耗確實很大，尤其是使用大量插件時?！?/p>
受影響的用戶數量不少，Anthropic正在改進：
(a) 優(yōu)化用戶體驗，讓用戶更清楚了解情況；
(b) 更智能地截斷、精簡和調度非主任務，避免意外的Token消耗。
Anthropic另一位工程師、Bun運行時的創(chuàng)造者Jarred Sumner回應了3月的TTL回退問題。
他認為5分鐘TTL對整體而言“更便宜而非更貴”，因為“相當一部分Claude Code請求是一次性調用，緩存上下文只用一次就不再訪問”。
從技術層面看，這個解釋有一定道理，但用戶并不買賬。
問題在于，Swanson的數據直接反駁了這一點：2月份1小時TTL下的浪費率僅1.1%，如果大多數請求真的是一次性的，2月應該出現大量寫入浪費才對。
行業(yè)深層問題
AI的Token計價缺乏透明度
從更宏觀的角度看，這不僅僅是Anthropic一家公司的問題。
目前，AI編碼工具的按使用量計費完全依賴用戶信任。
開發(fā)者看不到計費的具體過程，無法審計每個請求的Token用量，無法驗證緩存狀態(tài)，無法確認應用的定價層級，也無法檢查高峰期倍數因子是否生效。
與其他開發(fā)者付費使用的基礎設施相比：
- AWS EC2：按秒計費，提供完整的實例可見性、CloudWatch指標、賬單警報和成本分析工具
- Stripe：按交易計費，每筆費用都有日志記錄且可審計，提供實時儀表盤
- Vercel：按調用計費，提供函數級指標、支出限額和自動警報
- Claude Code：按Token計費，無單次請求用量明細，無緩存命中可見性，無支出警報，無實時成本跟蹤
這種信息不對稱令人震驚。同價位的其他開發(fā)者工具都能讓用戶詳細了解費用構成，而AI編程助手只給用戶一個限額進度條，全憑信任。
這種不對稱平時對服務提供商有利，一旦出現問題，就會給用戶帶來嚴重損失。
AI計費沒有第三方審計，沒有Token用量報告的開源標準，也沒有針對提示詞成本的云端分析工具。
這不是合理的計費模式，更像是讓用戶盲目信任的冒險。
參考資料：
https://x.com/icanvardar/status/2043652025339023845
https://github.com/anthropics/claude-code/issues/45381
https://x.com/bcherny/status/2043715713551212834
https://platform.claude.com/docs/en/build-with-claude/prompt-caching#pricing
https://www.theregister.com/2026/04/13/claude_code_cache_confusion/
本文來自微信公眾號“新智元”，作者：新智元，編輯：KingHZ，36氪經授權發(fā)布。
本文僅代表作者觀點，版權歸原創(chuàng)者所有，如需轉載請在文中注明來源及作者名字。
免責聲明：本文系轉載編輯文章，僅作分享之用。如分享內容、圖片侵犯到您的版權或非授權發(fā)布，請及時與我們聯系進行審核處理或刪除，您可以發(fā)送材料至郵箱：service@tojoy.com