既知の
制限事項
正直なドキュメントを信条としています。lean-ctx の得意分野と--その限界をご確認ください。
圧縮の 限界
トークン節約はファイルタイプ、コンテンツの複雑さ、読み取りモードにより異なります。実際に期待できる効果をご覧ください。
シナリオ別の予想節約量
| シナリオ | 節約量 |
|---|---|
| 初回読み取り（コードファイル） | 60–95% |
| キャッシュ済み再読み取り | 最大99% |
| 小さいファイル（<10行） | わずか |
| バイナリファイル | スキップ |
| 未知のShell出力 | パススルー |
コンテンツ依存の節約
実際の節約はコード密度、コメント比率、繰り返しに依存します。明確なシグネチャを持つ構造化されたコードは、密集した無注釈の一行コードよりも効果的に圧縮されます。
キャッシュ済み再読み取り
lean-ctx がすでにファイルを読み取り、変更がない場合、再読み取りはファイルサイズに関係なく約13トークンです。これが99%の根拠です。
言語 サポート
lean-ctx はAST対応圧縮にtree-sitterを使用しています。カバレッジは言語により異なります--全体像をご覧ください。
言語サポートティア
| ティア | 言語 | 圧縮方式 |
|---|---|---|
| フルAST | Rust、TypeScript、Python、Go、Java、C、C++、C#、Ruby、PHP、Swift、Kotlin、Scala、Lua、Zig、Elixir、Haskell、OCaml | シグネチャ認識プルーニング |
| ベーシック | その他すべての言語 | 行ベース圧縮 |
ベーシックティアでも意味のある圧縮を提供します--関数シグネチャの抽出やASTノードのプルーニングができないだけです。重複排除とエントロピーフィルタリングにより、ほとんどのファイルで40–70%の節約が見込めます。
アーキテクチャ 制約
lean-ctx は特定のアーキテクチャ上のトレードオフを前提に設計されています。これらを理解することで、適切な期待値を設定できます。
MCPの要件
lean-ctx はMCPサーバーとして動作します。AIエージェントがModel Context Protocolをサポートしている必要があります。
対応：Claude Code、Cursor、Codex、Gemini CLIなど。
単一プロジェクトスコープ
各lean-ctxインスタンスは1つのプロジェクトルートに限定されます。マルチリポジトリのワークフローには別々のインスタンスが必要です。
回避策：ワークスペースのリポジトリごとに1インスタンスを実行。
メモリスケーリング
インメモリキャッシュはプロジェクトとともに増加します。非常に大きなモノレポ（10万ファイル以上）ではキャッシュ制限の調整が有効な場合があります。
lean-ctx設定で構成可能。
代替には ならない
lean-ctx はLLMへのコンテキスト配信を最適化します。優れたエンジニアリングの基本を置き換えるものではありません。
- 適切なプロンプティング - 明確で具体的な指示は依然として重要です
- 適切なコード構成 - よく整理されたコードはより効果的に圧縮されます
- バージョン管理 - lean-ctx はコードの変更や履歴を管理しません
lean-ctx は配信を最適化し、基本を置き換えません。
lean-ctx に できること
限界を理解した上で、lean-ctx がその範囲内で提供するものを探索してください--セキュリティ保証、パフォーマンスベンチマーク、競合比較。