Claude Codeはプロンプトを読む前に3.3万トークン、OpenCodeは7千トークンを送信する

 (systima.ai)
3 ポイント 投稿者 GN⁺ 5 시간 전 | 1件のコメント | WhatsAppで共有
  • 同一のモデル・マシン・タスクでAPI境界を測定した結果、Sonnet 4.5の初回リクエストにおける固定オーバーヘッドはClaude Codeが約32,800トークン、OpenCodeが約6,900トークンで、4.7倍の差があり、Fable 5では約3.3倍に縮小した
  • 差の大部分はツールスキーマに起因する。Claude Codeは27個のツール定義に約24,000トークン、OpenCodeは10個のツールに約4,800トークンを使っており、ツールをすべてオフにしてもシステムプロンプトはそれぞれ約6,500トークンと2,000トークンだった
  • 実際の設定では、72KBのコマンドファイルがリクエストごとに約20,000トークン、小型MCPサーバー1つが約1,000〜1,400トークンを追加し、初回リクエストだけで75,000〜90,817トークンに達する可能性がある
  • Claude Codeは同一のファイル要約タスクでOpenCodeよりキャッシュ書き込みを5.9〜54倍多く発生させ、2つのサブエージェントに作業を分散すると、直接実行時に121,000トークンだった使用量が513,000トークンへ4.2倍に増えた
  • 固定オーバーヘッドだけで総コストは判断できない。多段階タスクでは、Claude Codeがツール呼び出しを並列にまとめて3回のリクエストで約121,000トークンを使った一方、OpenCodeは直列呼び出し9回で約132,000トークンを使用した

API境界で測定した方法

  • Claude CodeとOpenCodeの間にロギングプロキシを配置し、ハーネスが送った正確なJSONリクエストとAPIが返した使用量ブロックを記録した
    • リクエスト本文にはシステムブロック、ツールスキーマ、メッセージが含まれる
    • 使用量には入力トークン、キャッシュ書き込み・読み取り、出力トークンが含まれる
    • キャプチャしたリクエスト本文は実際の送信内容、API使用量ブロックは実際の課金量の基準として使った
  • 基本比較にはClaude Code 2.1.207とOpenCode 1.17.18を使用し、どちらも2026年7月時点のclaude-sonnet-4-5に固定した
    • 固定オーバーヘッド、キャッシュ処理、多段階タスクの一部はclaude-fable-5で再実行した
    • 新しい設定ディレクトリ、MCPサーバー・ユーザー設定・メモリがない状態、コマンドファイルのない空のワークスペースでデフォルト値を分離した
  • 3種類のタスクで異なるコスト構造を測定した
    • T1はReply with exactly: OKで固定オーバーヘッドを分離し、ハーネスごとに3回実行した
    • T2は事前に用意したファイルを読んで要約させた
    • T3はFizzBuzzと検査スクリプトを対象に、作成・実行・テスト・修正の手順を実行した
  • ツールスキーマを除いたシステムプロンプトを比較するため、Claude Codeには--tools ""、OpenCodeには"tools": {"*": false}を適用した
  • ローカルLLMゲートウェイがリクエストごとに約6,200トークンの固定エンベロープを追加していたため、これを補正したうえで計測値から除外した
    • コンポーネント別の数値は、ゲートウェイが変更できないキャプチャ済みリクエスト本文から計算した
    • 文字・トークン変換には、コールドキャッシュ基準で測定したハーネス別の4.1〜4.4文字あたり1トークンの比率を使用した

基本オーバーヘッドを大きくするツールスキーマ

  • 22文字のT1プロンプトの初回リクエストで、Claude Codeは約32,800トークン、OpenCodeは約6,900トークンを送信した
    • Claude Codeのシステムプロンプトは3ブロック、27,344文字で、OpenCodeは1ブロック、9,324文字だった
    • Claude Codeの27個のツールスキーマは99,778文字、OpenCodeの10個のツールは20,856文字だった
    • Claude Codeは実際のプロンプトの前に、エージェント種別、利用可能なスキル、ユーザーコンテキストを含む<system-reminder>ブロック7,997文字を挿入する
    • OpenCodeは別の初回メッセージ用スキャフォールディングなしに、システムブロック、10個のコーディングツール、ユーザープロンプトを送る
  • 両者ともツール定義が最大の割合を占める
    • Claude Codeの約33,000トークンのうち約24,000トークンがツール定義である
    • OpenCodeの約6,900トークンのうち約4,800トークンがツール定義である
    • Claude Codeのツールには、コーディング機能だけでなく、CronCreate、Monitor、Task系、作業ツリー管理、プッシュ通知など、バックグラウンドエージェント・オーケストレーション機能が含まれる
  • ツールをすべて取り除くと、Claude Codeのシステムプロンプトは26,891文字、約6,500トークンで、OpenCodeは8,811文字、約2,000トークンである
    • どちらのハーネスも、ツールが無効化されるとプロンプトは少し短くなる
    • 残る差は、口調、安全指示、タスク管理ルール、環境情報などの行動指針に由来する
  • Fable 5ではClaude Codeがモデルに応じてプロンプトを減らし、差は約3.3倍に縮小した
    • システム指示はSonnetの27,787文字からFableの10,526文字に減少した
    • 同じ27個のツールを維持しつつ、スキーマも99,778文字から82,283文字に減った
    • OpenCodeのリクエストは2つのモデルでバイト単位で同一だった

