ハーネスがエネルギー（およびトークン）効率において重要である理由

ハーネスがエネルギー効率に重要である理由

Chad Gibson（共同創業者兼CEO）による

主要な発見

• ハーネスはキャッシュの仕方が異なる。 クライアント間で1.6%から11.1%のキャッシュされていない入力が見られた。「キャッシュ済み」とは、プロンプトキャッシュから提供された入力トークンの割合であり、再計算されなかったものである。92%キャッシュ済みの場合、100トークンあたり8トークンがキャッシュされておらず、97%の場合は3トークンである。これは、プリフィル作業の約2.7倍に相当する。
• キャッシュミスはリクエストのエネルギーを約2倍にする。 ここでのミスとは、プロンプトのほとんどまたは全くキャッシュされていない（10%未満）リクエストを意味する。GLM-5.3では、その約2.5倍になる。
• 深いセッションはミスのコストを高くする。 再読み込みは、プロンプトのその部分をゼロから再計算することを意味する。128kトークンを超えると、プロンプトの半分以上を再読み込みする1回のターンは、その深さでの通常の約600回のターンと同等のプリフィルコストがかかる。
• これらの問題のほとんどは修正可能である。 私たちのラボテストでは、キャッシュブレークはすべて、ハーネスが既に送信したものを編集し、最初の違いから再読み込みを強制したことによって発生した。

Neuralwattでは、モデルを呼び出すエージェントハーネスが、使用するエネルギーにどのように影響するかを見ることができます。クラウドの1ヶ月分のトラフィックを調べてみましたが、ハーネスがGPUの処理量を決定する驚くべき割合を占めているようです。通常、推論効率については、モデル（アクティブなパラメータ数、アテンションメカニズム）やハードウェア（H200 vs B200 vs B300）の観点から議論します。クライアントにもっと注意を払う必要があります。

私たちのトラフィックのほとんどはエージェントによるもので、出力よりも入力の方がはるかに多いです。典型的なコーディングエージェントのターンは、10万トークン以上の会話を送信し、数百トークンを返します。その入力のほとんどは、前のターンのプロンプトに少し追加されたものです。以前のテキストが変更されていない場合、サーバーは既にキー・バリュー（KV）キャッシュを持っており、新しい部分だけを処理すれば済みます。これがプロンプトキャッシュであり、効率の最大の源です。キャッシュされたトークンを提供する方が、再計算するよりもはるかに安価です。

キャッシングには正確なプレフィックスが必要です。キャッシュブレークは、ハーネスが既に送信したものを変更したときに発生します。その後、最初の違いからすべてを再計算します。最初の方の変更、たとえタイムスタンプであっても、プロンプト全体を再計算する必要があります。最後の方の変更はほとんどコストがかかりません。ハーネスがプロンプトの構築方法を制御します。

同じモデル、同じ価格、異なるキャッシュ率

すべてのリクエストは、どのクライアントが送信したかを示しています。2026年9月8日から10月7日までの30日間で、OpenCode、Oh My Pi (omp)、Piなどのオープンソースのコーディングエージェントを含む、数百の異なるクライアントが見られました。エディタの統合、OpenAI SDK、カスタムアプリも含まれていました。OpenCodeだけでも、顧客の約4分の1が利用しています。

最も広く使用されているクライアントについて、キャッシュから提供できなかった入力トークンの割合は以下の通りです。

［画像: クライアントごとのキャッシュされない入力の割合を示す棒グラフ。deepseek-harnessの1.6%からNode.jsアプリの11.1%まで］

図1. クライアントごとのキャッシュされない入力。

ここに示すすべてのクライアントは、入力の大半をキャッシュしています。これらの小さな違いも重要です。97%キャッシュされているクライアントは100トークンあたり3トークンがキャッシュされておらず、92%のクライアントは8トークンです。これは、同じ会話でプリフィル作業が2.7倍になることを意味します。

ヒット率も、ハーネスだけでなくワークロードにも依存します。セッションが長くなるほどスコアは高くなります。なぜなら、各ターンの新しいテキストはプロンプト全体のごく一部になり、deepseek-harnessのリードの約半分は非常に長いセッションを実行するユーザーによるものです。ハーネスのよりクリーンな測定方法は、ターンがキャッシュを破る頻度です。deepseek-harnessでは100ターンに1ターンですが、OpenCodeとPiでは100ターンに約3ターンです。トラフィックにはOpenCode 1.xと2.xの両方がありますが、バーはそれらをまとめています。2.xは単独で見るとより良好です（キャッシュされない割合は2.2%対3.0%）。これは主にモデルのミックスによるものです。同じモデルでは、キャッシュの性能はほぼ同じです。2.xはラボで見つかった1.xのキャッシュブレークのほとんどを修正しています。この違いは本番環境では現れておらず、その理由はまだわかっていません。

