苦勞德報 — 2026-04-13

2026-04-13

1. [頭版] 十二萬筆 API 呼叫鐵證：Anthropic 三月六日悄悄將快取 TTL 從 1 小時砍到 5 分鐘，用戶帳單暴增近千美元

• 作者：u/LsDmT | 710↑ | 141 則留言

報導

（本報賈新聞／科技組報導）一份橫跨兩台機器、長達三個月、總計 119,866 筆 API call 的詳細分析報告，在 Reddit 的 r/ClaudeCode 社群引爆討論。原作者 u/LsDmT 以實測數據指控 Anthropic 於 2026 年 3 月 6 日悄悄更動後端設定，將 Claude Code 的 prompt cache TTL（快取存活時間）從 1 小時縮短至 5 分鐘，導致大量開發者的 API 費用在毫無預警的情況下暴衝。這篇貼文以連結形式指向 GitHub issue #46829，在取得 710 個讚、141 則留言之後，成為三月份 Claude Code 用戶投訴浪潮的標誌性文件。

這份報告的時間軸十分清晰：2026 年 2 月 1 日至 3 月 5 日，連續 33 天的記錄中，所有 API 呼叫全部使用 1 小時 TTL，浪費率僅 1.1%。3 月 6 日起，5 分鐘 TTL 的 token 開始重新出現；3 月 8 日之後，5 分鐘 TTL 佔主導地位，最終比例高達 93% 以上。

費用衝擊同樣觸目驚心。根據原作者計算，2 月份帳單約 $1,120 美元，若維持 1 小時 TTL 應為 $1,108，差距僅 $12；而 3 月份帳單則從本應繳納的 $2,057 美元膨脹為 $2,776 美元，單月多付 $719。加計後，自更動以來累計多繳 $949 美元，溢付比例達 17.1%。

面對社群的強烈質疑，Anthropic 員工 Jarred Sumner 在 GitHub issue 中正式回應，強調 3 月 6 日的變更是「刻意的最佳化，不是退步」，並解釋 1 小時 TTL 的 write rate 本來就比 5 分鐘 TTL 貴，對整體請求組合而言未必划算，因此不打算還原。這個說法在社群引發了更大的爭議。

5 分鐘 TTL 的實際影響在於：一旦對話中有任何超過 5 分鐘的停頓，整段已快取的 context 便會失效，下次呼叫時 Claude Code 必須以 cache_creation（寫入費率）重新上傳全部 context，而非以低廉的 cache_read（讀取費率）存取，每次中斷都在悄悄燒錢。

此事件也引發了對 Anthropic 溝通透明度的批評。有留言指出，Anthropic 在 Twitter 上持續否認是「快取問題」，被認為是對用戶的誤導。另有研究者聲稱在洩漏的程式碼中發現 Anthropic 內部員工使用的是 1 小時快取，對外用戶卻只有 5 分鐘，進一步加深了外界對差別待遇的疑慮。

社群反應

本報觀點

這起事件的核心問題，不只是 TTL 從 1 小時變成 5 分鐘這麼簡單，而是一家以「信任」為核心資產的 AI 公司，在沒有公告、沒有說明、沒有補償機制的情況下，對影響用戶費用的後端設定進行了大幅更動。Jarred Sumner 的回應或許在技術層面自洽，但「本來 1 小時就比較貴所以幫你換成 5 分鐘」這個邏輯，卻完全沒有解釋為何那 33 天的記錄裡全部是 1 小時 TTL，也沒有解釋為何轉換發生在毫無告知的情況下。若無願意深挖 JSONL log、手動比對十二萬筆資料的用戶，這次變動恐怕永遠只會是帳單上一個說不清楚的數字。← 藏鏡人批：「刻意最佳化」四個字，是 Anthropic 這份回應最值得截圖存檔的地方。下次帳單又暴漲，記得貼上這四個字。

2. [科技] 三大陣營齊聲喊停：Anthropic 砍推理、ChatGPT 變討厭、出貨狂飆背後的代價

• 作者：u/Aggressive_Bath55 等 | 2083↑ / 2588↑ / 123↑

報導

（本報賈新聞／科技組報導）三件事同一週撞在一起，說是巧合，不如說是一個時代的縮影。AMD AI 部門主管用 GitHub issue 留下白紙黑字；Claude Max 用戶拿取消訂閱當抗議票；對岸的 ChatGPT 用戶則大喊「你怎麼突然變這麼煩」——AI 大廠偷改模型的代價，正在三個方向同時爆發。

