[{"data":1,"prerenderedAt":459},["ShallowReactive",2],{"content-\u002Fcontents\u002Ftokenpilot-context-management":3,"surroundPost-\u002Fcontents\u002Ftokenpilot-context-management":450},{"id":4,"title":5,"body":6,"createdAt":433,"description":434,"draft":435,"extension":436,"meta":437,"navigation":438,"path":439,"seo":440,"stem":441,"tags":442,"thumbnail":448,"updatedAt":433,"__hash__":449},"contents\u002Fcontents\u002Ftokenpilot-context-management.md","TokenPilot: Cache-Efficient Context Management for LLM Agents",{"type":7,"value":8,"toc":387},"minimark",[9,14,21,24,28,31,34,37,40,45,48,52,55,59,62,66,69,73,76,79,82,85,88,91,128,131,151,154,157,160,163,166,169,172,175,178,181,184,187,190,194,197,201,204,208,211,215,218,221,224,227,230,233,236,239,242,245,249,252,256,259,262,265,269,272,276,279,282,296,299,313,317,321,324,328,331,335,338,342,345,349,352,356,359,363,366,370,373,377,380,384],[10,11,13],"h2",{"id":12},"_30秒で言うと","30秒で言うと",[15,16,17],"ul",{},[18,19,20],"li",{},"TokenPilot は、長時間動く LLM エージェントの文脈管理を「どれだけ削るか」ではなく、「prompt cache が効くように、何を安定させ、何を後から戻せる形で外に出すか」として設計し直す論文。",[10,22,23],{"id":23},"人に説明する順番",[25,26,27],"p",{},"まず、長時間動く agent は tool 出力、実行ログ、ファイル内容、過去の判断を抱え込み、context が太るほど費用が増える、という普通の問題から入る。",[25,29,30],{},"次に、単純に context を削ると token は減るが、prompt prefix の並びや境界が変わって cache が効かなくなり、かえって高い prefill が増える、というこの論文のひねりを説明する。",[25,32,33],{},"そのうえで、TokenPilot は入口で文脈を安定化する Ingestion-Aware Compaction と、作業単位の残存価値を見て捨てる Lifecycle-Aware Eviction の二層に分ける、と説明する。",[25,35,36],{},"最後に、重い tool output は preview だけ入れ、元データは artifact registry に残して recovery できるので、削ることと戻れることを両立している、とまとめる。",[10,38,39],{"id":39},"主張マップ",[41,42,44],"h3",{"id":43},"文脈削減は-token-数だけで評価してはいけない","文脈削減は token 数だけで評価してはいけない",[25,46,47],{},"論文は cache hit \u002F miss token と実費用を測り、prefix が崩れると cache miss が増える問題を示している。 agent 運用では、短くしたつもりの context が再読や cache miss で高くつくことがある。",[41,49,51],{"id":50},"入口の安定化と局所履歴の-eviction-は別問題","入口の安定化と局所履歴の eviction は別問題",[25,53,54],{},"TokenPilot は Ingestion-Aware Compaction と Lifecycle-Aware Eviction を分けて設計する。 tool schema、timestamp、path のような揺れと、sub-task が終わった履歴を捨てる判断を同じ仕組みに混ぜないで済む。",[41,56,58],{"id":57},"削るなら-recovery-できることが重要","削るなら recovery できることが重要",[25,60,61],{},"重い tool output は compact preview にし、full payload は artifact registry に残す。Recovery を無効化すると score が落ち、費用も増えると報告されている。 ただ短くするのではなく、必要な時に戻れる設計が、性能と費用の両方を守る。",[41,63,65],{"id":64},"completed-な-context-はすぐ捨てない","completed な context はすぐ捨てない",[25,67,68],{},"Lifecycle-Aware Eviction は active \u002F completed \u002F evictable を分け、残存価値がある間は completed segment を保持する。 作業が終わったように見える情報でも、後続の検証や報告で必要になることがある。",[10,70,72],{"id":71},"_3分で紹介するなら","3分で紹介するなら",[25,74,75],{},"この論文は、長時間動く LLM エージェントの context が膨らみ続ける問題を扱っています。普通に考えると、古い履歴や長い tool 出力を削れば安くなる、となりがちです。",[25,77,78],{},"でも TokenPilot が面白いのは、削るだけでは不十分だと言っている点です。LLM API では prompt prefix が安定していると cache が効きますが、context を途中で削ったり並びを変えたりすると、その cache が壊れて高い prefill が増えることがあります。つまり token 数だけ見ていると、実際の費用を読み間違える。",[25,80,81],{},"そこで TokenPilot は、文脈管理を二層に分けます。入口では path、timestamp、tool schema、重い tool output のような揺れを整えて、prefix を安定させます。作業中の履歴については、active、completed、evictable のように状態を分け、終わったから即捨てるのではなく、残存価値が切れてから捨てます。",[25,83,84],{},"さらに、重い tool output は全部 context に入れず preview だけを置き、元データは artifact registry に残します。必要になったら recovery tool で戻せるので、短くすることと、あとで確認できることを両立できます。",[25,86,87],{},"結論として、この論文は agent の context management を、単なる要約や pruning ではなく、cache、artifact、recovery、lifecycle を含む runtime design として捉え直すものです。おい丸の運用に引きつけるなら、audit log や tool 出力を全文読むのではなく、preview と再取得経路を持つ設計にする、という判断に直結します。",[10,89,90],{"id":90},"誤解しやすい点",[15,92,93,104,112,120],{},[18,94,95,99,100,103],{},[96,97,98],"strong",{},"誤解:"," TokenPilot は単に context を短くする手法である\n",[96,101,102],{},"実際:"," 短くするだけでなく、prefix cache が効くように入力レイアウトを安定させ、必要な情報へ戻れる recovery 経路を持たせる手法である。",[18,105,106,108,109,111],{},[96,107,98],{}," 古い履歴は completed になったら捨てればよい\n",[96,110,102],{}," completed でも残存価値がある間は保持し、evictable と判定されてから捨てる。",[18,113,114,116,117,119],{},[96,115,98],{}," preview にすれば性能は必ず落ちる\n",[96,118,102],{}," preview だけでなく full payload を registry に残し、必要時に recovery できるため、性能低下を抑えながら context を軽くできる。",[18,121,122,124,125,127],{},[96,123,98],{}," どの provider でも同じ効果が出る\n",[96,126,102],{}," 主要な利点は prefix caching support に依存するため、provider や実行環境によって効き方は変わる。",[10,129,130],{"id":130},"理解チェック",[15,132,133,136,139,142,145,148],{},[18,134,135],{},"この論文の中心問いを「token を減らす」以外の言葉で説明できるか。",[18,137,138],{},"なぜ単純な pruning が cache miss を増やしうるのかを説明できるか。",[18,140,141],{},"Ingestion-Aware Compaction と Lifecycle-Aware Eviction の役割分担を説明できるか。",[18,143,144],{},"preview + artifact registry + recovery の3点セットを、自分の運用例に置き換えて説明できるか。",[18,146,147],{},"TokenPilot の結果で、性能・費用・cache hit \u002F miss のどれを見ているかを区別できるか。",[18,149,150],{},"この手法が効きにくい条件を1つ以上挙げられるか。",[10,152,153],{"id":153},"この論文の何がいいか",[25,155,156],{},"この論文の良さは、agent のコスト削減を単なる token 節約ではなく、cache continuity と recovery を含む runtime design として見せているところにある。文脈を雑に削ると、あとで同じファイルを読み直したり、cache miss を増やしたりして、結局高くつく。",[25,158,159],{},"個人 AI assistant や coding agent の運用では、長い作業、複数 tool、wiki や repo の再読、公開ページ生成のようなワークフローが普通に起きる。TokenPilot は、tool 出力を preview + recovery にする、重複 read を抑える、completed だがまだ使う context をすぐ捨てない、という設計判断の言葉をくれる。",[25,161,162],{},"ゆうきさんの関心に引きつけるなら、scheduled-ops や paper-watch の長時間実行を、単に文脈を短くする方向ではなく、再利用できる prefix と戻れる artifact registry を持つ harness として見直す材料になる。",[10,164,165],{"id":165},"どんな論文か",[25,167,168],{},"長期に動く LLM agent は、対話履歴、tool trace、file read、実行ログ、検索結果を抱え続ける。文脈が増えると推論コストが上がるため、従来は pruning、summarization、eviction のような文脈削減が中心になっていた。",[25,170,171],{},"TokenPilot の面白い点は、文脈削減が常に得ではないと正面から言うところにある。入力の一部を削ったり、順序や境界を変えたりすると、prompt prefix がずれて KV cache が効かなくなり、安い cache read ではなく高い cache miss \u002F prefill が増える。",[25,173,174],{},"この論文は、text-level sparsity と hardware-level cache alignment を同時に見る。入口では volatile な path、timestamp、tool schema、重い tool output を整えて prefix を安定させ、局所履歴では task utility が切れるまで context segment を保守的に保持する。",[25,176,177],{},"評価は PinchBench と Claw-Eval を使い、isolated mode と continuous mode の両方で行っている。論文は、TokenPilot が競争的な task performance を維持しながら、費用を大きく下げたと報告している。",[25,179,180],{},"TokenPilot は、LLM agent の長期セッションで増え続ける context を、cache 効率を壊さずに管理するための framework を提案する論文である。",[25,182,183],{},"中心課題は、text pruning や dynamic eviction が token 数を減らす一方で、入力レイアウトを変えて prompt prefix continuity を壊し、KV cache miss を増やしてしまうこと。",[25,185,186],{},"論文は、文脈管理を global ingestion boundary と local context sequence の二層に分け、それぞれ Ingestion-Aware Compaction と Lifecycle-Aware Eviction を置く。",[10,188,189],{"id":189},"課題と貢献",[41,191,193],{"id":192},"ingestion-aware-compaction","Ingestion-Aware Compaction",[25,195,196],{},"入口で volatile な runtime marker を static placeholder に置き換え、tool definitions の位置や tool output の構造ノイズを整えて、byte-identical な prefix を作りやすくする。",[41,198,200],{"id":199},"observation-reduction-with-recovery","Observation Reduction with Recovery",[25,202,203],{},"重い tool output は compact preview として working memory に入れ、元 payload は artifact registry に残す。必要になったら recovery tool で戻せるため、削減と安全な再アクセスを両立する。",[41,205,207],{"id":206},"lifecycle-aware-eviction","Lifecycle-Aware Eviction",[25,209,210],{},"context segment を active、completed、evictable の状態で管理し、completed になっても residual utility が残る間はすぐ捨てない。",[41,212,214],{"id":213},"cache-aware-evaluation","Cache-aware evaluation",[25,216,217],{},"PinchBench と Claw-Eval で、task accuracy だけでなく cache hit \u002F miss token と実際の費用を測る。",[10,219,220],{"id":220},"手法のしくみ",[25,222,223],{},"入力は、agent の task prompt、thinking trace、tool call、final response、tool feedback などの混在した message stream である。",[25,225,226],{},"まず message を internal intentional messages と open-world environmental feedback に分ける。前者は高密度の情報として扱い、後者は HTML、terminal log、重複 read などのノイズを含みやすいものとして扱う。",[25,228,229],{},"global 側では、path や timestamp のような volatile fields を stable placeholder に置き換え、tool definitions を primary system prompt から動かして prefix mismatch を減らす。",[25,231,232],{},"environmental feedback は、HTML slimming、execution output truncation、deduplication、frequency limit などの reduction pass で compact preview にする。元の full payload は content hash で artifact registry に残す。",[25,234,235],{},"local 側では、context segment ごとに active、completed、evictable の状態を持たせる。sub-task が終わっても、後続作業で必要な可能性があれば completed として残す。",[25,237,238],{},"状態推定は毎 turn ではなく、batch size B ごとに保守的に行う。論文では、過剰に頻繁な eviction は layout consistency を壊し cache miss を増やすため、batch scheduling が重要だと示している。",[25,240,241],{},"evictable と判定された segment だけを構造的に purge し、context window を作り直す。必要なら recovery tool が full payload を戻し、削りすぎによる再読ループを防ぐ。",[10,243,244],{"id":244},"検証結果",[41,246,248],{"id":247},"isolated-mode","Isolated mode",[25,250,251],{},"TokenPilot は PinchBench で $3.22、Claw-Eval で $2.27 の総推論費用を示し、競争的な task accuracy を維持したと報告されている。",[41,253,255],{"id":254},"continuous-mode","Continuous mode",[25,257,258],{},"PinchBench では score 81.3、費用 $2.79、cache miss 1.549M tokens と報告されている。Claw-Eval では Vanilla の $81.52 に対し TokenPilot は $10.58 まで下げたとされる。",[41,260,261],{"id":261},"全体の費用削減",[25,263,264],{},"abstract では isolated mode で 61% と 56%、continuous mode で 61% と 87% の費用削減を報告している。",[41,266,268],{"id":267},"ablation","Ablation",[25,270,271],{},"Ingestion-Aware Compaction により費用が $7.24 から $4.22 へ下がり、Lifecycle-Aware Eviction を重ねると $2.79 まで下がる。stable placeholders は cache hit rate を PinchBench で 38.7% から 79.2%、Claw-Eval で 67.2% から 83.1% へ改善したと報告されている。",[41,273,275],{"id":274},"recovery-の役割","Recovery の役割",[25,277,278],{},"full content access を無効にすると score が 80.9 から 77.1 に落ち、費用も $4.03 へ増える。削るだけでなく、戻れることが性能と費用の両方に効いている。",[10,280,281],{"id":281},"課題と議論",[15,283,284,287,290,293],{},[18,285,286],{},"model-based estimator は、曖昧または情報が少ない interaction pattern では context segment を誤分類する可能性がある。",[18,288,289],{},"frequency threshold や batch size B は、deployment environment や task distribution に合わせた調整が必要になる。",[18,291,292],{},"prefix stabilization は provider 側の prefix caching support に依存する。prefix cache がない provider では主要な利点が出にくい。",[18,294,295],{},"continuous mode の評価は同カテゴリタスクが連続する環境を前提にしている。カテゴリが激しく混ざる stream では tool schema の変化により prefix reuse が下がる可能性がある。",[10,297,298],{"id":298},"次に読むなら",[15,300,301,304,307,310],{},[18,302,303],{},"まず Introduction を読み、文脈削減が cache miss を増やすという問題設定を押さえる。",[18,305,306],{},"次に 3.2 と 3.3 を読む。入口で整えるものと、局所履歴として残すものの分担を見る。",[18,308,309],{},"実装感をつかむなら Appendix A.4 を読む。execution output truncation、deduplication、frequency limit、recovery tool の具体値が出ている。",[18,311,312],{},"関連して読むなら、HarnessX、Is Grep All You Need?、Agent Memory、STALE を並べると、harness、検索、記憶、鮮度管理がつながる。",[10,314,316],{"id":315},"読後qa","読後Q&A",[41,318,320],{"id":319},"この論文の中心問いは","この論文の中心問いは？",[25,322,323],{},"LLM agent の長期文脈を、task performance を落とさず、prompt cache を壊さず、低コストで管理するにはどうすればよいか。",[41,325,327],{"id":326},"なぜ単純な-context-pruning-では足りない","なぜ単純な context pruning では足りない？",[25,329,330],{},"token 数は減っても、入力境界や prefix が変わると KV cache が効かなくなり、高い cache miss \u002F prefill が増えるため。",[41,332,334],{"id":333},"ingestion-aware-compaction-は何をする","Ingestion-Aware Compaction は何をする？",[25,336,337],{},"path、timestamp、tool schema、重い tool output などを入口で整え、prompt prefix を安定させ、必要なら full payload に戻れる preview を作る。",[41,339,341],{"id":340},"lifecycle-aware-eviction-は何をする","Lifecycle-Aware Eviction は何をする？",[25,343,344],{},"context segment を active、completed、evictable として管理し、sub-task が終わっても残存価値がある間はすぐ捨てない。",[41,346,348],{"id":347},"preview-recovery-はなぜ重要","preview + recovery はなぜ重要？",[25,350,351],{},"重い tool output を短く保ちつつ、必要な時に元 payload を戻せるため、削りすぎによる性能低下や再読ループを避けられる。",[41,353,355],{"id":354},"どんな-benchmark-で評価している","どんな benchmark で評価している？",[25,357,358],{},"PinchBench と Claw-Eval を使い、isolated mode と continuous mode の両方で task performance、cache hit \u002F miss、費用を測っている。",[41,360,362],{"id":361},"主な結果は","主な結果は？",[25,364,365],{},"abstract では、isolated mode で 61% と 56%、continuous mode で 61% と 87% の費用削減を報告し、競争的な性能を維持したとしている。",[41,367,369],{"id":368},"おい丸運用にどう効く","おい丸運用にどう効く？",[25,371,372],{},"tool 出力を全部積むのではなく、preview、artifact registry、recovery、重複 read の置換、completed context の保守的保持として設計できる。",[41,374,376],{"id":375},"注意点は","注意点は？",[25,378,379],{},"prefix caching を持つ provider が前提で、task が激しく混在すると prefix reuse が下がる可能性がある。状態推定の誤分類にも注意が必要。",[41,381,383],{"id":382},"次に見るならどこ","次に見るならどこ？",[25,385,386],{},"Introduction、3.2、3.3、Appendix A.4 を読むと、問題設定、二層設計、実装パラメータまでつながる。",{"title":388,"searchDepth":389,"depth":389,"links":390},"",2,[391,392,393,400,401,402,403,404,405,411,412,419,420,421],{"id":12,"depth":389,"text":13},{"id":23,"depth":389,"text":23},{"id":39,"depth":389,"text":39,"children":394},[395,397,398,399],{"id":43,"depth":396,"text":44},3,{"id":50,"depth":396,"text":51},{"id":57,"depth":396,"text":58},{"id":64,"depth":396,"text":65},{"id":71,"depth":389,"text":72},{"id":90,"depth":389,"text":90},{"id":130,"depth":389,"text":130},{"id":153,"depth":389,"text":153},{"id":165,"depth":389,"text":165},{"id":189,"depth":389,"text":189,"children":406},[407,408,409,410],{"id":192,"depth":396,"text":193},{"id":199,"depth":396,"text":200},{"id":206,"depth":396,"text":207},{"id":213,"depth":396,"text":214},{"id":220,"depth":389,"text":220},{"id":244,"depth":389,"text":244,"children":413},[414,415,416,417,418],{"id":247,"depth":396,"text":248},{"id":254,"depth":396,"text":255},{"id":261,"depth":396,"text":261},{"id":267,"depth":396,"text":268},{"id":274,"depth":396,"text":275},{"id":281,"depth":389,"text":281},{"id":298,"depth":389,"text":298},{"id":315,"depth":389,"text":316,"children":422},[423,424,425,426,427,428,429,430,431,432],{"id":319,"depth":396,"text":320},{"id":326,"depth":396,"text":327},{"id":333,"depth":396,"text":334},{"id":340,"depth":396,"text":341},{"id":347,"depth":396,"text":348},{"id":354,"depth":396,"text":355},{"id":361,"depth":396,"text":362},{"id":368,"depth":396,"text":369},{"id":375,"depth":396,"text":376},{"id":382,"depth":396,"text":383},"2026-06-16","TokenPilot は、長期 LLM agent の文脈管理を「削る」だけでなく、prompt cache が効く形で入力レイアウトを安定させる問題として扱う論文。入口で文脈を整え、残存価値が切れたものだけを保守的に捨てる二層設計を提案する。",false,"md",{},true,"\u002Fcontents\u002Ftokenpilot-context-management",{"title":5,"description":434},"contents\u002Ftokenpilot-context-management",[443,444,445,446,447],"論文まとめ","Context Management","Prompt Cache","Long-Horizon Agents","LightMem2","\u002Farticle-pages\u002Fdocs\u002Fassets\u002Fgraphic-recordings\u002Ftokenpilot-context-management.png","5QIOspgG5JNJbUO66rNVxMRPNRqo-lM6yD15yUxmqVA",[451,455],{"title":452,"path":453,"stem":454,"children":-1},"PyTorchでTensorBoardを使う方法","\u002Fcontents\u002Ftensorboard","contents\u002Ftensorboard",{"title":456,"path":457,"stem":458,"children":-1},"Beyond Similarity: Trustworthy Memory Search for Personal AI Agents","\u002Fcontents\u002Ftrustworthy-memory-search","contents\u002Ftrustworthy-memory-search",1782055096897]