タスク形態によって変わる総使用量

  • ファイル1つを読んで要約するT2では、両ハーネスとも正確な結果を出したが、リクエスト構造は異なっていた
    • Claude CodeはHTTPリクエスト6回と累計入力約199,000トークンを使用した
    • OpenCodeはリクエスト4回と約41,000トークンを使用し、セッションタイトル生成のためのHaiku呼び出し1回を追加した
    • 使用量の大半は、入力価格の10分の1で課金されるキャッシュ読み取りだった
  • キャッシュ割引があっても、初回リクエストのキャッシュ書き込み、各ターンのキャッシュ読み取り、コンテキストウィンドウの占有はペイロードサイズに応じて増える
    • 33,000トークンのベースラインは、コードが入る前から200,000トークンウィンドウの約6分の1を占める
  • 作成・実行・テスト・修正タスクであるT3では、ツール呼び出し方式が基本オーバーヘッドの差を相殺した
    • Claude Codeはファイル書き込み2回とスクリプト実行2回を1回の並列ツール往復にまとめ、モデルリクエスト3回、累計入力約121,000トークンを記録した
    • OpenCodeは各ターンでツールを1つだけ呼び出し、9回のリクエストとタイトル呼び出し1回、累計入力約132,000トークンを記録した
    • 全体入力はおおむね、リクエストごとのベースラインとリクエスト回数の積に会話の増分を足した値で決まる
  • 会話が進むにつれて、Claude Codeは<system-reminder>を初回ターンの3個から、最初のツール往復時点の4個へ増やした
  • OpenCodeのターンごとの追加ペイロードは約400〜2,200文字で、会話内容だけが増える

実際の設定が追加するトークン

  • 本番リポジトリの72KBのAGENTS.mdを追加すると、両ハーネスともリクエストごとに20,000トークン以上増加した
    • OpenCodeの計測値は13,152トークンから33,336トークンに増加した
    • Claude Codeは39,005トークンから59,243トークンに増えた
    • Claude Code 2.1.207はAGENTS.mdを無視し、CLAUDE.mdに名前を変えて初めて最初のユーザーメッセージに挿入した
    • OpenCodeは両方のファイル名を読み、システムプロンプトに挿入する
    • ハーネスが実際に認識するファイル名を確認しないと、コマンドファイルが静かに無視される可能性がある
  • 公開型の小型MCPサーバーは、サーバー1台あたりリクエストごとに約1,000〜1,400トークンを追加する
    • サーバー5台はClaude Codeのペイロードに4,900トークン、OpenCodeの計測値に6,967トークンを加えた
    • ツール数はClaude Codeで27個から69個、OpenCodeで10個から52個に増えた
    • 豊富なAPIを持つ本番サーバーは、より大きなスキーマを送る可能性がある
    • Claude Codeのprintモードは、明示的な--mcp-configがないとプロジェクト範囲の.mcp.jsonを静かに無視したため、API境界で接続有無を確認する必要がある
  • BMADのようなストーリーベースのワークフローフレームワークは、ペルソナ・プロトコル・チェックリストを含む大きなテンプレートをスラッシュコマンドとして展開する
    • 実験の8,405文字のテンプレート自体は約2,100トークンだが、会話履歴に入るため、その後のすべてのリクエストで再送信される
    • 9回リクエストのセッションでは同じテンプレートが9回載るため、コストはテンプレートサイズ × リクエスト数で増える
  • 実際の構成の初回リクエストは、基本オーバーヘッドよりはるかに大きくなった
    • OpenCodeはメール・カレンダー、タスク管理、参考文献管理、製品分析などのためのMCPサーバー11台と72KBのコマンドファイルを使い、179個のツールと277KBのスキーマ、コールドキャッシュ書き込み90,817トークンを記録した
    • Claude CodeはMCPサーバー4台、インストール済みプラグイン、同じコマンドファイルで118個のツールと311KBのペイロード、約75,000トークンを記録した
    • OpenCode構成はゲートウェイエンベロープを除くと、約7,000トークンのデフォルト値の約12倍だった