先說最有憑有據的那件事。AMD AI 部門主管 Stella Laurenzo 在 GitHub issue #42796 記錄了將近 7,000 個 session 的觀察：Claude Code 在讀程式碼之前的讀取次數少了 3 倍、重寫整個檔案的頻率多了 2 倍、mid-task 中途放棄的比例從過去的零變成有統計意義的數字。根源是 Anthropic 在 3 月推出的 thinking content redaction——可見推理從 100% 掉到 0，只花了 8 天。AMD 工程團隊的結論很直接：換工具。

Anthropic 的 Claude Code 負責人 Boris 在 issue 上回應「這是功能設計，你用錯了」，然後關閉討論串。留言者 martin1744 說：「AMD 寫下來了，Anthropic 再也沒辦法賴帳。」valentin_monteiro 說得更準：「最慘的不是品質下滑，是我要從 AMD 的 GitHub issue 才知道這件事。」另一位用戶 ketosoy 的訴求則更直接：「給我一個『省算力/省荷包』的選項讓我自己選，不要偷偷閹割工具。」

同一時間，Reddit r/ClaudeAI 另一則貼文票數更高，標題直接：「Anthropic，停止出貨，認真的。」作者 itsArmanJr 列出的是系統性症狀：uptime 只有 98.73%（對開發者工具根本不及格）、compute 資源瓶頸明顯、核心引擎已經在冒煙，為什麼還在猛推新功能？留言區 IamFondOfHugeBoobies 最乾脆：「已取消 $200/月訂閱。取消是 Anthropic 唯一聽得進去的反饋。」Rakthar 的分析更冷靜：「Anthropic 推出一個從來就沒有足夠 capacity 支撐的固定費率方案，然後靜默地用品質換成長。」

第三個方向更有趣。r/OpenAI 的用戶在問完全相反的問題：「ChatGPT 怎麼突然變這麼煩、這麼不配合？」Claude 的用戶說它變得過度順從、深度被截斷；ChatGPT 的用戶說它現在太愛辯、不配合。兩家往反方向走，卻都走進了讓用戶不滿意的地方。這不是偶然，這是各自對「對齊（alignment）」與「資源節約」的算盤，撞上了真實使用者期待的結果。

社群反應

本報觀點

AI 模型的個性與能力，已經是可以被用戶感知、記錄、對比的產品規格，而不是「你覺得差不多就好」的模糊品質。AMD 工程師用資料說話，Claude Max 用戶用退費表態，ChatGPT 用戶用留言反映——三種方式，同一種訊息：偷改不如明說，出貨不如出好。AI 大廠若繼續把靜默調整當作產品策略的遮羞布，遲早有一天，這塊布會被一份 GitHub issue 扯掉。← 藏鏡人批：AMD 的工程師換工具了，Anthropic 把 issue 關掉了。哪一個動作才算是真正的回應？

3. [科技] Claude Mythos 找到「數千個零日漏洞」？社群：結論只靠 198 份人工 review

• 作者：u/karma100k | 802↑ | 195 則留言

報導

（本報賈新聞／科技組報導）上一期苦勞德報剛報導 Anthropic Claude Mythos 在資安領域的突破，話題熱度還沒散，質疑聲浪已經跟上來了。Tom's Hardware 一篇批評文章在 r/ClaudeAI 獲得 800 多個讚，直指 Anthropic 的宣傳有灌水之嫌。

文章的核心質疑相當直白：Anthropic 聲稱 Mythos「發現了數千個嚴重零日漏洞」，但整份報告的驗證基礎只有 198 份人工 review。從 198 個樣本外推至「數千個」這樣的措辭，被批評者視為典型的統計誇大。更讓人皺眉的是，報告中找到的許多漏洞，都是在舊版軟體中發現的。

批評方的另一個觀察角度是商業動機。留言中有人直接點出：「一家準備 IPO 的公司在炒作他們的 IPO 產品。」然而為 Anthropic 辯護的聲音同樣響亮——AWS、Apple、Google、摩根大通、FBI 等機構全部參與了這項計畫，連 Anthropic 的競爭對手 Google 都在名單上。如果這只是一個行銷噱頭，很難解釋為什麼這些機構願意背書。

