Headroom 幾乎沒有減少 Claude Code 訂閱方案的用量 — 為了在 VS Code 上使用，還得多架設一到兩個代理伺服器

Headroom 會在本機的代理伺服器裡壓縮 Claude Code 的請求。我在 2.1.292 版本上實測，訂閱方案的用量增減都在 5% 以內；換算成 API 價格，成本則少了 4% 到 16% 左右。

近乎黑色的卡片上的 Headroom 標誌，一對薄荷綠的方括號夾著兩條橫線，旁邊是同樣薄荷綠的 Headroom 字樣
本頁目錄

引言

我聽說 Headroom 可以減少 Claude Code 的 token 用量，在決定要不要導入之前，我想先弄清楚它的運作方式。我是在 VS Code 擴充功能裡使用 Claude Code，用的是訂閱方案，也接上了 claude.ai 的 connector。所以如果要在 API 前面放任何東西，我會優先考慮不要影響到這些 connector。

Headroom 會在本機的代理伺服器裡壓縮傳送給 API 的請求，而要把這個代理伺服器放在 Claude Code 和 API 之間的話，有兩種做法。

  1. 把 ANTHROPIC_BASE_URL 指向本機代理的 URL：ToolSearch 和 Remote Control 會被停用，Claude Code 顯示的脈絡使用量也會跟著膨脹。
  2. 使用正向代理伺服器，在連往 api.anthropic.com 的途中攔截：ToolSearch 等功能可以正常使用，但需要兩個代理伺服器。

在我的訂閱方案上，用量幾乎沒有變化，增減都在 5% 以內。Headroom 壓縮的內容大多已經被快取，而已快取的 token 幾乎不會消耗訂閱方案的額度。換算成 API 價格，同樣的執行會便宜 4% 到 16%，但付出的代價比得到的好處來得大得多，所以最終我決定不導入。這篇文章會說明這兩條路線，以及該如何取捨、在什麼情況下則應該導入。

Headroom 在請求路徑中的位置

Headroom 是一個開源的壓縮層，專門給 AI 代理在寫程式時使用，並且以 Python 套件 headroom-ai 發布。它會縮減傳送給模型的請求內容（工具 schema、工具輸出、日誌和對話紀錄）。原始資料則會備份在本機磁碟上，模型需要時可以透過 headroom_retrieve 工具調閱。

Headroom 必須在網路上攔截請求，因為 Claude Code 沒有提供任何機制讓外部工具改寫請求。hook 是 Claude Code 在特定時機自動執行的指令，例如 PreToolUse、PostToolUse、Stop，會在工具呼叫和對話回合的前後執行，但它們都沒辦法改寫 API 的請求主體。

所以要攔截對 Claude 的請求，有兩種方法。第一種方法（以下稱為路線一）是替換 Claude Code 送出請求的端點，Headroom 自己的設定指令用的就是這個做法：

終端機視窗
headroom proxy --port 8787
ANTHROPIC_BASE_URL=http://127.0.0.1:8787 claude

第二種方法（路線二）則不去更動端點，而是在連線送出的途中攔截。這裡還需要另一個工具，後面會另立一節說明。

在路線一中，代理伺服器會把 /v1/messages（呼叫模型的 API 路徑）轉送到 api.anthropic.com。訂閱方案的登入可以照常通過。經過代理伺服器的 session 和直接連線一樣回報 apiKeySource: none，表示沒有使用 API 金鑰，仍然是以訂閱帳號登入。所有請求也都正常成功了。

