逆向 Claude Agent SDK:把 Prompt Caching 效率從 25% 拉到 91% 的完整紀錄 | Allen 知識庫 | Allen 知識庫
title: "逆向 Claude Agent SDK:把 Prompt Caching 效率從 25% 拉到 91% 的完整紀錄"
date: 2026-03-26
author: miyago1124
source: https://miyago9267.com/Sharing/claude-sdk-cache-optimization/
category: articles
tags:
- Claude
- SDK
- Prompt Caching
- 逆向工程
- Token 優化
- Agent
created: 2026-03-26
updated: 2026-03-26
逆向 Claude Agent SDK:把 Prompt Caching 效率從 25% 拉到 91% 的完整紀錄
原文背景
作者為了做一個類似 Neuro Sama 的 AI Companion「Monika」(DDLC 的 Monika),串了 Claude Agent SDK 做多平台 Agent。結果發現每則訊息吃 2-3% 的五小時額度,一天燒 150 美元。逆向了 SDK 閉源的 12MB minified bundle 後,找到問題並修到 cache efficiency 91%。
結論先行
| 優化項目 | 階段 | 效果 |
|---|
| V2 persistent session | Phase 1 | cache 25% → 84% |
| 5 patch 解鎖 V2 選項 | Phase 1 | V2 可實際使用 |
| Tool 排序穩定化 | Phase 2 | 消除 multi-agent cache 失效 |
| cli.js 6 patch | Phase 2 | 各項額外 15-60% 削減 |
| ContextManager | Phase 2 | 防止 context 爆炸 |
| Cache keepalive | Phase 2 | 防止 idle 後 cache 過期 |
| V1 fallback | Phase 2 | 穩定性保障 |
cache efficiency 從 25% → 91%,每訊息成本從 2-3% 額度降到 <0.5%
監控公式:efficiency = cacheReadTokens / (inputTokens + cacheReadTokens + cacheCreationTokens),低於 50% 就是在燒錢。
Phase 1:從 V1 到 V2
為什麼 SDK 每次都 cache miss?
Anthropic API 的 prompt caching 是嚴格前綴匹配:從第一個 byte 開始比,少一個空格都 miss。
SDK V1 的 query() (12MB minified,用完即丟)。cli.js 每次啟動會動態塞 15+ 種 (git status、檔案 diff、CLAUDE.md、task 列表等),全部 UI 看不到。
每次都 spawn 一個全新的 cli.js process
<system-reminder>
isMeta: true
問題:每次 spawn 新 process,這些注入全部重新組裝。memory 的 mtime 不同、task 列表順序不同、git status 結果不同——只要一個 byte 不同,後面整段 messages 全部 miss。
45k tokens 以 125% 費率重寫,每則訊息都來一次。
V2 Persistent Session 解法
SDK 有一個 alpha API unstable_v2_createSession(),只 spawn 一次 cli.js process,之後訊息透過 stdin/stdout 在同一個 process 內通訊。
但 V2 在 v0.2.76 幾乎所有有用的選項都寫死了:settingSources 硬編碼 []、無 systemPrompt、mcpServers 硬編碼 {}。
5 個 Patch 硬改 sdk.mjs
settingSources:[] → options.settingSources??[](載入 CLAUDE.md)
- 插入
cwd: options.cwd(指定工作目錄)
- 讀取 thinkingConfig / maxTurns / maxBudgetUsd
- 過濾 CLI-side MCP servers
- 從 options 提取 systemPrompt + SDK MCP routing
用錨點字串定位(不靠行號),postinstall script 自動套用。
Phase 2:V2 之後的戰場
Tool 排序地雷
tools 陣列順序變了,即使內容完全一樣,cache 也會 miss。JavaScript 的 Object.keys 順序不保證穩定。
解法:一個 .sort() 搞定。 allowedTools、disallowedTools 全部排序。
cli.js 6 項修正
- context margin 1000 → 200 tokens(每次 compaction 省 800 tokens)
- fork pruning 限 5 turns(省 80% fork 啟動成本)
- subagent pruning 限 10 messages(省 60% cold start)
- SDK querySource 啟用 cache(最關鍵,乘數效應)
- 跳過 failed stream retry(避免 2x token 浪費)
- initConfig 修正(V2 session 行為正確)
Context 管理
SDK 的 modelUsage.inputTokens 回傳的是累計值不是單次(文件沒寫)。做了 diffCumulativeModelUsage() 轉換。
三種壓縮策略:自訂 2K summary 開新 session、呼叫 /compact 保留 5-10K、殺掉重來。
Cache Keepalive
標準帳號 cache TTL 5 分鐘,Max 1 小時。idle 時定期送輕量 ping 維持 cache。
V1 Fallback
三層降級:createSession 失敗 → V1、session.send 失敗 → V1、compact 失敗 → restart。不可逆,要回 V2 得重啟 process。
核心觀點
1. SDK 閉源但逆向不難
把字串常量當座標,搜關鍵字串定位函數,從函數往外追調用鏈。minified code 的字串常量每次升版不會變,行號會。
2. 這揭露了 Anthropic SDK 的嚴重效能問題
V1 每次 spawn 新 process 導致 cache 永遠只有 25%,這不是使用者的問題,是 SDK 架構決定的。作者只是用 V2 alpha API + patch 修了官方該修的東西。
3. multi-agent 場景下 token 成本管理是必修課
tool 排序、context 膨脹、cache 過期——每個都是獨立的坑,跑 production 才會踩到。如果你在做多 Agent 系統,這篇是必讀。