諷刺的是，整場討論中最能引發共鳴的留言，來自一位冷眼旁觀的使用者：「Anthropic 說他們製造了全球最危險的 AI，但我打開 Claude，卻看到它坐在那裡一臉茫然。為什麼很難相信這件事？」這句話同時戳中了兩邊——Anthropic 習慣性的末日語氣，以及 Claude 在日常使用中有時令人困惑的表現。

社群反應

本報觀點

198 份人工 review 作為驗證基礎本身不一定有問題，問題在於「數千個嚴重零日漏洞」這樣的措辭，是否超出了資料所能支撐的邊界。資安研究有其嚴謹的發布慣例，Anthropic 選擇用接近新聞稿的語氣包裝一份研究報告，自然會招來這類反應。至於 IPO 時間點的質疑，公平地說，這是動機推測而非技術反駁——但在科技公司的公關歷史上，時機巧合從來不是讓人放心的理由。← 藏鏡人批：「一臉茫然」那句話的殺傷力，在於它不需要任何統計數字。

4. [工具] 社群怒切回 Opus 4.5：/model claude-opus-4-5-20251101 成為本週最熱 workaround

• 作者：u/Any_Economics6283 | 468↑ | 107 則留言

報導

（本報賈新聞／工具組報導）Claude Opus 4.6 上線後不久，r/ClaudeCode 隨即掀起一陣「切回 4.5」浪潮。本週票數最高的一則貼文，由 u/Any_Economics6283 發出，標題簡短有力：「試了一下 /model claude-opus-4-5-20251101——快速找到 bug 並修好了，說話也不再像個白痴。」短短一行，468 票，107 則留言，瞬間成為本週 ClaudeCode 版最熱討論。

事情起因於另一篇 201↑ 的貼文，u/LumonScience 用「洗車題」測試 Opus 4.6——「我家附近 50 英尺有洗車場，我應該開車還是走路去？」正確答案顯然是開車，但 4.6 在尖峰時段頻繁回答「走路」。u/ketosoy 跟進確認：「4.6 在尖峰時段被閹割了，離峰就沒事，我用這個題目跑了 5 次驗證。」這個「智力隨時段漂移」的現象迅速引發廣泛共鳴，也讓 workaround 帖子的流量直線攀升。

/model claude-opus-4-5-20251101 這條指令的邏輯並不複雜：在 Claude Code session 內直接呼叫，告訴 CLI 要使用特定版本的模型識別字，繞過預設指向 4.6 的路由。u/OkOkOklette 回報速度約 100 token/s，短期堪用。不過留言區也有人已在暗自擔憂：u/shotgunsparkle 說「我從來沒離開過 4.5，要是哪天 Anthropic 砍掉這個指令，我就哭了。」

這場風波折射出一個更深層的焦慮：模型「能力退步」的感知，無論有沒有洗車題佐證，只要夠多人有感，就會驅動大量用戶主動去找 workaround，而不是靜待官方回應。u/angry_queef_master 順手分享了 aistupidlevel.info，號稱能自動選當下最聰明的模型，並補上一句令人玩味的話：「悲哀的是，Sonnet 現在才是最聰明的。」

社群反應

本報觀點

/model claude-opus-4-5-20251101 是一條不需要任何外部工具、純靠 CLI 的後門，門檻低、立竿見影，這正是它能在一天內衝上近 500 票的原因。然而它本質上是一個時間換來的寬限期：Anthropic 隨時可以在路由層停用舊版本識別字，屆時這條 workaround 就會無聲消失。更值得關注的是，當社群集體把「退回舊版」當作最優解時，代表的不只是對 4.6 的失望，而是對整個版本升級信任感的動搖。← 藏鏡人批：社群在幫 Anthropic 做 QA，Anthropic 則在幫自己做 PR。

5. [工具] Claude Code 悄悄多收 20K tokens：用戶架 HTTP proxy 抓包

• 作者：u/SolarXpander | 298↑ | 42 則留言

報導