ミスがエネルギーにどれだけかかるか

私たちは測定されたエネルギーに基づいて請求するため、コストを直接確認できます。2026年10月1日から7日までの1週間、同じモデルで同じプロンプトサイズ（約5万トークン）と類似の出力長のリクエストを比較しました。以下は、完全にキャッシュされたリクエストと比較して、各リクエストが使用した追加エネルギーです。

［画像: 棒グラフ：キャッシュが10%未満のリクエストは、GLM-5.3で140%増、DeepSeek V4.1 Flashで91%増のエネルギーを使用］

図2. キャッシュミスによる追加エネルギー。

ほとんどキャッシュされていないリクエストは、同じサイズのキャッシュされたリクエストの約2倍のエネルギーを消費します。GLM-5.3では、2.5倍近くになります。プリフィルは同じGPUを生成と競合するため、無駄なプリフィルはサーバー上の他のすべての応答を遅くします。

セッションが深くなるとキャッシュミスは高コストになる

2026年10月6日から13日までの1週間、最もトラフィックの多い3つのモデルで個々のセッションをターンごとに追跡しました。前のターンから5分以内に同じサーバーに着信したすべてのターンを調べました。この場合、キャッシュはウォームであるはずです。ほとんどのキャッシュブレークは小さかったです。プロンプトの最後の方の数千トークンがゼロから再計算されました。

コンテキストが128kトークンを超えると、1,000ターンあたり約3ターンが、プロンプトの半分以上をゼロから再読み込みします。これらのわずかなターンが、その深さでの再読み込みトークン全体の75%を占めます。それぞれが平均約23万トークンを再読み込みします。その深さでの通常のターンは、中央値で約370の新しいトークンを追加するため、これらの単一のターンは、通常の約600回のターンのプリフィルコストと同等です。

遅延も顕著です。以下は、通常のターンとプロンプトの大部分を再読み込みする必要があったターンの、最初のトークンまでの時間の中央値です。

［画像: 棒グラフ：通常のターンが0.8秒から2.8秒であるのに対し、プロンプトの大部分を再読み込みするターンでは、最初のトークンまでの時間が5秒から41秒に増加］

図3. セッションが深くなるにつれて、最初のトークンまでの時間。

私は、キャッシュブレークの頻度よりも、セッションのどのくらい深くまでキャッシュブレークが発生するかの方に注意を払っています。プロンプトの最初の方を変更することは、一度だけならコストはかかりません。長いセッションの200ターン目でそれを行うと、大きくて目に見える一時停止と大きなエネルギーコストが発生します。長いエージェントセッションは、私たちのトークンの大部分を占めるため、これは積み重なります。

サーバー側からは、ハーネスがプロンプトを編集したのか、メモリ圧力下でキャッシュがエビクトされたのかを常に判断できるわけではありません。これらの数値には両方が含まれます。以下のラボテストでは、再現できた早期プロンプト編集の原因がハーネスにあることを示しています。エビクションはおそらく残りの原因の一部を占めています。

キャッシュを壊すもの

原因を2つの場所で調べました。ラボ（すべてのトークンを確認できた場所）と本番環境（リクエストメタデータのみが見えた場所）です。

ラボで

4つの人気のあるオープンソースエージェント（OpenCode、Pi、omp、Kilo Code）を、DeepSeek V4.1 FlashとGLM-5.3に対してレコーディングプロキシ経由で実行しました。2026年10月6日時点の最新リリースをデフォルト設定で使用しました。OpenCode 1.18.34、Pi 1.0.4、omp 18.6.3、Kilo Code 7.8.3です。その後、OpenCode 2.0.29（2.xライン）で同じセッションを繰り返しました。それぞれが、小さなPythonプロジェクトに対して同じスクリプトセッションを実行しました。計画、構築、推論努力の切り替え、サブエージェントの起動、アイドル状態、再起動、MCPサーバーの接続と切断、スキルの追加、そしてコンパクションのために十分な長さの実行です。各リクエストを前のリクエストと比較しました。JSON形式とサーバーがレンダリングする正確なトークンの両方で比較しました。