路線一：把 Headroom 設成 base URL以 VS Code 擴充功能或 CLI 執行的 Claude Code，會把請求送到 ANTHROPIC_BASE_URL 指定的 127.0.0.1 連接埠 8787。Headroom 代理伺服器在那裡壓縮工具 schema、工具輸出和對話紀錄，把原始資料備份在本機磁碟，再把 /v1/messages 轉送到 api.anthropic.com。下方是 Claude Code 對 base URL 的檢查。它發現端點不是 api.anthropic.com 之後，會關掉三項功能。Remote Control 拒絕啟動；ToolSearch 工具除非設定 ENABLE_TOOL_SEARCH=true，否則會消失；Artifact 工具也會消失。在 2.1.292 版中，/schedule 保留，claude.ai 的 connector 在 13 次中載入了 12 次。Claude CodeVS Code 擴充功能或 CLIANTHROPIC_BASE_URL127.0.0.1:8787Headroom 代理伺服器壓縮工具 schema工具輸出和對話紀錄原始資料備份在本機/v1/messagesapi.anthropic.comClaude Code 發現 base URL 不是 api.anthropic.com✕Remote Control 拒絕啟動✕ToolSearch 消失（設定 ENABLE_TOOL_SEARCH=true 可以恢復）✕Artifact 工具消失✓/schedule 保留，claude.ai 的 connector 在 13 次中載入了 12 次（2.1.292）
路線一。Claude Code 會把每個請求送到 ANTHROPIC_BASE_URL 指定的代理伺服器，由代理伺服器壓縮後再轉送到 api.anthropic.com。當 Claude Code 發現端點不是 Anthropic 的 URL 時，會關掉 Remote Control，以及 ToolSearch 和 Artifact 這兩個工具。

路線一：替換 ANTHROPIC_BASE_URL

Claude Code 會檢查 ANTHROPIC_BASE_URL 是否指向 api.anthropic.com，如果不是，就會關閉部分功能。我請 Claude Code 在 2.1.292 版上，分別以直接連線和經過代理伺服器的方式，各啟動一次相同的 headless session（不開啟互動介面、用 claude -p 執行的 session），再比較兩邊拿到的工具和指令。

直接連線經過代理伺服器
claude.ai 的 connector1313（13 次中有 12 次）
/schedule可以使用可以使用
ToolSearch 工具可以使用消失
Artifact 工具可以使用消失
Remote Control可以使用拒絕啟動

經過代理伺服器時，Remote Control 拒絕啟動，並說明了原因：

終端機視窗
輸入
ANTHROPIC_BASE_URL=http://127.0.0.1:8787 claude remote-control
輸出
Error: Remote Control is only available when using Claude via api.anthropic.com. ANTHROPIC_BASE_URL is set and does not point at api.anthropic.com, so this session is using a custom endpoint — unset it (or run in a shell without it) to use Remote Control.

ToolSearch 這個工具會在需要時才載入 MCP 的工具定義，而不是每次請求都把全部定義送出去。把 base URL 指向代理伺服器時，它會失效。只要設定 ENABLE_TOOL_SEARCH=true，即使 base URL 指向代理伺服器也能使用 ToolSearch，但 Artifact 工具仍然無法使用。

我測試了 13 次把 base URL 指向代理伺服器的 session，/schedule 每次都能使用。claude.ai 的 connector 則有 12 次能夠全部載入，只有一次啟動時完全沒有載入。我另外測試了 8 次不使用代理伺服器的 session，每次都能正常載入所有 connector。

base URL 指向代理伺服器時 /context 回報的數字會失真

/context 會顯示一個 session 用掉了多少脈絡視窗。經過代理伺服器時，這個數字比起沒有代理時上升到三倍以上：

組別/context 的總計MCP 的工具定義
直接連線47.4k107.7k 延後載入，不計入
經過代理伺服器156.1k已載入 109.1k
經過代理伺服器，並設定 ENABLE_TOOL_SEARCH=true191.5k已載入 137.9k

原本 ToolSearch 會只在需要時載入各個 MCP 工具的定義。然而把 base URL 指向代理伺服器之後，這項功能就被關閉了，Claude Code 會一開始就把所有 MCP 的工具定義納入脈絡視窗的計算。而且它是用 Headroom 壓縮之前的大小來計算，所以模型實際收到的 token 會比顯示的脈絡使用量少。即使設定了 ENABLE_TOOL_SEARCH=true，/context 回報的數字仍然會失真。

