OpenClawエージェント、65%コンテキストで故障：683kトークン、Ollama/GLMでキャッシュ読み取りゼロ

ある開発者が、Ollama Cloud上のGLM 5.3 Flashに対して、DiscordでFrancisというOpenClawエージェントを約23時間走らせた。名目上のコンテキストウィンドウは1,048,576トークン。複数のDiscordチャンネルにまたがる約6人の人間が、ツール呼び出し、レシート処理、コーディング作業、コードレビュー、ファイル読み込みをこなしながら会話した。約800件のトランスクリプトイベントを乗り切り、その後、設定されたコンテキストウィンドウの約65%で完全に失敗した。

障害のタイムライン

• 約68.3万トークン: Francisは、完了したセットアップ作業に関するメッセージに対し、約19時間前に議論されたまったく無関係なジョブの指示で応答した。英語としては依然として筋が通っているが、タイミングが完全にずれていた。
• 2分後: 古いタスクに関する長い内部計画の独白が続き、その後designという単語の数百回の繰り返しに崩壊した。
• その後: チェックマーク、tool tool tool、toolResult、偽のトランスクリプト、繰り返される数字、自身のオーケストレーションエンベロープの断片。
• 約68.8万トークン: 最後の壊れたターン。

セッションは回復しなかった。通常の制御（/new、/reset、/stop）では中断できず、オペレーターはOpenClawセッション自体を強制終了せざるを得なかった。

本当に重要な点：成功として報告された

オーバーフローエラーも、プロバイダーエラーも、タイムアウトもなかった。ハーネスの視点では、design design designは完全に有効なモデル完了だった。自動コンパクションは、ウィンドウの約25%が残った時点で発動するはずだったが、安全網が作動する約10万トークン手前で破綻した。

キャッシュ統計：cacheRead=0、cacheWrite=0

影響を受けたすべてのOllama/GLMのターンで、可視のキャッシュ読み取りとキャッシュ書き込みがゼロだった。キャッシュテレメトリが利用できないかゼロだったため、OpenClawには繰り返されるプレフィックスが再利用されている証拠がなかった。最後の25分間の約10ターンはそれぞれ約68万トークンのプロンプトを運び、その短い時間枠で約610万入力トークンが押し込まれた。

主崩壊の直前に別のエージェントセッションが6,912,253入力トークン、28,956出力トークン、キャッシュ読み取りゼロ、コンパクションゼロ、タイムアウトなし、プロバイダーエラーなしを記録した。数分後、そのエージェントは自身の会話履歴に捏造された人物、ツール、チャンネルが含まれていると主張し、コンテキストのどの部分が本物かもはや判別できないと認めた。

キャッシュに関する会話

崩壊の数分前、オペレーターはFrancisに、システムを通る反復テキストを考慮するとキャッシュレイヤーを構築する価値があるかと尋ねた。Francisは自信を持って、繰り返されるコンテキストはプロバイダー側でプロンプト/KVキャッシュによりすでに安価なので、有益なことは何もないと答えた。これはOpenAIやAnthropicでは正しい答えだ。安定したプレフィックスがキャッシュされ、テレメトリがそれを証明するからだ。しかし、使用中のOllama/GLMルートではそれは誤りだった。エージェントは実質的にオペレーターに「この部分は安価だ」と言いながら、ハーネスは毎ターン約68万トークンを再送信していた。

結論は「小型モデルはダメ」ではない。エージェントはまずほぼ丸一日、実際の作業を行った。問題は、ハーネスが存在しないキャッシュを信頼し、約75%より前にコンパクションのトリガーがなく、退化した出力を正常完了として扱ったことだ。検証可能なキャッシュテレメトリを持たないプロバイダーに対して長コンテキストエージェントを実行するなら、コンテキストの割合だけでなく、入力トークンの蓄積を監視すべきだ。