同じ会話で前のリクエストに続く539件のリクエストのうち、88%は純粋な追加でした。つまり、前のプロンプトは新しいプロンプトの正確なプレフィックスでした。残りの65件はキャッシュを壊しました。すべてのブレークは、ハーネスが既に送信したものを変更したことによって発生しました。チャットテンプレートによるものは一つもありませんでした。アイドル時間は、いずれの4つのエージェントでもブレークを引き起こしませんでした。ハーネスの再起動とセッションの再開、またはサブエージェントの使用も同様でした。

ユーザーの操作なしにキャッシュを壊す2つの原因があります。

• OpenCodeのプランモードリマインダー。 プランモードを使用すると、OpenCodeは各新しいユーザーメッセージにリマインダー（「オペレーションモードがプランからビルドに変更されました」）を添付します。次のターンでそのリマインダーをメッセージから削除します。各ターンは、ツール呼び出しとその結果を含め、前のターン全体を再読み込みします。短いセッションでは、これはターンあたり330〜2,340トークンでした。コストはターンのサイズとともに増加します。OpenCode 2.xはリマインダーを独自のメッセージに保持するため、再読み込みはトリガーされなくなりました。
• ompによる再読み込みファイルのプルーニング。 ファイルが2回目に読み込まれると、ompは履歴内の以前のコピーを[Superseded by a newer read of this file]（このファイルの新しい読み込みに置き換えられました）に置き換えます。私たちの実行では、その1回の編集はプロンプトの62%の位置にあり、15,520トークンのうち5,846トークンの再読み込みを強制しました。ompは「イベント性のない」ツール結果もプルーニングし、90分アイドル状態の後、どの深さでもプルーニングします。compaction.supersedeReads: falseおよびcompaction.dropUseless: falseを設定すると、キャッシュが維持されます。

PiとKilo Codeには、この種のブレークはありませんでした。

その他の原因は、ユーザーの操作に依存します。それらのコストは、プロンプトが変更される場所によって異なります。

• 推論努力の切り替え。 両方のテンプレートは、プロンプトの最初の数トークンに努力レベルを書き込みます。GLM-5.3ではReasoning Effort: Max、DeepSeek V4.1では1から100までの数値です。最初の違いは両方のモデルでトークン8にあり、切り替えはすべてを再読み込みします。その値だけが変更され、その後の長さとすべては同一のままです。
• MCPサーバーの接続または切断。 OpenCode 1.xとKilo Codeは、ツールリストの真ん中に新しいツールをアルファベット順に挿入します。OpenCode 2.xはツールリストを変更せず、注釈を追加するため、接続と切断の両方が純粋な追加でした。Piはツールを追加し、システムプロンプトを編集します。ompはシステムメッセージにセクションを追加します。GLM-5.3では、ツールリストはシステムプロンプトの前にレンダリングされるため、変更は非常に早い段階で発生します。OpenCode 1.xでは約1,300トークンです。
• スキルの追加。 4つすべてがシステムプロンプトにスキルをリストします。最初の違いは、DeepSeek V4.1ではトークン461から2,948の間、GLM-5.3ではツールが先に来るため、それより遅い位置にありました。
• 日付の変更。 OpenCode 1.xとKilo Codeは、システムプロンプトに今日の日付を約2,000トークン目に入れます。OpenCode 2.xはセッションの元の日付を保持し、日付が変更されたときに注釈を追加します。ompはそれを最初のユーザーメッセージに入れます。Piは日付を送信しません。日付を上書きするクライアントの場合、ローカルの深夜を越えると、ほぼすべてを一度再読み込みする必要があります。
• コンパクション。 各ハーネスはこれを異なる方法で行います。Piは最後の約2万トークンをそのまま保持しますが、先頭近くの要約を書き換えます。プロンプトはほとんど縮小せず、そのほとんどが再読み込みされます。同じ4万トークンのウィンドウで、OpenCode 2.xは3回コンパクションし、合計67,850トークンを再読み込みしました。1.xは1回コンパクションし、29,776トークンを再読み込みしました。

セッションの早い段階で使用した設定に戻すことは、予想よりも安価でした。サーバーはまだその以前のバージョンのプロンプトを保持しています。努力レベルの切り替えは、各新しい状態が使用される最初の1回だけ、フル再読み込みを必要とし、すべての切り替えで必要とされるわけではありません。私たちの実行では、10.6kから27.5kのキャッシュトークンにヒットしました。