費用是依照模型實際收到的內容來計算的，不會受這個失真的數字影響，自動壓縮對話也一樣。我把自動壓縮的視窗設成 120k，讓顯示的脈絡使用量超過門檻，連續送出兩則訊息都沒有觸發壓縮。

用 wrap vscode-claude 讓 VS Code 擴充功能經過代理伺服器

headroom wrap claude 會先啟動代理伺服器，再啟動 Claude Code 的 CLI，並且只在這個 CLI 行程上設定 ANTHROPIC_BASE_URL，所以它只涵蓋終端機的 session。VS Code 擴充功能則會從 VS Code 的環境啟動自己的 Claude Code 執行檔，因此 Headroom 另外提供了一個專屬的子命令 headroom wrap vscode-claude。它的 --help 會顯示：

Usage: headroom wrap vscode-claude [OPTIONS]


  Route VS Code's official Claude Code extension through Headroom.


  Run this from your project, reload VS Code after first setup, and keep this
  command running while using Claude Code. Authentication and model selection
  remain unchanged. Run `headroom unwrap vscode-claude` to restore settings.

這個 wrapper 會在 Claude Code 的使用者設定 settings.json 做兩個修改：

  1. 把 ANTHROPIC_BASE_URL 指向 http://127.0.0.1:8787/p/<project>
  2. 將 ENABLE_TOOL_SEARCH 設為 "true"

使用者設定會套用到這台電腦上所有的 Claude Code session。因此只要這個檔案裡還留著 ANTHROPIC_BASE_URL，不管指令當初是在哪個專案執行的，每個 VS Code 視窗和每個終端機 session 都會經過代理伺服器。

Headroom 的文件寫著，代理伺服器停止時並不會切換回直接連線到 Anthropic（「A stopped proxy intentionally does not fall back to a direct Anthropic connection.」）。所以一旦 wrapper 的行程停止，這些 session 就全部無法連線。

路線二：不更動 base URL 的正向代理伺服器

正向代理伺服器會接手用戶端所有的對外連線，再代為轉送，透過 https_proxy 來設定。claude-rc-proxy 就是為這個用途寫的工具，作者在 Headroom 一則 issue 的留言裡分享了它。它只解密送往 api.anthropic.com 的連線，其他主機則以不讀取內容的原始通道直接轉送。

同時在送往 api.anthropic.com 的請求中，它也只把 /v1/messages 的請求交給本機的後端，也就是 Headroom。其他請求（包括 Remote Control 的橋接連線和 OAuth 呼叫）都會原封不動地送到 Anthropic。因為沒有設定 ANTHROPIC_BASE_URL，所以能通過 Claude Code 對 base URL 的檢查。

路線二：放在 Headroom 前面的正向代理伺服器Claude Code 在沒有設定 ANTHROPIC_BASE_URL 的情況下執行，所以能通過第一方檢查，並透過 https_proxy 把連線送到 127.0.0.1 連接埠 9801 上的 rc-proxy。rc-proxy 只解密送往 api.anthropic.com 的連線。它把 /v1/messages 請求交給連接埠 8787 上的 Headroom，由 Headroom 壓縮後轉送到 api.anthropic.com；Remote Control 和 OAuth 等其他請求，則直接送到 api.anthropic.com。其他主機（包括 connector 和遙測）都以原始通道直接轉送，不會被解密。Claude Code未設定 base URL✓ 通過檢查rc-proxy127.0.0.1:9801只解密送往api.anthropic.com 的連線Headroom127.0.0.1:8787壓縮請求api.anthropic.com推論、Remote Control、OAuthhttps_proxy/v1/messages其他所有請求壓縮後其他主機（包括 connector 和遙測）都以原始通道直接轉送，不會被解密。
路線二。Claude Code 仍然是送往 api.anthropic.com，所以能通過 Claude Code 對 base URL 的檢查。rc-proxy 只解密這條連線，把 /v1/messages 交給 Headroom，其他請求則送到 Anthropic。其他主機的連線不會被讀取，直接轉送。

