ベンチマーク結果：メモリシステム搭載のClaudeエージェントスウォームで、30〜43%のトークンコスト削減を実現

Claudeエージェントスウォームのメモリシステムベンチマーク

ある開発者が9ヶ月間、Stompyと呼ばれるメモリシステムを構築してきました。これはファイルベースからSQLite、PostgreSQLへと進化してきたもので、Claudeエージェントスウォームを実行する際のトークン使用量を最小限に抑えることを目的としています。彼らは、メモリシステムを使用した場合と使用しない場合のパフォーマンスを比較するベンチマークを実施しました。

テスト設定

このベンチマークでは、バックエンド、フロントエンド、テストを含む完全な予約機能を必要とする40ポイントのコーディングタスクを使用しました。6エージェントのスウォームを、リードモデルとしてSonnet 4.6、Opus 4.6、Haiku 4.5の3つの異なるClaudeモデルでテストしました。すべてのテストは同じコードベース、同じチームメイト、同じ採点システムを使用しています。チームメイトのエージェントは、リードモデルに関わらず常にOpusを実行しました。

ベンチマーク結果

• Sonnet 4.6 + メモリ: 40/40, $3.98, 6.5分, 2ターン
• Sonnet 4.6 メモリなし: 40/40, $7.04, 9.6分, 4ターン
• Opus 4.6 + メモリ: 40/40, $4.34, 9.6分, 29ターン
• Opus 4.6 メモリなし: 40/40, $7.65, 10.0分, 70ターン
• Haiku 4.5 + メモリ: 39/40, $4.95, 7.5分, 2ターン
• Haiku 4.5 メモリなし: 0/40, $3.97, 5.8分, 3ターン

主な発見

OpusとSonnetは、メモリを使用することで、メモリなしで実行する場合と比較して約43%のコスト削減を実現しました。開発者は、これらのモデルはメモリなしでもタスクを完了できるほど賢いが、メモリシステムが排除するコードベースの探索にトークンを浪費してしまうと指摘しています。

Haikuの結果は予想外でした：メモリなしでは0/40のスコアでしたが、メモリを使用すると39/40を獲得しました。開発者は、Haikuはプロジェクト構造を理解せずにOpusのチームメイトエージェントを調整できなかったが、メモリアクセスを持つことで有能なリードモデルになったと観察しています。

メモリを使用したSonnetは全体的に最良の構成であり、メモリなしのOpusをすべての指標で約半額のコストで上回りました。重要な教訓は、高価なモデルを使用することよりも、プロジェクトの知識をモデルに利用可能にすることが重要だということです。

技術的詳細

このメモリシステムはStompyと呼ばれ、MCP/API/CLIベースで、Claude Codeと連携します。ベンチマークの設定はGitHubで公開されており、他の人が使用したり改善したりできます。開発者は、これまで各条件でn=1（1回の実行）であるため、さらなる実行を計画していると述べています。