サブエージェントと拡張思考のコスト

  • Claude Codeが作業を2つのサブエージェントへ並列分散すると、直接実行の121,000トークンが513,000トークンへ増え、4.2倍になった
    • メインセッション、サブエージェント呼び出しなど3種類のリクエストタイプで、合計9回のモデルリクエストが発生した
    • サブエージェント呼び出し5回は、それぞれ3,554文字のシステムプロンプトと、基本27個中24個のツールで独自にブートストラップする
    • 各サブエージェントが初期コストを負担し、その実行履歴を親が再び読む構造である
  • OpenCodeのサブエージェントは、1,379文字のシステムプロンプトと5個のツールだけを使う縮小プロファイルを送信する
    • ゲートウェイ経由の実行が正常完了しなかったため、OpenCodeのサブエージェント全体の使用量は数値化していない
    • キャプチャしたペイロードで確認された設計上の違いのみを比較した
  • 拡張思考出力は入力単価の5倍である出力単価で課金され、推論ブロックが会話履歴に含まれて以後のリクエストで再送信される
    • ゲートウェイ自体の思考ポリシーのため、両ハーネスの設定が実際に適用されたか確認できず、測定値は公開しない
    • 推論ブロックが履歴に加わるコスト構造だけを確認対象として残した

プロンプトキャッシュの経済性と安定性

  • 両ハーネスともキャッシュブレークポイントを正しく設定している。ペイロードは5分TTL基準で基本入力価格の1.25倍として一度書き込まれ、その後10分の1の価格で読み取られる
  • キャッシュで減らないコストは3つある
    • 5分以上中断するとスタック全体を書き直す必要があるため、会議や食事のような休止後には書き込みコストが再発する
    • キャッシュ読み取りもリクエスト回数分繰り返されるため、直列ツールループやサブエージェント分散がコストを増やす
    • コンテキストウィンドウの占有はキャッシュ割引の影響を受けず、85,000トークンのブートストラップが200,000トークンウィンドウの40%以上を占め、圧縮が始まると要約コストも追加される
  • OpenCodeは、キャプチャしたすべてのリクエストと実行でバイト単位で同一のプレフィックスを維持した
    • 3回のT1セッションで、ツール、システム、メッセージのバイトが同一で、反復実行でのキャッシュ書き込みは0だった
    • 9リクエストで構成されるT3セッションも、1つの安定したプレフィックスを維持した
  • Claude Codeはセッションごとに、ウォームアップ探索、メイン会話、サブエージェント呼び出しという異なるリクエストタイプとキャッシュ項目を作る
    • 同じワークスペースでも、システムバイトと初回メッセージのスキャフォールディングが実行ごとに変わる
    • 同一のファイル要約タスクで5件のリクエストにわたり53,839キャッシュトークンを書き込み、約43,000トークンのプレフィックス全体を作業途中で一度書き直した
    • OpenCodeの同じタスクのキャッシュ書き込みは1,003トークンだった
  • Claude Codeの大規模な中間キャッシュ再書き込みは、反復実験でも見られた
    • 最初の2回の実行でそれぞれ43,342トークンと36,899トークンを書き直し、新しくウォームアップしたキャッシュを使った3回目の実行ではほとんど書き込まなかった
    • Fable 5でもキャッシュ読み取りなしで50,053トークンを書き直し、Sonnetの54倍に近い52倍の差が発生した
    • キャッシュ温度に応じて、Claude Codeのキャッシュ書き込み量はOpenCodeの5.9〜54倍だった
    • キャッシュ書き込み単価は5分階層で基本の1.25倍、1時間階層で2倍である
  • 単一のキャッシュミスはゲートウェイの追い出しが原因かもしれないが、複数回の実行で再現され、リクエスト前のキャプチャバイトでもプレフィックスの不安定性が確認された
    • プレフィックスが大きく種類も多く、再書き込みが繰り返され、さらにサブエージェントまで加わると、Claude Codeの使用量ダッシュボードはより速く増える可能性がある