我讓 Claude Code 讀了 rc-proxy 原始碼，發現按照公開的版本，它無法和 Headroom 搭配使用。因為這個工具是為模型 gateway 寫的，所以它會把請求的 Authorization 標頭換成 gateway 的 token，並把 /v1/messages 請求送到 gateway 所在的 127.0.0.1:8317。

要和 Headroom 搭配，就得在本機 fork 一份，把轉送目標改成 Headroom 的連接埠，並保留呼叫端自己的 token：

tools/rc-proxy/main.go
upstreamPool = "127.0.0.1:8317" // CLIProxyAPI
upstreamPool = "127.0.0.1:8787" // Headroom
// …
r.URL.Scheme, r.URL.Host = poolURL.Scheme, poolURL.Host
r.Header.Set("Authorization", "Bearer "+poolToken)

這份 fork 也拿掉了「沒有設定 gateway token 時就拒絕 /v1/messages 請求」的防護。rc-proxy 要解密連線，Claude Code 就得信任它簽發的憑證，所以我為這次測試製作了一個憑證授權單位（用來簽發 TLS 憑證的根憑證），並只透過 NODE_EXTRA_CA_CERTS 讓 Claude Code 的行程信任它。執行時也沒有設定 ANTHROPIC_BASE_URL：

終端機視窗
export https_proxy=http://127.0.0.1:9801 http_proxy=http://127.0.0.1:9801
export no_proxy=localhost,127.0.0.1,::1,datadoghq.com,statsig.com,sentry.io
export NODE_EXTRA_CA_CERTS=/tmp/rcproxy/ca/ca-cert.pem
rc-proxy 讀得到與讀不到的連線圖分成兩列。第一列中，Claude Code 透過 rc-proxy 連往 api.anthropic.com。rc-proxy 會出示本機憑證授權單位簽發的 api.anthropic.com 憑證，而 Claude Code 透過 NODE_EXTRA_CA_CERTS 信任這個憑證授權單位，所以第一條 TLS 連線會被解密。rc-proxy 把 /v1/messages 交給 Headroom，由 Headroom 壓縮後，用 Anthropic 真正的憑證建立第二條 TLS 連線到 api.anthropic.com。第二列中，Claude Code 請 rc-proxy 以 CONNECT 連往 gmailmcp.googleapis.com。rc-proxy 只會複製加密過的位元組，所以使用 Google 真正憑證的同一條 TLS 連線會從頭到尾直通，rc-proxy 讀不到其中的內容。api.anthropic.com：解密Claude Code信任本機的憑證授權單位rc-proxy假扮成api.anthropic.com並解密Headroom壓縮api.anthropic.comTLS 1/v1/messagesTLS 2TLS 1 · 本機憑證授權單位簽發的 api.anthropic.com 憑證，Claude Code 以為自己連上的是 AnthropicTLS 2 · Anthropic 真正的憑證其他主機：直接轉送Claude Coderc-proxy只轉送原始位元組gmailmcp.googleapis.comGoogle 真正的憑證CONNECT已加密從 Claude Code 到 Google 的同一條 TLS 連線rc-proxy 只讀取 CONNECT 裡的主機名稱，因此無法解密這段流量。
rc-proxy 用本機憑證授權單位簽發的憑證假扮成 api.anthropic.com，Claude Code 因為信任這個憑證授權單位而接受它。其他主機的連線，rc-proxy 只會轉送它讀不到的加密位元組。

我在同一個 shell 裡，比較了直接連線的 session 和經過這兩個代理伺服器的 session：

直接連線路線二
claude.ai 的 connector8 次中 8 次都有 13 個9 次中 9 次都有 13 個
/schedule可以使用可以使用
ToolSearch 工具可以使用可以使用
/context 的總計32.3k33.7k
apiKeySourcenonenone

