smart-compaction

スマートコンパクション — アイドル時の自動コンパクション管理

概要（1段落）

チャネルセッションではコンテキストが蓄積します。プロンプトキャッシュの TTL を超えるアイドル時間が生じると、次のメッセージではコンテキスト全体を高い料金でキャッシュに書き直します。デーモンには決定論的なスイーパーが組み込まれており、LIVE セッションが auto_compact_idle_minutes の間アイドル状態で、コンテキストが auto_compact_min_context_tokens を超えている場合、通知なしで /compact を実行します。これはすべての環境でデフォルトでは無効です。有効化し、会話ごとに調整するポリシー層はあなた（エージェント）です。Claude はライブストリーミングのサブプロセス上で、インバンドに /compact を実行します。Grok では同じ設定値を使いますが、_x.ai/compact_conversation を実行します（通知はなく、チャネルへの確認応答もありません）。Pi でも同じ2つの設定値を使い、Pi のコンパクションは2層構造です。Pi 独自のネイティブなしきい値コンパクション（ユーザーの Pi 設定を引き継いだもの）が有効なまま、Duoduo のアイドル時自動コンパクションと併存します。両方の層は意図的に共存します。除外されるランタイムは Codex だけです。Grok のコンパクションはトークン数を返さないため、Grok のみのセッションではフューズもコンパクション通知も自己調整されません。最初の Grok のアイドル時コンパクションを、キャリブレーション測定値として扱わないでください。Pi も同様です。コンパクション結果で報告されるのはコンパクション前のサイズだけです（コンパクション直後は、Pi はまだ新しい常駐コンテキストを測定できません）。そのため、Pi のみのセッションでもフューズは自己調整されません。ただし、最悪のケースでのコストは Pi のほうが低くなります。コンパクションする価値がないセッションでは、料金のかかる効果なしのコンパクションではなく、無料の no-op で応答します。

設定値（インスタンスごと、種類ごと）

duoduo session config <session|alias> get            # merged view + per-key source + measured stats
duoduo session config <session|alias> set auto_compact_idle_minutes=50 auto_compact_min_context_tokens=100000
duoduo session config <session|alias> unset auto_compact_idle_minutes   # back to kind default
duoduo session config --kind <kind> set ...          # kind-wide default (ONLY when the user explicitly says "kind"/"所有会话")

• 推奨される初期値（サブスクリプション／TTL が1時間のバックエンド向けに承認済み）： idle_minutes=50（1時間のキャッシュ TTL 内に実行されるため、コンパクション時の読み取りコストは10分の1になります）、min_context_tokens=100000（測定されたコンパクション後の下限の約2倍）。
• オフにするには set auto_compact_idle_minutes=0 を実行します。キャリブレーション済みのしきい値は保持されます。有効／無効の切り替えとキャリブレーションは別のフィールドです（サーモスタットのルール：電源を切っても設定値は忘れません）。初期状態に戻すには、明示的に unset を実行します。
• スコープの原則：デフォルトでは現在のインスタンスを対象にします。ユーザーが明示的にスコープの拡大を求めた場合に限り、--kind を指定します。
• set／unset は、セッションの次回のドレイン時または次の60秒スイープ時に反映されます。再起動は不要です。get は何も変更しません。

統計情報の読み方 — カーネルが事前計算した値を自分で暗算しない

session config get は、コンパクションのたびにセッションの compact_stats を出力します（手動、自動、モデル自身によるリアクティブなコンパクションなど、起点は問いません）。

フィールド	意味
post_total	測定された S_total：コンパクションで下回れない下限（プロンプトチェーン＋要約）
history_post	コンパクション後の履歴サイズ — 要約の出力コスト（数式の O）です
p_estimate	固定プロンプトチェーンのオーバーヘッド（コンパクションでは回収できません）
suggested_min_context_tokens	カーネルが計算した 2 × post_total — デフォルトの再調整目標値です
g_gt1h_since_prev_compact	直近2回のコンパクション間に発生した、コールド（間隔が1時間超の）戻り回数 — 測定された G です
g_5m1h_since_prev_compact	中間隔の戻り回数 — TTL が5分のバックエンドでは、これもコールドになります
idle_ms	自動実行時にセッションがアイドル状態だった時間（手動の場合はありません）
threshold_at_fire	自動実行が発生した時点で有効だった min_context_tokens（手動／リアクティブの場合はありません）

コンパクト通知（カーネル → あなた）

スマートコンパクションが有効なセッションでは（この機能がオフのセッションには注入されません）、任意のコンパクション後、最初の通常ターンに <smart-compact-notice> ブロックが含まれます。

• データ行 — compacted <ts>: ctx <pre>→<post>, history <pre>→<post>。 post は測定された下限値です。基本情報を得るために統計情報を照会する必要はありません。
• 不一致行（キャリブレーションがずれている場合のみ）— threshold <T> < suggested <S> — re-calibrate via smart-compaction skill。これは再調整の合図です。すぐにガードレール 4 を適用してください。また、これはカーネルの FUSE が有効になったことも意味します。しきい値が測定された下限値以下にある間は、自動コンパクトの再実行が拒否されます（その位置で実行してもしきい値を下回ることはなく、利益のないループにしかならないためです）。したがって、自動コンパクトを再び有効にするには再調整が必要です。
• トランスクリプト行 — ディスク上にある、コンパクション前の完全なトランスクリプトのパスです。 コンパクションはコンテキストを要約しますが、何も削除しません。失われた最近の詳細情報を探すには、低コストのサブエージェント（haiku／sonnet）を起動してこのファイルを検索してください。スリム化したばかりのコンテキストにファイル全体を読み込まないでください。memory／dossiers はライブチャットから数時間遅れています。これらは長期記憶のレイヤーであり、最近の情報を想起するためのレイヤーではありません。