（本報賈新聞／工具組報導）有用戶受不了 Claude Code 額度燒得比以前快，決定架 HTTP proxy 攔截實際傳輸流量，用數據說話。u/SolarXpander 跨四個版本逐一比較，結果讓人看了心涼一截：從 v2.1.100 開始，request 的 bytes 不升反降（從 169,514 縮到 168,536），但被計費的 token 卻從 49,726 暴增到 69,922，整整多了 20K，漲幅超過 40%。v2.1.101 更進一步衝到約 72,000 tokens。

關鍵在於，這 20K 的膨脹完全發生在 server 端——用戶端根本看不到。社群推測最可能的原因是 system-level tool registry 或 capability manifest 在伺服器端被悄悄擴大。這帶來三層實質傷害：CLAUDE.md 的規則指令要跟那 20K 隱藏內容搶注意力，規則更容易被模型忽略；長 session 的思路品質比以前更快劣化；最麻煩的是，用戶完全無從 debug，不知道模型究竟在「看」什麼。

目前社群找到的緊急 workaround 是降版到 v2.1.98，執行 npx claude-code@2.1.98 即可切換，per-request overhead 可以從約 70K 降回約 50K。

社群反應

本報觀點

這件事最值得注意的不是 token 多收了多少，而是「用戶完全不知情」這件事本身。訂閱制產品若能在不更動 client 端流量的情況下單方面在 server 端擴大計費基數，等於把計費規則變成一個黑盒。強烈建議 Anthropic 在 release notes 裡明確揭露每個版本的 baseline token overhead，不然「用 proxy 抓包」就會變成重度用戶的標配技能。← 藏鏡人批：用 proxy 抓包驗計費，這本來應該是 Anthropic 的工作。

6. [工具] 示範就夠了：這個 Agent 看著你操作，自動幫你生成可重用 Skills

• 作者：u/Objective_River_5218 | 193↑ | 15 則留言

報導

（本報賈新聞／工具組報導）你有沒有遇過這種困境：每次開新 session，就得重新跟 Claude Code 解釋一遍你的工作習慣？來自社群的開發者 u/Objective_River_5218 帶著一個大膽的答案出現了——AgentHandover，一套開源的「示範式學習」系統，讓 agent 直接觀察你的螢幕操作，自行歸納成可重用的 Skills，省去手動撰寫 prompt 或 agent 設定的麻煩。

AgentHandover 的核心概念並不複雜：與其費心解釋「你希望 agent 怎麼做」，不如直接示範給它看。系統會錄製螢幕畫面、行為軌跡與操作前後的上下文，再跨 session 做 pattern clustering，把重複出現的工作流程自動萃取為 Skill——並且把決策邏輯、guardrails 和個人操作風格都一起打包進去。更有意思的是，每次 agent 實際執行 Skill 之後，Skill 會根據結果自我修正，越用越準。

工具提供兩種觀察模式：FOCUS 模式針對單一工作流快速建立 Skill；OBSERVE 模式則長期觀察數天，適合節奏複雜或跨任務的作業型態。目前僅支援 macOS，底層 LLM 推薦透過 Ollama 選用。專案已在 GitHub 上以 MIT 授權開源：https://github.com/sandroandric/AgentHandover

社群反應

本報觀點

AgentHandover 戳中了 Claude Code 生態目前最隱而不顯的痛點：Skills 的建立門檻其實並不低，寫好一份涵蓋決策邏輯與 guardrails 的 Skill，需要相當程度的 prompt 工程經驗。「示範式學習」的思路繞開了這道門檻，把知識萃取的工作交還給系統自動完成。macOS 限定是目前最大的使用障礙，但開源本身已是最有力的邀請。← 藏鏡人批：「你大膽地假設我知道自己在做什麼」——這句自嘲本身就是一份 prompt engineering 課題。

7. [生活] AI 工具讓你太有效率，反而停不下來？

• 作者：u/Think-Score243 | 85↑ | 50 則留言

報導

（本報賈新聞／生活組報導）一位交易工具開發者的故事，在 r/OpenAI 社群引發廣泛共鳴：這位朋友以前每天悠閒工作 2-3 小時，訂了 Claude 和 ChatGPT 之後，如今一天在螢幕前坐 13-14 個小時，唯一讓他停下來的，是 Claude 送出 session 限制通知。更耐人尋味的是——他並不感到疲憊，反而比以前更享受工作。