結果品質と監査ログ

  • 両ハーネスは評価対象タスクをすべて正確に完了した
    • ファイル要約結果はいずれも正確だった
    • 多段階タスクは各ハーネスが作成した検証スクリプトを通過し、正常終了した
    • この範囲では、同じ結果を得るために必要なトークンコストの差を比較できた
  • より難しい実際のエンジニアリングタスクで、Claude Codeのバックグラウンドエージェント、スキル、オーケストレーションが追加コストに見合う品質向上をもたらすかは測定していない
    • これを判断するには、適切なテストセット、十分な反復実行、合格率評価が別途必要である
  • 品質と無関係な無駄も確認された
    • バイトが同じキャッシュプレフィックスをセッション途中で書き直すのは、同じ内容をプレミアム価格で買い直すようなものだ
    • ハーネスがコマンドファイルを静かに無視すると、そのファイルから何の効用も得られない
  • キャプチャしたリクエスト・レスポンス185件の記録を、オープンソースライブラリ@systima/aiact-audit-logでSHA-256ハッシュチェーンに記録した
    • チェーンは最後まで途切れず検証され、完全性の結果はVALIDだった
    • 同じ構造で送信・応答内容を再構成し、第三者に完全性資料を提供できる
    • これはEU AI Act Article 12のロギングで提供される構造化記録方式と同じである

測定の限界と再現方法

  • 結果は1台のマシン、2つのハーネスバージョン、小さな標本を使った2026年7月のスナップショットである
    • T1とT2はそれぞれ3回、各構成の倍率条件は1回実行した
    • デフォルト値とキャッシュ条件はSonnet 4.5とFable 5を使用し、構成倍率条件は1つのモデルだけを使用した
    • ハーネスのプロンプトは頻繁に変わるため、個別の数値よりAPI境界で測定する方法のほうが長く有効である
  • ローカルゲートウェイが測定経路にあった
    • コンポーネント数値は、ゲートウェイが変更できないリクエスト本文を使用した
    • 計測値はコールドキャッシュ基準点で固定エンベロープを補正し、原因を区別できないウォーム実行の数値は除外した
    • ゲートウェイが固定したモデルより新しいスナップショットへ静かに置き換えた事例があり、実際の応答モデルも境界で確認する必要がある
    • Fable経路では古いサーバーセッションの再開とホスト側ツール実行が発生したため、Claude CodeのFable多段階結果を除外した
  • T3のコスト収束は、1つのタスク形態から得られた1回の観測である
    • 順次実行が必須のタスクでは、Claude Codeのリクエスト回数と総使用量が再び増える可能性がある
    • OpenCodeのツール除去およびサブエージェント条件は、ゲートウェイが誤ったストリームを返したため、キャプチャしたペイロードサイズのみを使用した
    • 実際の構成数値はあるユーザーの設定であり、別の環境では変わり得る
  • 再現装置は約200行のNodeコードで構成されたHTTPプロキシである
    • モデルエンドポイントへリクエストを転送しながら、リクエスト本文とレスポンス使用量ブロックをディスクと監査チェーンに記録する
    • ANTHROPIC_BASE_URLをプロキシに指定し、新しい設定ディレクトリと空のワークスペースでデフォルト値を測定した後、コマンドファイル、MCPサーバー、ワークフローを1つずつ追加する
    • ゲートウェイを使う場合は、まず最小リクエストで自身のエンベロープを測定し、実際にどのモデルが応答しているか確認する必要がある
    • 本番エージェントが特定時点にモデルへ送った正確な内容を再構成できるようAPI境界ロギングを備えれば、トークン会計も同時に確保できる

関連記事