損益分岐アルゴリズム（計算だけでは判断できない場合に限る）

C* = (5·O + 1.25·G·S) / (1.25·G − w)

• S ← compact_stats.post_total（このセッションで測定した値。決して推測しないでください）
• O ← 要約の出力サイズ、つまりコンパクト要約自体にかかるトークン数です。compact_stats.history_post（コンパクション後の履歴。通常は約 4K）を使います。履歴の削減量（history_pre − history_post、約 50K になることもあります）は使わないでください。これは削除された量であり、要約にかかるコストではありません。これを使うと C* が桁違いに大きくなります。
• G ← g_gt1h_since_prev_compact（バックエンドの TTL が 5 分クラスの場合は g_5m1h も加算します）。これらはカーネルが台帳から測定した値です。読み取ってください。
• w ← トリガーの温まり具合：バックエンドのキャッシュ TTL が idle_minutes を超える場合は 0.1（サブスクリプション＝TTL 1 時間）、それ以外は 1.0（従量課金 API のデフォルト、Bedrock、Vertex）

適用範囲：この式が有効なのは 1.25·G > w の場合のみです。1.25·G ≤ w の場合、分母はゼロまたは負になります。つまり、どのコンテキストサイズでもコンパクションを採算に乗せるには、サイクルあたりのコールドリターンが少なすぎるということです。この領域は C* ではなく、ガードレール 2（しきい値を上げるか無効にする）に従います。

コンテキストが C* を上回るセッションではコンパクションが有利になり、下回るセッションではコストが増えます。TTL は、把握しているか、確認する必要があるバックエンドの特性です。意図的にカーネルには含まれていません。

G はフィードバック変数であり、固定の入力値ではありません。 設定するしきい値によってセッションのコンパクション頻度が決まり、それによって各コンパクションサイクルの長さが変わり、サイクル内のコールドリターン数も変わります。つまり、次回測定する G 自体が変化します。調整のたびに、設定 → 次の compact_stats（新しい G）を観察 → 再評価、というループの一段階として扱ってください。単一サイクルの G に過剰適合せず、数回のコンパクションを通して傾向を見てください。

ガードレール（厳守事項）

1. 測定した post_total の 1.2 倍を下回るしきい値は絶対に設定しないでください — 物理的な下限を下回ると、圧縮は無意味な churn と忠実度の低下を招くだけです。
2. 従量課金制／TTL の短いバックエンド: 測定した G が 2 以上の場合に限り、100000 を維持してください。G≈1 のセッション（重いタスクを 1 つこなし、一晩おいて戻り、翌日にコンテキストが再び膨らむ）では、コールド状態での損益分岐点は約 305K です。その場合はしきい値を引き上げるか、無効にしてください。
3. 再調整は「実行してから通知」: 変更を適用した後、何をなぜ変更したのかを 1 行でオーナーに伝えてください（例: 「このセッションの圧縮しきい値を 100K から 76K に変更しました — 実測した圧縮後の下限は 38K です」）。黙って変更するのも、長々と説明するのも避けてください。
4. 最初の自動圧縮がキャリブレーションです（compact_stats を書き込む Claude の場合）: 最初の圧縮通知が届いたら、suggested_min_context_tokens を読み取り、その値にインスタンスを再調整してください。新しい種類を使う際に、事前のキャリブレーション手順は必要ありません。Grok はその通知を出さないため、Grok ではこの手順を省略してください。Pi も通知を出しません（圧縮結果に圧縮後の合計値が含まれないため）。Pi でも省略し、損益分岐点の計算式だけでしきい値を調整してください。
5. オーナーが会話を大切にしていると伝えた場合（「この会話のコンテキストには触れないでください」）、そのインスタンスで auto_compact_idle_minutes=0 を設定し、確認してください。
6. 圧縮後、以前の詳細について確信が持てない場合は、直近の具体的な情報については、通知に記載されたトランスクリプトのパスを安価なサブエージェントに検索させてください。長期的な知識については、メモリ／資料集を参照してください。要約だけをもとに情報を再構成してはいけません。
7. チャネルをインストールした後に種類を設定してください。 チャネルがまだインストールされていない種類に対して --kind <kind> を実行すると、種類の設定ファイルが作成されます。その後チャネルをインストールすると、設定ファイルがすでに存在するため初期設定の適用がスキップされ、チャネルが同梱のデフォルト設定なしで起動します。意図的に種類全体へ設定を展開する場合を除き、インスタンス単位の設定（config <session>）を優先してください。

キャッシュ非対応の互換バックエンド

セッションがプロンプトキャッシュにまったく対応していないエンドポイントで動作する場合、すべてのターンでコンテキスト全体の入力料金が発生します。そのため、圧縮の効果は小さくなるのではなく、むしろ大きくなります。同じ設定項目を使い、w=1 として、キャッシュの割増料金は通常の入力料金として計算する同じ計算式を使ってください。