在我能測量的範圍內，使用路線二不會失去任何東西。MCP 的工具定義仍然是延後載入，所以顯示的脈絡使用量和直接連線的 session 一樣。Headroom 的日誌顯示它收到了 12 次 /v1/messages 請求，全部都成功了。

Headroom 替請求省下了多少

我分別對路線一及路線二進行了測試，每個路線都以數種連線方式（以下稱為組別）進行測試，讓它們在相同的時間內測量。路線一有三個組別，分別是直接連線、把 base URL 指向代理伺服器，以及再加上 ENABLE_TOOL_SEARCH=true。路線二則有兩個組別，分別是直接連線和經過兩個代理伺服器。

路線一的 21 次是我讓 Claude Code 在它自己的 shell 裡執行的，路線二的 16 次則是我在自己的終端機裡執行的。提示詞有兩種，一種只要求回覆一行，另一種會執行 git log --stat -40 再讀取它的輸出。所有組別的回答都一致。

基準測試的執行順序兩條時間軸。路線一是我讓 Claude Code 在它自己的 shell 裡執行的 21 次：一行提示詞跑了 5 輪，每一輪都讓直接連線、base URL 指向代理伺服器、再加上 ENABLE_TOOL_SEARCH 這三個組別各執行一次；接著 git log 提示詞跑了 3 輪，每一輪讓直接連線和再加上 ENABLE_TOOL_SEARCH 的組別各執行一次。路線二是我在自己的終端機裡執行的 16 次：一行提示詞跑了 5 輪，git log 提示詞跑了 3 輪，每一輪都讓直接連線和經過 rc-proxy 送到 Headroom 的組別各執行一次。每次執行的用量都取自 claude -p --output-format stream-json 輸出的最後一行，每個組別取中位數。路線一 · 我讓 Claude Code 在它自己的 shell 裡執行 · 21 次一行提示詞直接連線base URL → 代理伺服器+ ToolSearch× 5 輪git log --stat直接連線+ ToolSearch× 3 輪路線二 · 我在自己的終端機裡執行 · 16 次一行提示詞直接連線rc-proxy → Headroom× 5 輪git log --stat直接連線rc-proxy → Headroom× 3 輪每次執行的用量都取自 claude -p --output-format stream-json 輸出的最後一行，每個組別取中位數。
各次執行的輪流方式。每一輪裡每個組別都會各執行一次，下一輪才開始，所以所有組別都在相同的時間內測量。

每次執行都用同一個指令，輸出的最後一行會帶有用量。兩條路線的差別只在環境變數：

路線一
ANTHROPIC_BASE_URL=http://127.0.0.1:8787 claude -p "Reply with exactly: OK" \
  --output-format stream-json --verbose
路線二
https_proxy=http://127.0.0.1:9801 NODE_EXTRA_CA_CERTS=/tmp/rcproxy/ca/ca-cert.pem \
  claude -p "Reply with exactly: OK" --output-format stream-json --verbose

什麼會消耗 Claude Code 訂閱方案的額度？

訂閱方案沒有按 token 計費，所以重點是一個 session 會多快用完額度。Anthropic 的使用額度建議提到，提示詞中已快取的部分對額度的影響比新內容少（「count less against your limits than new content」），但沒有公布權重。一個追蹤訂閱方案帳號的第三方網站則用迴歸分析估計，一次快取讀取幾乎不會消耗額度（「close to none」）。

測試一：一行提示詞與 git log --stat

照這個說法，在訂閱方案上衡量 Headroom 節約 token 的效果時，應該要看的是未快取的輸入加上快取寫入，並且不包括快取讀取：

提示詞路線直接連線經過 Headroom變化
一行路線一，沒有 ToolSearch16,24511,220−31%
一行路線一，恢復 ToolSearch16,24516,993+5%
git log --stat路線一，恢復 ToolSearch18,43417,779−4%
一行路線二13,63612,989−5%
git log --stat路線二17,27117,118−1%

