HeadroomはClaude Codeのサブスクリプションの使用量をほとんど減らさない — VS Codeでは1〜2個のプロキシが必要

HeadroomはClaude Codeのリクエストをローカルのプロキシで圧縮します。2.1.292で測ると、サブスクリプションの使用量の変化は前後5%以内で、API料金なら4〜16%減でした。

黒に近いカードに、ミントグリーンの角括弧が横棒2本を挟んだHeadroomのロゴと、同じミントグリーンのHeadroomという文字
目次

はじめに

HeadroomでClaude Codeのトークン使用量を減らせると聞き、導入するか決める前に仕組みを知りたくなりました。私のClaude CodeはサブスクリプションでVS Code拡張機能として動いていて、claude.aiのコネクタもつないでいます。そのため、APIの手前に何かを置くなら、コネクタには手を出さないものである必要がありました。

Headroomはローカルのプロキシでリクエストを圧縮します。このプロキシをClaude CodeとAPIの間に置く方法は2通りあります。ANTHROPIC_BASE_URLをプロキシに向けると、ToolSearchとRemote Controlが止まり、コンテキストメーターの値も膨らみます。代わりにapi.anthropic.comへの接続を途中で横取りするフォワードプロキシを使うと、測れた範囲の機能はすべて残りましたが、プロキシが2つ必要です。

私のサブスクリプションでは、使用量はほとんど変わりませんでした。増減は5%以内です。Headroomが圧縮するものの大半はキャッシュ済みで、キャッシュ済みのトークンはサブスクリプションの上限にほとんど効かないからです。API料金で換算すると同じ実行は4〜16%安くなりますが、どちらのルートでも払うコストのほうがはるかに大きいため、私は導入しないことにしました。この記事では、2つのルートと、このトレードオフが割に合う場面を説明します。

Headroomはリクエストの経路のどこに入るのか？

Headroomはコーディングエージェント向けのオープンソースの圧縮レイヤーで、Pythonパッケージheadroom-aiとして公開されています。モデルへのリクエストに入るもの（ツールスキーマ、ツール出力、ログ、会話履歴）を縮め、元のデータはディスクに残します。モデルはheadroom_retrieveツールで元データを取り戻せます。

ネットワークの経路に入る必要があるのは、Claude Codeの内部にはリクエストを書き換えられる仕組みがないからです。フックとは、Claude Codeが決まったタイミングで自動的に実行するコマンドです。PreToolUse、PostToolUse、Stopなどのフックはツール呼び出しやターンの前後で動きますが、どれもAPIのリクエストボディを受け取りません。

入り方は2つです。ルート1は、Claude Codeの送信先のエンドポイントを差し替える方法で、Headroom自身のセットアップコマンドもこの方法を使います。

ターミナルウィンドウ
headroom proxy --port 8787
ANTHROPIC_BASE_URL=http://127.0.0.1:8787 claude

ルート2は、エンドポイントはそのままにして、外に出ていく接続を途中で横取りする方法です。こちらは別のツールが必要なので、後の節で扱います。

ルート1では、プロキシは/v1/messages（モデルを呼び出すAPIのパス）をapi.anthropic.comに転送します。サブスクリプションのサインインはそのまま通ります。プロキシ経由のセッションも直接接続と同じくapiKeySource: noneを報告しました。これは、APIキーを使わず、サブスクリプションのアカウントでサインインしたままだという意味です。リクエストはすべて成功しました。