本番環境で

顧客のプロンプトや応答のテキストをログに記録したり保持したりしません。このセクションのすべては、リクエストメタデータから来ています。トークンレベルの分析は、独自のスクリプト化されたテストセッションから来ており、顧客のトラフィックからではありません。そのメタデータは、各リクエストが要求した推論努力と送信したツールの数を記録します。これを使用して、2026年10月6日から13日までのDeepSeek V4.1 Flash、GLM-5.3、GLM-5.3 Flashの実際のセッションで、これらの原因のうち2つをチェックしました。同じサーバー上で5分以内に、少なくとも8kトークンの連続するターンを追跡しました。少数のヘビーユーザーのアカウントが結果を左右しないように、各グループで最も再読み込みトークンが多い3つの顧客を除外しました。

［画像: 棒グラフ：何も変更が見られない場合は2.8%のターンがキャッシュを壊し、推論努力が変更された場合は61%、ツールの数が変更された場合は67%］

図4. 変更された内容によるキャッシュブレーク。

ツールリストや努力レベルの変更は、キャッシュブレークの可能性を20倍以上にし、平均して前のプロンプトの約40%のコストがかかります。ツールリストの変更は約0.5%のターンで発生しますが、これらのモデルでの再読み込みトークン全体の19%を占めます。その割合は集中しており、3つのアカウントがその約3分の2を占めます。ターンあたりの効果は、他のすべてのユーザーに共通しています。

再読み込みトークンの残りの4分の3は、努力やツール数が変更されなかったターンで発生します。その「見えない」バケットには、サーバーからは見えない原因が含まれています。OpenCode 1.xのリマインダー、ompのプルーニング、スキル、日付、コンパクション、キャッシュエビクションです。次に、各プロンプトが前のものと最初に異なる場所を記録したいと考えています。これにより、プロンプトテキストを一切読まずにバケットを分割できるようになります。

deepseek-harnessがキャッシュを維持する方法

私たちのラボキャプチャでは、deepseek-harnessのフォローアップリクエストはすべて、プロセスが再起動され、セッションが再開された後でも、前のリクエストへの純粋な追加でした。ソースを読むと、注目に値するいくつかのプラクティスが見つかりました。

1. リクエストは、追加専用のセッションログから再構築される。 リトライと再開は、バイト単位で同一のプロンプトを生成します。
2. システムプロンプトは固定されており、最小限である。 日付、gitステータス、OSは含まれていません。一度書かれ、そのままにされます。
3. 状態の変更は履歴の後に行われる。 承認ポリシーや利用可能なスキルが変更されると、ハーネスはそれらが以前のものを上回ることを示す短いスナップショットを追加します。システムプロンプトや古いメッセージはそのままにしておきます。
4. ツールリストはソートされ、すべてのモードで同一である。 プロズ指示により、ツールを追加・削除することなくモードが強制されます。
5. コンパクションは遅れて行われる。 要約呼び出しは既存のプレフィックスを再利用するため、コンパクションでさえほとんどがキャッシュヒットです。トランスクリプトを単一の新しいメッセージに再シリアライズするサマライザーはコールドスタートします。私たちが確認した最大のワークロードでは、それらの呼び出しはわずか22%しかキャッシュされませんでした。
6. すべての変更はキャッシュへの影響についてレビューされる。 各パッケージには短い「KVキャッシュ効果」セクションが含まれています。

あなたができること

ハーネスを構築または設定する場合：

• 各ターンのプロンプトの先頭を同一に保ってください。新しいメッセージやツールの結果は会話の末尾に追加してください。設定の変更もそこに記述し、以前のテキストはそのままにしてください。
• 日付、gitステータス、その他の変更されるものをシステムプロンプトに入れないでください。
• ツールリストを安定させ、ソートしてください。新しいツールは末尾に追加してください。
• 遅れてコンパクションし、サマライザー呼び出しが会話の正確なプレフィックスを再利用するようにしてください。
• 安定したセッションIDを送信してください。Neuralwattでは、X-NW-Conversation-IDにより、キャッシュを保持しているサーバー上でセッションを維持できます。コンパクションをまたいでも同様です。

ハーネスを使用する場合：

• セッションあたり1つの推論努力を選択し、セッション中に切り替えないでください。
• ompの場合、compaction.supersedeReads: falseを検討してください。
• MCPサーバーやスキルなどの設定は、セッションが長くなる前に確定してください。キャッシュブレークが最も痛いのはその時です。