只要保留了 ToolSearch，訂閱方案的用量就只在 −5% 到 +5% 之間變動，落在同一組別各次執行之間的誤差範圍內。光是路線一的直接連線，一行提示詞的數字就從 14,090 到 17,452 不等。

唯一大幅減少的，是路線一中失去 ToolSearch 的組別，少了 31%。這是因為載入的工具定義變少了，而不是因為壓縮。

測試二：含有大量工具輸出的八回合 session

一行提示詞的內容大多是固定的前綴，所以我另外執行了一個更接近實際使用情境的工作負載測試。每個 session 有八個回合，每個回合都會讀取一個大檔案，或執行一個輸出很長的指令。每個組別都在我的終端機裡輪流執行了兩次。

組別第一輪第二輪兩輪平均和直接連線相比
直接連線40.9k44.8k—
路線一，恢復 ToolSearch34.0k37.2k−17%
路線二46.1k39.1k約 0%

表中加總了第 2 到第 8 回合的訂閱方案下的 token 使用量（未快取的輸入加上快取寫入）。第一個回合會寫入 session 的快取前綴，它的大小會依快取是否還有效而有變化，從 16k 到 57k 不等。因此這一回合沒有計入。

Headroom 幾乎沒有壓縮工具輸出。在它回報的 76 次請求中，訊息內容只縮減了 1.9%。它 12% 的整體節省大多來自工具 schema（344,690 個 token），而這部分都在已快取的前綴裡，因此沒有太大的節省效果。

路線一的 17% 只是兩次對兩次的比較，而路線二經過同一個 Headroom、送出同樣的請求，卻幾乎沒有省下任何使用量。所以我認為這是每次執行之間的誤差，而不是實際壓縮的效果。

換算成 API 價格的話

在 API 價格下，快取讀取的價格是正常輸入單價的十分之一，所以壓縮已快取的前綴多少能省一點。以下是用 API 價格重新計算測試一的結果。輸入 token 總數是以模型收到的所有 token 來計算。加權成本則依照已快取前綴的計費方式計價，快取寫入以基本輸入單價的 1.25 倍計算，快取讀取以 0.1 倍計算。

路線一：

提示詞組別次數輸入 token 總數加權成本
一行直接連線559,21824,603
一行經過代理伺服器，沒有 ToolSearch535,96316,499
一行經過代理伺服器，恢復 ToolSearch540,82523,727
git log --stat直接連線3121,07739,338
git log --stat經過代理伺服器，恢復 ToolSearch3113,32333,154

路線二：

提示詞組別次數輸入 token 總數加權成本
一行直接連線544,55020,153
一行路線二537,98518,735
git log --stat直接連線394,31329,100
git log --stat路線二381,25527,822

每個數字都是該組別各次執行的中位數。兩條路線的測試分別在不同的 shell 裡執行，載入的工具也不一樣，所以每條路線只能和自己那一批的直接連線比較。路線一中沒有 ToolSearch 的組別加權成本少了 33%，看起來最便宜，但代價是少載入了一個工具。

經過代理伺服器的請求相對於直接連線的比例（依路線）五組比較，各自和同一批的直接連線相比，並以輸入 token 總數、加權成本，以及不計快取讀取的訂閱方案用量表示。路線一中沒有 ToolSearch 的一行提示詞，token 是 61%，成本是 67%，訂閱方案用量是 69%。路線一中恢復 ToolSearch 的一行提示詞，token 是 69%，成本是 96%，訂閱方案用量是 105%。路線一中恢復 ToolSearch 的 git log 提示詞，token 是 94%，成本是 84%，訂閱方案用量是 96%。路線二的一行提示詞，token 是 85%，成本是 93%，訂閱方案用量是 95%。路線二的 git log 提示詞，token 是 86%，成本是 96%，訂閱方案用量是 99%。輸入 token 總數加權成本訂閱方案的用量直接連線 = 100%路線一・一行提示詞沒有 ToolSearch61%67%69%路線一・一行提示詞恢復 ToolSearch69%96%105%路線一・git log --stat恢復 ToolSearch94%84%96%路線二・一行提示詞正向代理伺服器85%93%95%路線二・git log --stat正向代理伺服器86%96%99%
測試一中，各條路線以同一批的直接連線為基準的比例。只要保留了 ToolSearch，訂閱方案的用量和直接連線相差不到 5%，換算成 API 價格的成本則減少 4% 到 16%。