ルート1：HeadroomをベースURLにするVS Code 拡張機能または CLI として動く Claude Code は、ANTHROPIC_BASE_URL に書かれた 127.0.0.1 のポート 8787 にリクエストを送ります。そこで Headroom プロキシがツールスキーマ、ツール出力、会話履歴を圧縮し、元データをディスクに残して、/v1/messages を api.anthropic.com に転送します。下では Claude Code がベース URL を確認し、api.anthropic.com ではないため3つの機能を止めます。Remote Control は起動せず、ToolSearch ツールは ENABLE_TOOL_SEARCH=true を設定しない限り消え、Artifact ツールも消えます。バージョン 2.1.292 では /schedule は残り、claude.ai のコネクタは13回中12回読み込まれました。Claude CodeVS Code 拡張機能または CLIANTHROPIC_BASE_URL127.0.0.1:8787Headroom プロキシツールスキーマ・ツール出力・会話履歴を圧縮し、元データはディスクに保存/v1/messagesapi.anthropic.comClaude CodeがベースURLはapi.anthropic.comではないと判定✕Remote Control が起動しない✕ToolSearch が消える（ENABLE_TOOL_SEARCH=true で戻る）✕Artifact ツールが消える✓/schedule は残り、claude.ai のコネクタは13回中12回読み込まれた（2.1.292）
ルート1。Claude Codeは各リクエストをANTHROPIC_BASE_URLに書かれたプロキシに送り、プロキシが圧縮してapi.anthropic.comに転送します。Anthropic以外のURLだと判断したClaude Codeは、Remote Control、ToolSearch、Artifactツールも止めます。

ルート1：ANTHROPIC_BASE_URLを差し替える

Claude CodeはANTHROPIC_BASE_URLがapi.anthropic.comを指しているかを確認し、指していなければ一部の機能を止めます。私はClaude Codeに、バージョン2.1.292で同じヘッドレスセッション（対話画面を開かずclaude -pで動かすセッション）を直接接続とプロキシ経由で1回ずつ起動し、それぞれが受け取ったツールとコマンドを比べるよう頼みました。

直接接続プロキシ経由
claude.aiのコネクタ1313（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のツール定義を毎回すべて送る代わりに、必要になったときに読み込むツールです。ENABLE_TOOL_SEARCH=trueを設定すればプロキシ経由でも戻りますが、Artifactツールは戻りません。

/scheduleはプロキシ経由のすべてのセッションにあり、13個のコネクタはプロキシ経由の13回中12回でそろっていました。残る1回はclaude.aiのコネクタがひとつもない状態で起動し、これは直接接続の8回では一度も起きていません。

ベースURLをプロキシに向けると/contextの値がずれる

/contextは、セッションがコンテキストウィンドウをどれだけ使っているかを表示します。プロキシ経由では、この値が3倍以上に増えました。

条件/contextの合計MCPのツール定義
直接接続47.4k107.7kは遅延読み込みで、計上されない
プロキシ経由156.1k109.1kを読み込み済み
プロキシ経由、ENABLE_TOOL_SEARCH=true191.5k137.9kを読み込み済み

ツール定義の読み込みを遅らせるのはToolSearchの役目です。ベースURLのチェックがこれを止めるため、Claude CodeはMCPのツール定義をすべて最初から読み込み済みとして数えます。しかもHeadroomが圧縮する前の大きさで数えるため、モデルが実際に受け取るトークンはメーターの表示より少なくなります。ENABLE_TOOL_SEARCH=trueを設定しても、遅延読み込みの行は戻りませんでした。

料金はモデルが実際に受け取った内容で決まるので、この膨らんだ値に費用はかかりません。自動コンパクトもこの値には左右されません。自動コンパクトのウィンドウを120kに設定し、表示上の使用量がしきい値を超える状態にしても、2回続けてメッセージを送ってコンパクトは起きませんでした。

wrap vscode-claudeでVS Code拡張機能を経由させる

headroom wrap claudeはプロキシを起動し、その1つのプロセスにだけANTHROPIC_BASE_URLを設定してClaude CodeのCLIを立ち上げます。対象になるのはターミナルのセッションだけです。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.

このラッパーは、Claude Codeのユーザー設定のsettings.jsonに2つの項目を書き込みます。http://127.0.0.1:8787/p/<project>を指すANTHROPIC_BASE_URLと、"true"に設定したENABLE_TOOL_SEARCHです。ユーザー設定はそのマシンのすべてのClaude Codeセッションに適用されます。そのため、このファイルに項目が残っている間は、すべてのVS Codeウィンドウとターミナルのセッションがプロキシを通ります。コマンドをどのプロジェクトで実行したかは関係ありません。

Headroomのドキュメントには、プロキシが止まってもAnthropicへの直接接続には切り替わらないと書かれています（「A stopped proxy intentionally does not fall back to a direct Anthropic connection.」）。そのため、ラッパーのプロセスが止まると、それらのセッションはすべて接続できなくなります。