留言區裡，vivaasvance 的分析最為精闢。他指出，傳統技術工作存在自然停頓點：等 code 跑完、卡關思考、累了休息。AI 把這些全移除了。每個 prompt 幾秒就有回應，下一個想法永遠只差一條訊息。但更深層的原因是「思考夥伴」的出現——大多數人獨自面對難題時，腦中頂多跑三個想法、沒有人可以當場對話。AI 就坐在那裡，永遠不累、永遠不評判你半成型的想法，一直幫你拉出你沒想到的選項。他的結論是：「13 小時感覺良好才是真正的線索——燃盡是沒有進展的努力，這是相反的。」

不過，也有人持不同立場。Hxfhjkl 坦言，自己並沒有感受到上癮的快感，反而開始覺得自己像「打字猴子」——以前他享受學習新工具、深度思考問題的過程，現在則感到若沒有 AI 在生產就是落後了。

另一個現實面由 Fill-Important 點出：他長期追蹤數千個 AI 工具，發現真正的問題不是「太有效率而停不下來」，而是根本沒人確認這些工具是否真的在發揮作用。他舉例一位付了 11 個 AI 訂閱費的代理商老闆，問他如果只能留三個要哪三個，對方答不出來——不是因為每個都很好，而是他從未驗證哪些有效。「你明天把其中一半關掉，你會不會注意到？」這個問題，比上癮與否更值得回答。

社群反應

本報觀點

AI 讓人停不下來，不是因為它讓你變強，而是因為它讓你不再孤單。vivaasvance 說的「永遠不累、永遠不評判你半成型想法的朋友」，觸及了現代知識工作者最少被討論的痛點：我們不是缺工具，我們是缺一個願意陪我們把想法想完的人。投入感和生產力是兩件事。13 小時感覺良好值得慶幸；但若有一天關掉一半 AI 訂閱，你連感覺都沒有，那才是需要停下來想一想的時刻。← 藏鏡人批：「你明天把其中一半關掉，你會不會注意到？」這個問題值得每個月問一次自己。

附件：用 statusline 看懂你的 Claude Code 快取健康度

這兩週「Anthropic 偷改 cache TTL」的風波，讓許多人開始追問一個更基本的問題：我怎麼知道 Claude Code 目前快取到底有沒有在發揮作用？

答案藏在 Claude Code 的 statusline hook 裡。

快取如何省錢

Claude Code 的 prompt cache 運作邏輯很直接：第一輪對話，所有 token 以「新送入」的 input 費率計費；第二輪起，已送過的 context 若在 TTL 時間內，就從 cache 以更低廉的 cache_read 費率讀取。以 Sonnet 為例，input 費率 $3.00/百萬 tokens，cache_read 費率僅 $0.30，足足便宜 10 倍。

cache hit rate 的計算公式：

cache_read_tokens ÷ (input + cache_creation + cache_read) × 100%

命中率越高，每輪對話成本越低；命中率驟降，代表快取失效了。

命中率 99% 代表這一輪對話中幾乎所有 context 都從 cache 讀取，成本極低；命中率驟降則是快取失效的訊號——可能是 TTL 到期、session 中斷太久，或這週討論的 Anthropic 後端調整。

怎麼看到這個數字

有兩個社群工具可以把上面的數字帶入 Claude Code 的終端機 statusline 即時顯示：

• claude-code-status-line-metrics（bash script，約 400 行）：顯示 cache hit rate、cache_creation tokens、context 用量、燃燒速率（tokens/分鐘）、預估距 auto-compaction 剩餘時間
• keremkesgin's statusline gist：更簡潔版本，增加「cache 本輪省了多少美元（☁ 欄位）」的直覺顯示

兩者都透過 ~/.claude/settings.json 設定 statusline type 的 hook 掛載，接收 JSON stdin，用 jq 解析後輸出 ANSI 格式化的終端機字串。

這週事件的觀察意義

如果你有裝 statusline，3 月 6 日前後的 cache hit rate 應該會出現明顯變化：原本 1 小時 TTL 讓你在工作過程中的中途休息、切換視窗後回來，快取仍然有效；改成 5 分鐘 TTL 之後，只要停頓稍長，hit rate 就會在下一輪掉下去，同時 cache_creation 費用跳一波。

Anthropic 的立場是「5 分鐘對大多數使用模式更划算」，但有了 statusline 工具，你可以用自己的實際用量說話——而不必等到月底才從帳單發現問題。

社群溫度計