1件のコメント

 
GN⁺ 5 시간 전
Hacker Newsの意見

  • トークンを本当に大量に燃やしているのは サブエージェント だ。Claude Codeに大きな作業を任せたら、即座にサブエージェントを7個立ち上げ、1つも終わる前に予算を使い切った。5時間後に再試行しても同じだった
    メインエージェントに同じ作業を順番に実行させればまったく問題なかった。通信と調整コストのせいでこんなに非効率なのか、それともサブエージェント利用者はたいてい大企業アカウントでトークン単価課金だから、Anthropicが売上を増やしたいのかは分からない

    • 一方で、複雑なプロジェクトの探索・計画段階では、Fableの 好奇心の強い挙動 がまさに必要なこともある。調整エージェントがプロンプトを複数の探索観点に分けるだけでなく、各サブエージェントがその観点でコードベースを調査し、新たな手がかりを再帰的に広げていくようにしたいなら、全段階でFableを使うのは理にかなっている
      逆に、よく計画された作業を複数対象へ並列適用したいだけなら、サブエージェントには好奇心の弱いモデルへ 段階を下げるよう 明示すべきだ。成果物の一貫性も向上するかもしれない
    • 各サブエージェントは、作業に必要な文脈を得るためにコードベースの一部を読み直す必要がある。作業が長引くと、調整エージェントの文脈もキャッシュから消え、サブエージェント完了後に再び全コストを払うことになる
      逐次実行なら、ファイルはだいたい一度ずつ読むだけで済み、すべてのリクエストが同じ プレフィックスキャッシュ を活用できる
    • 顧客が問題を回避するためにより高価な料金プランを選ぶようになるなら、会社にはその問題を直さない 負のインセンティブ が生まれる。解決策を持つエンジニアが数人いても、大多数の無関心、一部の妨害、ときには管理職層のどこかにいる積極的な敵意にぶつかりうる
      こういう環境では、最上位プランに新機能を先に入れて費用回収したあと下位プランへ降ろすか、競合が追随しづらいよう はしごを外す戦略 が最善かもしれない
    • 各サブエージェントに、約 3万トークンのシステムプロンプト を同一内容で送っている。Fable/Opusを使うと、7個が作業を始める前に5時間利用枠の30%を簡単に消費する
    • このコツを覚えてからは、Fableサブエージェントを明示的に禁止している。昨日、大規模リファクタリング後の複雑なコードをレビューするため、まずレビュー計画を求めたところ、第1段階でFableエージェント8個と結果検証用1個を提案してきたので承認した
      ところが検証段階で Fable検証エージェント41個 を立ち上げようとした。どうにか抜け道を見つけたらしい

  • Claude Codeがトークンを多く使うのは、Anthropicがもっと金を稼ぎ、ユーザーをサブスクへ追い込みたいからだと思う。サブスク権限を他のコーディングエージェントで使えない方針も、それを裏づけている。私はpiを使っている

    • Anthropicを トークン販売業者 と見ると、いろいろな意思決定が理解できるようになる。ユーザーが反発したり安全装置を求めたりしない限り、自社経路でより多くのトークンを消費させる理由を作り続ける
    • IPO関連書類によれば、サブスク売上は約5%とかなり小さいと見たことがある。ただしその5%は個人向けClaudeサブスクで、Claude Codeサブスクの大半は企業部門に含まれている可能性が高い
      API・エンタープライズは全売上の75〜85%、企業サブスクは約10〜15%、個人サブスクは約5%だ
    • むしろ逆の理屈だ。サブスク加入者は固定月額を払うので、AnthropicにはClaude Codeが トークンをあまり使わないようにするインセンティブ がある
    • 一方で、こうした挙動は定額料金に含まれる一般加入者のトークン消費も増やす。悪意というより 無能に近く見える

  • PUSH_AXのもっともな比喩どおり、これは施工業者Aが3万3千ドルを請求し、Bが7千ドルを請求したような話なので、私たちが正しい対象を測っているのか考える必要がある
    これを踏まえ、記事には より深い作業、定性的な結果比較、できる限り高速な入出力再現資料を追加する予定だ

    • 3万3千トークンのかなりの部分が、直近の会話のような コンテキストデータ なのか気になる

  • 大きなシステムプロンプトだけの問題ではない。コーディングエージェントの実行環境も、些細なリクエストにさえツールをより攻撃的に使っている。テストでは、"Hey" や "commit" のようなプロンプトが、ときに 30回を超えるツール呼び出し を引き起こした
    https://quesma.com/blog/the-true-cost-of-saying-hi-to-an-ai-...
    簡単な作業が消費するトークン数が増え続ける トークンインフレ は実際に見られる

    • Opusがコメントの誤字1つを直したあと、テストやlintなど実行できるものを全部走らせると腹が立つ。そもそもすべてのテストが通っていたか先回りして確認するため、今の変更を先にstashすることさえある
      すべての変更をテストで検証しろとルールに書いたのは自分の責任でもあるが、AIのIをそこまで強調するなら、少なくともフルーツサラダにトマトを入れない程度の判断力は期待してしまう
    • "Hey" や "commit" のような曖昧なプロンプトを受けると、望まれる作業を推測しようとして過去の会話や他の文脈を探るため、ツール呼び出しが増える。より明確なプロンプト のほうがよい
    • コミットくらいはLLMに任せず自分でやればいいのでは？

  • Claudeを6か月使ったあと、最近Codexへ切り替えた。Codexのほうがよりオープンで、モデルの作業過程を追いやすく、承認フローのUXも良い。全体として 透明性が高く、乗り換えコストもほぼゼロだった
    Claudeが2月ごろから、システムプロンプトを含めてより不透明になったのは気に入らないし、3万3千トークン は多すぎるように見える

    • 今は両方使っているが、実際ほぼ入れ替えて使える程度だ。Codexがオープンソースで、OpenAIがサブスク権限を他のエージェントで使ってよいと明示している点も良い
      最近のOpenAIはずっと 消費者寄り になっている
    • より不透明になってから、どんな設定を試したのか気になる。今は設定項目がずっと増えている

  • piエージェントはシステムプロンプトがより小さく、全体の内容はここで見られる
    https://github.com/earendil-works/pi/blob/main/packages%2Fco...

    • こうしたミニマリズムと関係があるのかもしれないが、PiにはLLMが効率的かつ効果的に動作するために必要なツールの大半が欠けている。何もない土台に欲しいものを足していくという哲学は理解できるが、私の基準では空っぽすぎる
    • システムプロンプトを呼び出すたびに日付とcmdを設定すると、キャッシュが無効化されるのか気になる
      日付やルートディレクトリが変わるときだけ無効化されるなら、実際には十分まれなことではある
    • 大幅にカスタマイズするための最小エージェントが必要なら、「最小」のpi-coderパッケージで130個以上の推移的依存関係を引き込むより、自分で作るほうがよい。難しくないし多くを学べるし、最初の段階では別のLLMに助けを求めてもよい

  • 結局重要なのは生のプロンプトサイズではない。もしそうなら、Piとその派生が最も低コストであるはずだ。肝心なのはプロンプトの効率性であり、プロンプトのミニマリズムと効率性はしばしば混同される。それでもClaude Codeは、やっていることに比べて肥大化して見える
    それよりさらに重要なのはツールの品質だ。悪い、あるいはバグのあるツールは往復の呼び出しを大幅に増やし、最初に節約しようとしていた利点をすべて打ち消してしまう
    数か月前に8つのタスクで7つのエージェントを含む全体ベンチマークを行っており、https://github.com/dirac-run/diracにデータとトレース記録がある。そのうちの1つに直接関わっているので中立だとは言えないが、再現可能な資料ではある。タスクの大半がリファクタリングに関係しているため、ハッシュアンカリングと抽象構文木解析を強みとするDiracが大差で勝った

    • 競合は多く、競争も非常に激しいので、改善の余地があれば誰かが実現するだろうし、その後ほかの製品にも急速に広がる可能性が高い

  • 職場でClaude Codeを強制的に使わされているが、--system-prompt ""を使えば簡単に解決する。ほかの実行環境も許可してくれるとよいのだが

    • --system-prompt ""で空にすると、モデルが利用可能なツールを理解するための基本システムプロンプトすらなくなるのではないか？
    • かなり前からこう使っているのに、なぜみんな使わないのかわからない
    • このオプションは知らなかった。適用前後の実際の効率を分析した資料や、実運用環境の性能チャートがあれば見てみたい
    • このオプションでClaudeを起動するのか、それともプロンプトを送るたびに一緒に渡すのか気になる

  • ローカルモデルを最初に試したとき、Claude Codeにつないだら非常によく動いたが遅かった
    Claudeの助けを借りてmitmproxyを設定し、Claude Codeの初回システムプロンプト全体をキャプチャしたところ、再確認の結果JSON 162KBだった。これをきっかけにPi、OpenCode、Hermesを試し始めた

    • いまClaude Codeの新しいセッションで/contextを実行すると、Opus 4.8の100万トークンのコンテキストのうち2万3千トークンしか使っていない。システムプロンプト3.9千、システムツール13.9千、ユーザー定義エージェント235、メモリファイル28、機能4.9千、メッセージ8、圧縮バッファ3千トークンと表示される
      システムプロンプト4千トークンは約15〜20KBだ。キャプチャした内容をGistに上げてほしいと言いたいが、機密データが含まれているかもしれないし、見えている162KBがシステムプロンプトだけとは限らない

  • 私が作ったものはもっと少なく送る: https://maki.sh

    • コンテキストが長くなりすぎると、makiは画像と推論ブロックを削除し、以前の会話を要約して履歴を自動圧縮するという
      ただ、以前の会話の要約は実質的にコンテキストキャッシュを無効化し、トークン使用量は減っても、より高価なトークンを消費することになるのではないか？