ルート2：ベースURLを変えないフォワードプロキシ

フォワードプロキシとは、クライアントが外向きの接続をすべて預ける先のプロキシで、https_proxyで設定します。Headroomのissueへのコメントで紹介されたclaude-rc-proxyは、まさにこの用途のためのものです。復号するのはapi.anthropic.comへの接続だけで、それ以外のホストは中身を読まない生のトンネルで素通しします。

その接続の中でも、ローカルのバックエンドに回すのは/v1/messagesへのリクエストだけです。Remote ControlのブリッジやOAuthの呼び出しを含むそれ以外は、そのまま本物のAnthropicに届きます。ANTHROPIC_BASE_URLは設定しないままなので、ファーストパーティのチェックを通過します。

ルート2：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に送ります。それ以外のホストは、コネクタやテレメトリも含めて生のトンネルで素通しし、復号しません。Claude CodeベースURLは未設定✓ チェックを通過rc-proxy127.0.0.1:9801復号するのはapi.anthropic.comだけHeadroom127.0.0.1:8787リクエストを圧縮api.anthropic.com推論、Remote Control、OAuthhttps_proxy/v1/messagesその他すべて圧縮済みそれ以外のホスト（コネクタやテレメトリを含む）は、生のトンネルで素通しし、復号しません。
ルート2。Claude Codeは引き続きapi.anthropic.comに送るので、チェックを通過します。rc-proxyはその接続だけを復号し、/v1/messagesをHeadroomに渡して、それ以外はAnthropicに送ります。ほかのホストは中身を読まずに素通しします。

何かを動かす前にClaude Codeがソースを読み、公開されている状態ではHeadroomと組み合わせて使えないことが分かりました。モデルゲートウェイ向けに作られているため、リクエストのAuthorizationヘッダーをゲートウェイのトークンに差し替え、/v1/messagesのリクエストをゲートウェイがいる127.0.0.1:8317に送ります。

Headroomと組み合わせるには、送り先をHeadroomのポートに変え、呼び出し元のトークンをそのまま残すようにローカルでフォークする必要がありました。

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)

このフォークでは、ゲートウェイのトークンが設定されていないときに/v1/messagesのリクエストを拒否するガードも外しています。rc-proxyが接続を復号するには、Claude Codeがrc-proxyの署名した証明書を信頼する必要があります。そこでテスト用に認証局（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が読める接続と読めない接続2段の図です。上の段では、Claude Codeがrc-proxy経由でapi.anthropic.comに接続します。rc-proxyはローカルの認証局が署名したapi.anthropic.comの証明書を提示し、Claude CodeはNODE_EXTRA_CA_CERTSでその認証局を信頼しているため、1本目のTLS接続は復号されます。rc-proxyは/v1/messagesをHeadroomに渡し、Headroomが圧縮して、Anthropicの本物の証明書で2本目のTLS接続をapi.anthropic.comに張ります。下の段では、Claude Codeがgmailmcp.googleapis.comへのCONNECTをrc-proxyに頼みます。rc-proxyは暗号化されたバイトをコピーするだけなので、Googleの本物の証明書による1本のTLS接続が端から端までつながり、rc-proxyはその中身を読めません。api.anthropic.com：復号するClaude Codeローカルの認証局を信頼rc-proxyapi.anthropic.comになりすまし復号するHeadroom圧縮api.anthropic.comTLS 1/v1/messagesTLS 2TLS 1 · ローカルの認証局が署名したapi.anthropic.comの証明書。Claude CodeはAnthropicにつながっていると思い込むTLS 2 · Anthropicの本物の証明書その他のホスト：素通しClaude Coderc-proxyバイトをコピーするだけgmailmcp.googleapis.comGoogleの本物の証明書CONNECT暗号化済みClaude CodeからGoogleまで、1本のTLS接続rc-proxyが読むのはCONNECTのホスト名だけなので、この通信は復号できません。
rc-proxyはローカルの認証局が署名した証明書でapi.anthropic.comになりすまし、Claude Codeはその認証局を信頼しているので受け入れます。それ以外のホストでは、rc-proxyは読めない暗号化済みのバイトを中継するだけです。

同じシェルから、直接接続のセッションと、2つのプロキシを通したセッションを比べました。