自分のセッションで確認する

この記事のすべては、リクエストごとに記録するデータから来ており、自分の作業についても同じデータを見ることができます。Neuralwattダッシュボードのセッションインサイトは、各エージェントセッションをターンごとに表示します。各プロンプトのどれだけがキャッシュから来たか、どれだけがコールドで計算されたか、最初のトークンまでの時間、測定されたエネルギーとコストです。プロンプトや完了テキストは表示されません。

［画像: 35ターンのセッションのセッションインサイトページ：キャッシュヒット率95.2%、合計トークン5.4M、コールドプリフィル258.8K、およびターンごとのキャッシュ済みとコールドプロンプトトークン、最初のトークンまでの時間のチャート］

図5. Neuralwattダッシュボードのセッションインサイト。

これは、2026年9月26日の私のセッションの1つです。DeepSeek V4.1 Flashでのコーディングエージェントの35ターンで、コンテキストは29kから257kトークンに増加しました。プロンプトトークンの95%がキャッシュから来ており、小さな赤いキャップは各ターンで追加された新しいテキストです。キャッシュブレークは背の高い赤いバーとして表示されるため、セッションの途中で推論努力を切り替えたりMCPサーバーを接続したりすると、そのコストを確認できます。これを使用して、自分のワークロードでハーネスや設定を比較したり、変更が実際にキャッシュをウォームに保ったことを確認したりできます。

私たちが側で行っていること

各セッションを、そのキャッシュを保持しているサーバーにルーティングし直します。最もトラフィックの多いモデルでは、これによりセッションのトークンの88〜96%がホームサーバーに維持されます。セッションが移動する必要がある場合、共有KVキャッシュプールにより、新しいサーバーは再計算せずにプレフィックスをロードできます。

最近、よりスマートなプレフィックス認識ルーターが、これに加えてどれだけ回復するかを測定しました。ヒット率の0.1〜0.2パーセントポイントです。残りの無駄のほとんどは、プロンプトの構築方法に起因します。

次に、顧客が最も使用しているオープンソースハーネスに、修正と推奨デフォルトをアップストリームに送信する予定です。また、サーバーがプロンプトの先頭近くの小さな編集（努力行や日付など）の後でキャッシュされた作業を再利用できるようにする方法を研究したいと考えています。これにより、私たち自身では変更できないクライアントにも対応できるようになります。

なぜこれが測定する価値があるのか

キャッシュブレークはエラーとして表示されません。回答は得られますが、時間がかかり、より多くのエネルギーが費やされます。各リクエストのエネルギーを測定することで、その無駄がどれだけ積み重なるかがわかりました。そのほとんどは、設定やハーネスがプロンプトを構築する方法の小さな変更で修正可能であることが判明しました。

AIはエネルギーで動いています。それが見えるほど、単一の開発者のセッションであれ、業界の次のデータセンターであれ、無駄にされているエネルギーを止めることができます。

---

方法論に関する注記。 クライアントは、各リクエストのUser-Agentヘッダーの名前で識別します。SDKおよびランタイムラベル（Node.jsアプリ、OpenAI SDKアプリ）は、多くの異なるアプリケーションをカバーしています。多くの顧客が使用しているクライアントのみを表示し、個々の顧客を特定することはありません。サーバーは固定サイズのブロックにプロンプトをキャッシュするため、純粋な追加でも前のターンの末尾に再読み込みが必要なトークンがいくつか残ることがあります。これらをキャッシュされていない入力としてカウントし、図1のコーディングエージェントでは0.1パーセントポイント未満を追加します。キャッシュ率は、2026年9月8日から10月7日までのすべてのモデルにおける、キャッシュから提供されたプロンプトトークンの割合です。エネルギーは、各リクエストに割り当てられたGPUエネルギーを測定したものです。キャッシュ済みとキャッシュされていないの比較では、プロンプトサイズと出力長を固定し、2026年10月1日から7日までをカバーしています。ディープセッションと原因の分析は、2026年10月6日から13日まで、DeepSeek V4.1 Flash、GLM-5.3、GLM-5.3 Flashで実施され、同じサーバー上で5分以内に連続するセッションのターンを追跡しました。

---

Chad GibsonはNeuralwattの共同創業者兼CEOです。彼はMicrosoftで20年以上過ごした後、初期段階のスタートアップに投資し、2024年にNeuralwattを共同設立しました。