減少的 token 大多落在已快取的前綴上，而這部分本來就只以十分之一的價格計費。以一行提示詞來說，恢復 ToolSearch 的路線一雖然少了 31% 的 token，成本只少了 4%。路線二則少了 15% 的 token、7% 的成本。

Headroom 自己的日誌報告說，路線一那一批減少了 36.5%，路線二那一批減少了 15.0%。但這些數字只考慮 token 數，沒有考慮已快取的 token 比較便宜。

為什麼我不推薦導入 Headroom？

在訂閱方案上，Headroom 讓用量增減的幅度都在 5% 以內，兩條路線卻都要付出代價，所以我不推薦導入。

路線一的代價是功能：

  1. Remote Control 拒絕啟動。
  2. 沒有設定 ENABLE_TOOL_SEARCH=true 的話，ToolSearch 會消失；Artifact 工具則不論如何都會消失。
  3. Claude Code 顯示的脈絡使用量，是模型實際收到的請求的三到四倍。
  4. 在 13 次經過代理伺服器的執行中，有一次 claude.ai 的 connector 沒有連上。

路線二保留了這些功能，代價則是信任：

  1. 本機的一個行程會解密所有送往 api.anthropic.com 的連線，包括 OAuth token。
  2. 要和 Headroom 搭配，就得 fork 一個第三方工具，之後也得自己維護這份 fork。
  3. 只要 Anthropic 加上憑證釘選（讓 Claude Code 只接受 Anthropic 自己的憑證），它就會失效。

不管是哪一條路線，這台電腦上所有的 Claude Code session 都得依賴本機的代理伺服器持續執行，而路線二在這條路上放了兩個代理伺服器。

Headroom 的 README 寫著 JSON 可以省下 60% 到 95%，但這個情況很少發生在 Claude Code 上。我讓 Claude Code 執行 36 次會輸出 JSON 的指令，其中 31 次它都自己先用 jq 篩過，原始的 JSON 沒有進到脈絡裡。在我過去 195 個 session 中，JSON 也只占工具輸出的 2% 左右。

總結

  • Claude Code 的 hook 沒辦法用來改寫 API 的請求主體，所以 Headroom 是利用在本機的代理伺服器來壓縮請求。
  • 路線一是替換 ANTHROPIC_BASE_URL。在 2.1.292 上，它會關掉 Remote Control、ToolSearch 和 Artifact 工具，並且會讓 /context 的數字膨脹；ENABLE_TOOL_SEARCH=true 能讓 ToolSearch 恢復但 Artifact 仍然不能用。
  • 路線二是 claude-rc-proxy 這類正向代理伺服器。它保留了 connector、/schedule、ToolSearch 並且正確反映了 /context 的數字，但這個方法需要 fork 並維持一個第三方工具。
  • 在訂閱方案上，保留 ToolSearch 之後，不管是一行提示詞還是含有大量工具輸出的 session，用量的增減都在 5% 以內，而且減少的 token 大多落在已快取的前綴上，這部分幾乎不會消耗額度。換算成 API 價格，大概會便宜 4% 到 16%。
  • Claude Code 通常會先用 jq 篩過 JSON，所以 README 宣稱的 60% 到 95% 很難派上用場。兩條路線最終都很難實現真正意義上的用量節省，所以我不推薦導入 Headroom。

只要測試 claude -p --output-format stream-json 的輸出，就能在做決定之前做比較。init 那一行列出這次 session 有哪些工具，usage 那一行列出用掉的 token。歡迎自行嘗試。

參考連結

分享這篇文章

更多

更多