直接接続ルート2
claude.aiのコネクタ8回中8回で13個9回中9回で13個
/schedule使える使える
ToolSearchツール使える使える
/contextの合計32.3k33.7k
apiKeySourcenonenone

測れた範囲では、失われたものはありませんでした。MCPのツール定義は遅延読み込みのままだったので、メーターは直接接続のセッションと同じ値を示します。Headroomのログには/v1/messagesへのリクエストが12回届き、失敗は0回でした。推論は確かにHeadroomを通っています。

リクエストで減った量

ルート1とルート2は別々のバッチで測定しました。各バッチではいくつかの接続方法（以下、条件と呼びます）を交互に回し、同じ数分間に測っています。ルート1の条件は、直接接続、ベースURLをプロキシに向けたもの、さらにENABLE_TOOL_SEARCH=trueを加えたものの3つです。ルート2は、直接接続と、2つのプロキシを通したものの2つです。

ルート1の21回はClaude Codeが自分のシェルで実行し、ルート2の16回は私が自分のターミナルで実行しました。プロンプトは2種類で、一方は1行の返答だけを求め、もう一方はgit log --stat -40を実行してその出力を読ませます。どの条件でも、答えはすべて一致しました。

ベンチマークの実行の回し方2本のタイムラインです。ルート1はClaude Codeが自分のシェルで実行した21回で、1行のプロンプトを5ラウンド、各ラウンドで直接接続、ベースURLをプロキシに向けた条件、ENABLE_TOOL_SEARCHを加えた条件を1回ずつ実行し、続いてgit logのプロンプトを3ラウンド、各ラウンドで直接接続とENABLE_TOOL_SEARCHを加えた条件を1回ずつ実行しています。ルート2は私がターミナルで実行した16回で、1行のプロンプトを5ラウンド、git logのプロンプトを3ラウンド、各ラウンドで直接接続とrc-proxy経由でHeadroomに送る条件を1回ずつ実行しています。各回の使用量はclaude -p --output-format stream-jsonの出力の最後の行から取り、条件ごとに中央値を出しています。ルート1 · Claude Codeが自分のシェルで実行 · 21回1行のプロンプト直接接続ベースURL → プロキシ＋ ToolSearch× 5ラウンドgit log --stat直接接続＋ ToolSearch× 3ラウンドルート2 · 私が自分のターミナルで実行 · 16回1行のプロンプト直接接続rc-proxy → Headroom× 5ラウンドgit log --stat直接接続rc-proxy → Headroom× 3ラウンド各回の使用量はclaude -p --output-format stream-jsonの出力の最後の行から取り、条件ごとに中央値を出しています。
実行の回し方。各ラウンドで全条件を1回ずつ実行してから次のラウンドに進むので、どの条件も同じ数分間に測られます。

各回は1つのコマンドで実行し、出力の最後の行に使用量が入ります。2つのルートの違いは環境変数だけです。

ルート1
ANTHROPIC_BASE_URL=http://127.0.0.1:8787 claude -p "Reply with exactly: OK" \
  --output-format stream-json --verbose
ルート2
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

サブスクリプションの上限に効くもの

サブスクリプションにはトークン単位の請求がないので、問題になるのはセッションが上限をどれだけ早く使い切るかです。Anthropicの使用上限に関するガイドは、プロンプトのキャッシュ済みの部分は「count less against your limits than new content」（新しい内容よりも上限への影響が少ない）と説明していますが、重みは公表していません。サブスクリプションのアカウントを追跡している第三者のサイトは、回帰分析から、キャッシュ読み取りは上限を「close to none」（ほぼ消費しない）と推定しています。

テスト1：1行のプロンプトとgit log --stat

これをそのまま受け取ると、サブスクリプションで見るべき値は、キャッシュ読み取りを除いた、キャッシュされない入力とキャッシュ書き込みの合計です。

プロンプトルート直接接続Headroom経由変化
1行ルート1、ToolSearchなし16,24511,220−31%
1行ルート1、ToolSearchあり16,24516,993+5%
git log --statルート1、ToolSearchあり18,43417,779−4%
1行ルート213,63612,989−5%
git log --statルート217,27117,118−1%

