Lowfat: LLMトークン使用量を削減するためのプラグイン可能なCLIフィルタ

Lowfatは、AIエージェントに到達する前に不要なコマンドライン出力をフィルタリングすることで、AIトークンコストを削減する軽量なCLIツールです。CLIレスポンスからノイズを取り除くことで、コンテキストウィンドウの肥大化を防ぎ、LLM API呼び出しの金銭的コストを低減します。

コアアーキテクチャと設計思想

Lowfatは、UNIXスタイルのパイプ原理に従う、構成可能でローカルファーストなユーティリティとして構築されています。その設計は、「魔法のような」自動フィルタリングよりも、ユーザーによる制御と拡張性を重視しています。

  • Local-First: このツールにはテレメトリが含まれておらず、データがユーザーの管理下に留まることを保証します。
  • Composable: パイプを介して、組み込みフィルタとカスタム定義されたフィルタを組み合わせて使用できます。
  • Lightweight: 最小限のコアを持つ、小さな単一バイナリとして配布されます。
  • User-Owned: ユーザーは lowfat history を通じて最も頻繁に使用するコマンドを追跡し、カスタマイズが最も必要とされる箇所を特定できます。

インストールと統合

Lowfatは、Cargo (cargo install lowfat) または Homebrew (brew install zdk/tools/lowfat) を介してインストールでき、GitHub Releasesでビルド済みのバイナリも利用可能です。

エージェント統合

Lowfatは、AIエージェントのワークフローへの透過的な統合のためのいくつかの方法を提供します。

  • Claude Code: .claude/settings.json 内の PreToolUse フックとして追加することで、Bashコマンドをフィルタリングできます。
  • Shell Integration: CLAUDECODE=1 または CODEX_ENV が設定されている環境で自動的にアクティブ化されます。または、シェル設定ファイルに eval "$(lowfat shell-init zsh)" を追加することで、LOWFAT_ENABLE=1 を介して強制的に有効化できます。
  • OpenCode: lowfat opencode install を介して統合されます。これは ~/.config/opencode/plugins/lowfat.ts にプラグインを書き込み、コマンドを透過的に書き換えます。
  • Pi Agent: ~/.pi/agent/settings.json 内の shellCommandPrefix フィールドを使用して設定します。

直接使用

ユーザーは、lowfat git status や lowfat docker ps のように、任意のコマンドにプレフィックスを付けて手動で出力をフィルタリングできます。

管理と拡張性

Lowfatには、節約額のモニタリングと機能拡張のためのツールスイートが含まれています。

  • Monitoring: lowfat stats は累積のトークン節約量を提供し、lowfat stats --audit は最近のプラグイン実行を表示します。
  • Configuration: lowfat info は、特定のコマンド（例：lowfat info git）のアクティブなフィルタとパイプラインを表示します。
  • Customization: ユーザーは lowfat level ultra を使用してフィルタリングの強度を設定したり、環境変数を使用して一時的なオーバーライドを行ったりできます（例：LOWFAT_LEVEL=lite lowfat git log）。
  • Plugin Development: 新しいフィルタは lowfat plugin new <name> を使用してスキャフォールディング（雛形作成）でき、lowfat plugin doctor で検証できます。

コミュニティの洞察とトレードオフ

Lowfatはトークン使用量を最適化することを目指していますが、コミュニティの議論では、コンテキスト管理に関するいくつかの重要なトレードオフと代替戦略が強調されています。

過剰なフィルタリングのリスク

いくつかのユーザーは、攻撃的なフィルタリングが、LLMが問題を解決するために必要な特定のスタックトレースなどの重要な情報を削除してしまう可能性があるという懸念を表明しています。あるユーザーは、このカテゴリのツールが時として「エージェントを助けるよりも混乱させる」ことがあり、欠損データを取り戻すためにエージェントがより多くのAPI呼び出しを行うようになり、結果としてコスト削減が相上のとなる可能性があると指摘しています。

ポストフィルタリングに対する戦略的代替案

実行後のフィルタリングを批判する人々は、その根本的な原因は、エージェントが広すぎるコマンドを使用していることにあると示唆しています。

"kubectl get -o yaml when a jsonpath query would give 1/50th the tokens. filtering after the fact works, but you're still paying for the round trip."

代替案として、以下が提案されています：

  • エージェントに正確さを教える: 広すぎる出力をフィルタリングするのではなく、エージェントに狭いクエリ（例：jsonpath を使用）を書くよう促すことです。
  • Response Truncation with Pointers: 出力を切り詰め、代わりにLLMに特定のテンポラリファイルパスを通じてフルテキストが利用可能であることを通知することで、LLMが、必要な部分のみをクエリできるようにします。
  • Local Pre-Filtering: 安価でローカルなLLMを使用して、CLI出力の「意味のある」部分のみを特定し、抽出する前に、より高価で大規模なモデルに渡す前に、ローカルLLMで抽出を行います。

ベンチマークと主張の妥当性

高い節約率の主張には懐疑的な見方もあります。一部のユーザーは、特定のコマンドの出力トークンを削減することは、タスク全体で使われる総トークン数の全体的な削減には必ずしも等価ではないと主張しています。プロンプト全体やエージェントの推論論理が依然としてかなりのリソースを消費するためです。

Sources