ToolSearchが残る条件では、サブスクリプションの使用量の変化は−5%から+5%の範囲でした。これは同じ条件の実行どうしのばらつきの中に収まります。ルート1の直接接続だけでも、1行のプロンプトで14,090から17,452まで幅がありました。

大きく減ったのは、ToolSearchを失ったルート1の条件の31%だけです。これは圧縮ではなく、読み込むツール定義が減ったことによるものです。

テスト2：ツール出力の多い8ターンのセッション

1行のプロンプトは中身のほとんどが固定のプレフィックスなので、実際の使い方に近いワークロードも測りました。各セッションは8ターンで、どのターンも大きなファイルを読むか、出力の長いコマンドを実行します。各条件を私のターミナルで交互に2回ずつ実行しました。

条件1回目2回目2回の平均（直接接続比）
直接接続40.9k44.8k—
ルート1、ToolSearchあり34.0k37.2k−17%
ルート246.1k39.1kほぼ0%

数値は、2〜8ターン目のサブスクリプションの使用量（キャッシュされない入力とキャッシュ書き込みの合計）です。1ターン目はセッションのキャッシュ済みプレフィックスを書き込むターンで、キャッシュがまだ有効かどうかで16kから57kまで振れたため、除いています。

Headroomはツール出力をほとんど圧縮しませんでした。報告された76回のリクエスト全体で、メッセージの内容は1.9%しか縮んでいません。12%という全体の削減の大半はツールスキーマの344,690トークンで、これはキャッシュ済みのプレフィックスにあるため、上限に効く削減はほとんどありません。

ルート1の17%は2回対2回の比較にすぎず、ルート2は同じHeadroomに同じリクエストを送りながら、ほとんど減っていません。そのため、これは圧縮の効果ではなく実行ごとのばらつきだと判断しています。

API料金で見た場合

API料金では、キャッシュ読み取りにも入力単価の10分の1がかかるため、キャッシュ済みのプレフィックスを圧縮すれば多少は安くなります。以下は、テスト1の結果をAPI料金で計算し直したものです。入力トークンの合計は、モデルが受け取ったすべてのトークンを数えたものです。重み付きコストは、キャッシュ済みのプレフィックスの課金方法に合わせてトークン数を換算したものです。キャッシュ書き込みは基本の入力単価の1.25倍、キャッシュ読み取りは0.1倍で計算しています。

ルート1：

プロンプト条件回数入力トークンの合計重み付きコスト
1行直接接続559,21824,603
1行プロキシ経由、ToolSearchなし535,96316,499
1行プロキシ経由、ToolSearchあり540,82523,727
git log --stat直接接続3121,07739,338
git log --statプロキシ経由、ToolSearchあり3113,32333,154

ルート2：

プロンプト条件回数入力トークンの合計重み付きコスト
1行直接接続544,55020,153
1行ルート2537,98518,735
git log --stat直接接続394,31329,100
git log --statルート2381,25527,822

どの値も、その条件の各回の中央値です。2つの直接接続の値が違うのは、バッチごとに別のシェルで、読み込まれたツールも違ったためです。それぞれのルートは、同じバッチの直接接続とだけ比べてください。ルート1でToolSearchなしの条件は33%減でいちばん安く見えますが、その分ツールが1つ欠けています。

プロキシ経由のリクエストを直接接続と比べた割合（ルート別）5つの比較を、それぞれ同じバッチの直接接続と比べ、入力トークンの合計、重み付きコスト、キャッシュ読み取りを除いたサブスクリプションの使用量で示しています。ルート1でToolSearchなしの1行のプロンプトは、トークンが61%、コストが67%、サブスクリプションの使用量が69%です。ルート1でToolSearchありの1行のプロンプトは、トークンが69%、コストが96%、サブスクリプションの使用量が105%です。ルート1でToolSearchありのgit logのプロンプトは、トークンが94%、コストが84%、サブスクリプションの使用量が96%です。ルート2の1行のプロンプトは、トークンが85%、コストが93%、サブスクリプションの使用量が95%です。ルート2のgit logのプロンプトは、トークンが86%、コストが96%、サブスクリプションの使用量が99%です。入力トークンの合計重み付きコストサブスクリプションの使用量直接接続 = 100%ルート1・1行のプロンプトToolSearch なし61%67%69%ルート1・1行のプロンプトToolSearch あり69%96%105%ルート1・git log --statToolSearch あり94%84%96%ルート2・1行のプロンプトフォワードプロキシ85%93%95%ルート2・git log --statフォワードプロキシ86%96%99%
テスト1の各ルートを、それぞれのバッチの直接接続を基準にした割合で示しています。ToolSearchが残る条件では、サブスクリプションの使用量は直接接続との差が5%以内に収まり、API料金で換算したコストは4〜16%減ります。

削れたトークンのほとんどは、もともと10分の1の値段で課金されるキャッシュ済みのプレフィックスの分です。1行のプロンプトでは、ToolSearchありのルート1はトークンを31%減らしても、コストは4%しか減りませんでした。ルート2はトークンを15%、コストを7%減らしました。

Headroom自身のレポートでは、削減率はルート1のバッチで36.5%、ルート2のバッチで15.0%でした。ただし、これはトークン数だけを数えた値で、キャッシュ済みのトークンが安いことは考慮されていません。

Headroomの導入をおすすめしない理由

サブスクリプションでは、Headroomによる使用量の増減はどちらの方向にも5%以内で、どちらのルートにもコストがかかるため、導入はおすすめしません。

ルート1で失うのは機能です。

  1. Remote Controlが起動を拒否する。
  2. ENABLE_TOOL_SEARCH=trueを設定しない限りToolSearchが消え、Artifactツールは設定に関係なく消える。
  3. コンテキストメーターが、モデルの受け取るリクエストの3〜4倍の大きさを表示する。
  4. プロキシ経由の13回中1回で、claude.aiのコネクタがつながらなかった。

ルート2は機能を残す代わりに、信頼を差し出します。

  1. ローカルのプロセスが、OAuthトークンを含むapi.anthropic.comへのすべての接続を復号する。
  2. Headroomと組み合わせるには第三者のツールをフォークする必要があり、そのフォークは自分で保守することになる。
  3. Anthropicが証明書ピンニング（Claude CodeがAnthropic自身の証明書しか受け付けない仕組み）を導入した日に動かなくなる。

どちらのルートでも、マシン上のすべてのClaude Codeセッションがローカルのプロキシの稼働に依存します。ルート2では、その経路にプロキシが2つ入ります。

HeadroomのREADMEはJSONで60〜95%の削減をうたっていますが、Claude Codeではその場面がほとんど生まれません。JSONを出力するコマンドをClaude Codeに36回実行させたところ、31回は自分でjqに通して絞り込んでおり、生のJSONはコンテキストに入りませんでした。過去195セッションを見ても、ツール出力に占めるJSONは2%程度です。

まとめ

  • Claude Codeのフックではリクエストボディを書き換えられないため、Headroomはローカルのプロキシでリクエストを圧縮します。
  • ルート1はANTHROPIC_BASE_URLの差し替えです。2.1.292ではRemote Control、ToolSearch、Artifactツールが止まり、/contextの値も膨らみます。ENABLE_TOOL_SEARCH=trueでToolSearchは戻りますが、Artifactツールは使えないままです。
  • ルート2はclaude-rc-proxyのようなフォワードプロキシです。コネクタ、/schedule、ToolSearchが残り、/contextの値も正しく出ますが、第三者のツールをフォークして保守する必要があります。
  • サブスクリプションでは、ToolSearchを残した状態で、1行のプロンプトでもツール出力の多いセッションでも、使用量の変化は前後5%以内でした。しかも削れたトークンのほとんどはキャッシュ済みのプレフィックスの分で、上限にはほとんど効きません。API料金に換算すると、4〜16%ほど安くなります。
  • Claude CodeはたいていJSONを先にjqで絞り込むため、READMEがうたう60〜95%はなかなか効いてきません。どちらのルートでも実質的な使用量の削減は見込めないので、Headroomの導入はおすすめしません。

claude -p --output-format stream-jsonの出力を試せば、導入を決める前に比較できます。init行にはそのセッションで使えるツールが、usage行には使ったトークン数が出ます。ぜひ試してみてください。

参考リンク

この記事をシェア

その他

その他