ZeroClawのストリーム中断：復旧と再試行の境界

ZeroClawは壊れたストリームを再開しません。ターンを再送信するかどうかは、プロファイルにいくつ候補があるかに依存し、現在の唯一のリリースではドキュメントの約束どおりとは限りません。ZeroClawのv0.8.5のドキュメント（2026年9月5日公開）では、出力前に失敗したストリームはストリーミングなしで再試行され、出力後に失敗したストリームは再実行されないと説明されています。2026年10月1日にストリームが返信途中で切断されるエンドポイントに対して実行したところ、v0.8.5のターミナルクライアントはより単純な動作をしました。候補が1つの場合、テキストが表示される前後を問わず再試行はありませんでした。候補が2つの場合、回答の一部が画面に表示された後でも、2つ目のモデルへストリーミングなしでターンを再送信しました。部分出力後のガイド付きリカバリは、設計承認に達していない未解決の機能リクエストです。したがって、役立つ問いはZeroClawに再試行させる方法ではありません。そのターンを安全に再送信できるか、そして失敗した試行ですでにどのようなコストが発生したかです。

これを実行可能な情報として扱う前に、対象範囲について2点記します。実行内容は限定的です。v0.8.5のリリースバイナリを対話型ターミナルモードで使用し、1つのOpenAI互換エンドポイントと、意図的にストリームを閉じるローカルテストサーバーを使いました。結果は以下のとおりです。チャネル、ゲートウェイWebSocket、RPC、ACP、Anthropicスロット、実際のプロバイダー障害は検証していません。それ以外の主張はすべて、2026年9月21日に、リリースタグv0.8.5のリポジトリ、バージョン固定されたdocs.zeroclaw.com/v0.8.5/のドキュメント、または日付付きの上流issue報告から読み取ったものです。また、そのURLは自分で固定してください。READMEは/master/パスへ誘導しますが、そのHEADはリリースより16日先行しており、まさにこの話題についてリリース版と矛盾しています。一方、/latest/は404を返します。ここでいうZeroClawはzeroclaw-labs/zeroclawランタイムを指します。実行しているものがそれか確信できない場合は、ZeroClawとOpenClawの比較で、同じ名前を共有するプロジェクトやフォークと区別できます。

v0.8.5における4つのマーカー。そのうちネットワークを示すのは1つだけ

何かを判断する前に、実際に受け取ったマーカーを確認してください。v0.8.5のZeroClaw英語ロケールファイルでは、これらは独立したFluentキーとして定義されています。ヘッダーコメントには、ターンが途中で打ち切られたときにアシスタント出力へ追加または保存され、channels、WS、RPC、ACP、CLIのすべてのトランスポートでエンドユーザーに表示されると記載されています。

5つ目のキーturn-failed = [turn failed]はmasterの同じファイルに存在しますが、v0.8.5のロケールファイルにはないため、リリース済みビルドでは出力されません。後から読み取れる内容を変えるため、知っておく価値のある動作が1つあります。ターンエンジンは、部分テキストが空でない場合に限り、マーカーを末尾に追加して部分テキストを保存します。推論またはプロバイダー側で事前実行されたツールイベントを生成しても、表示可能なテキストがなかったターンは何も保存されません。コードコメントでは、保存とはコンシューマーがすでに見た内容をコミットすることだと説明されています。他のロケールにも同じキーに翻訳済みの値が設定されているため、非英語環境で表示されるのは英語の角括弧文字列そのものではありません。

再試行の境界が実際に存在する場所

判断は、何かがすでに不変イベントシンクに到達したかという1つの問いに集約されます。

存在するノブはグローバルであり、エンドポイント単位ではありません。[reliability] には、文書化されたデフォルト値が2の provider_retries と、デフォルト値が500の provider_backoff_ms が含まれ、ライフサイクルドキュメントでは、マテリアライズされた各エントリが最大 provider_retries + 1 回試行されると記載されています。v0.8.5の設定リファレンスには、これらと併せてプロバイダー単位またはエイリアス単位の再試行オーバーライドは記載されていません。キーのプールにも頼らないでください。v0.8.5のドキュメントによれば、reliability.api_keys は現在機能するフェイルオーバーではありません。ラッパーは再試行可能なレート制限の後に代替キーを選択してログに記録しますが、構築済みのプロバイダーにそれを適用できないため、再試行でも元の認証情報が使用されます。救済を期待して追加した2つ目のキーも、救済にはなりません。

1つのエンドポイントを指す構成が影響を受けます

これは、単一のゲートウェイまたは単一のベンダーエンドポイントに対してZeroClawを実行する人にとって最も明確な境界です。1つのエンドポイントは、定義上、単一候補の信頼性構成だからです。Issue #10736 は、リリース済みビルドでその形態の出力前ストリーム障害が発生すると、非ストリーミングチャットへのフォールバックをログに記録した後、それを一度も送信せず、All model providers/models failed after 0 failure event(s) でターンを終了させると報告しています。これは2026年9月18日にクローズされました。v0.8.5の公開後であるため、修正はmasterにのみ存在します。2026年10月1日に実行したところ、リリース版v0.8.5は問題の記述どおりに動作しました。リクエストは1回だけ送信され、その後にそのエラーが発生しました。ストリームがテキストの表示前に途切れた場合でも、表示後に途切れた場合でも同じでした。

ここでは2つの公式見解が食い違っており、どちらも併記する価値があります。v0.8.5のアーキテクチャドキュメントは非ストリーミング再試行を約束していますが、issueはリリース済みビルドがそれを実行していないことを示しており、期待される動作のセクションでは、実際に試行される場合にのみログでフォールバックを主張するよう求めています。その後masterには、リリース版にはない単一候補の復旧許可が追加されました。しかし、issue #10787 は、その許可が RetryDecision::Admit(0) によって、provider_retries に関係なく、バックオフなしで付与されたと述べています。そのため、過負荷状態の上流サービスに対して、同じ過負荷時間帯へ即座に再送されました。このissueは2026年9月26日に完了としてクローズされました。v0.8.5の後のmaster上でのことであり、どのリリースにも含まれていません。masterの動作は現在も変化しているため、それを前提に計画しないでください。

文書化された緩和策の形は設定であり、設定項目ではありません。プロファイルに2つ目の候補を与え、信頼性の探索が進める先を用意します。2026年10月1日には、ターミナル上のv0.8.5でそれが機能しました。ただし、頼る前に知っておくべき注意点があります。復旧リクエストは最初のモデルではなく2つ目のモデルに送られたため、中断後に得られる回答はフォールバックからのものです。ZeroClaw APIのコストとセットアップガイドでは、これらのエントリを配置する設定形式を説明しています。

ストリームが切断されたときのv0.8.5の動作

2026年10月1日、リリースの SHA256SUMS に対してチェックサム検証を行ったv0.8.5のリリースバイナリを、使い捨てコンテナ内で対話型ターミナルモード、つまりストリーミングを行うモードで実行しました。単一メッセージの -m モードは、ストリーミングなしのリクエストを1回送信するだけで、このパスには到達しません。provider_retries = 2 を設定した1つのOpenAI互換カスタムスロットプロファイルで、ローカルテストサーバーを指定しました。このサーバーは通常のストリームで応答し、最初のイベントの前、またはテキスト1チャンクの後に、[DONE] なしで接続を閉じました。

v0.8.5でターミナルからZeroClawを実行する人には、3つの点が当てはまります。再現された単一候補の障害は#10736です。provider_retries では変化しませんでした。文書化された「表示可能な出力後は再実行しない」という境界は、ここでは適用されませんでした。ターミナルにすでに表示されたテキストは再送を止めなかったため、途中まで到達するのを見届けたターンが、別のモデルへ再送される可能性があります。また、ターンのログは最初のモデルをターンのモデルとして記録していた一方、テキストは2つ目のモデルから来ていました。これはv0.8.5自身のドキュメントが警告している帰属のずれです。この実行で対象外となるものは、TelegramやSlackなどのチャネル、ゲートウェイWebSocket、RPCおよびACPクライアント（再実行しないルールがイベントシンク向けに記述されているトランスポート）、Anthropicスロット、実際のプロバイダー障害、そしてKunavo経由のリクエストです。

再送する前に：すでに実行されたものと、すでに請求されたもの

ZeroClaw自身のツールループは、ストリームを最後まで読み、終了後にツール呼び出しを復旧して実行し、その後のアシスタントターンのために新しいストリーミング呼び出しを開始します。したがって、途切れた反復で要求されたツールは 実行されていません。しかし、これは聞こえるほど安心できる話ではありません。プロバイダー側で事前実行されたツール呼び出しは、上流ですでに効果を発生させている別のイベントクラスであり、まさにそのため再実行を妨げます。また、長いターンは後半で途切れます。#10736では、直前のツール呼び出しが障害発生前に正常完了していたと記載され、#10787のログでは、リクエストに126件のメッセージが含まれた反復2で途切れています。元のプロンプトを再送すると、モデルが繰り返すであろう、それ以前のすべての副作用が再実行されます。

見た目が整ったトランスクリプトも証拠にはなりません。イシュー #9421 は、AnthropicとOpenAI互換の両プロバイダーファミリーに対して優先度p1でオープンしており、未完了の終端応答が成功として報告される可能性があるというタイトルです。Code/ACPでは、さらに2件のオープン中のp1報告があり、失敗したターンによって受理済みのプロンプトと完了済みのツール交換が永続履歴から破棄される問題（#10788）と、予算超過したターンによってセッション復元後に表示済みの進行状況が失われる問題（#10659）を説明しています。また、中断されたターンの進行状況を永続化するプルリクエストはまだマージされていません。いずれも2026年9月21日時点でオープンしており、いくつかは進行中とマークされているため、このスナップショットを引用するのではなく再確認してください。

コストについては、v0.8.5とmasterで実際に見解が異なるため、自分のビルドに一致する方を読む必要があります。リリース版のドキュメントでは、最終レコードをすべての試行の正規台帳ではなく成功通知と呼び、試行ごとのコスト精度をそこから推測しないよう述べています。masterでは、その段落が プルリクエスト #8966 に由来する試行ごとの usage_by_provider 台帳に置き換えられています。これは2026年9月18日にマージされたもので、どのリリースにも含まれておらず、master自身もイベント計装されたターンパスに限定しています。一方、中断されたストリームの使用量スナップショットは任意フィールドであり、存在しない場合があります。またZeroClawは、OpenAI互換エンドポイントに対して最終SSEチャンクで使用量を要求しますが、切断されたストリームはそのチャンクを送信しない可能性があります。この最後の点は、自分のコスト出力で確認すべき仕組みとして扱い、測定結果とはみなさないでください。代わりに、エンドポイント自身の使用量記録と照合してください。Kunavoでは、それが 使用量ログ です。

モデルの前段にゲートウェイを置くとこのマーカーが生成される理由

最も可能性の高い第三者側の原因は、完了シグナルが到着しないことです。ZeroClawの v0.8.5ストリーミングドキュメント では、トランスポートは成功シグナルとして接続終了に依存しないと説明されています。OpenAI互換ストリームは [DONE] で、OpenAI Responsesストリームは終端レスポンスイベントで、Anthropicストリームは message_stop で完了し、サーバーはこれらのイベント後もHTTP接続を開いたままにする場合があります。シグナルなしでストリームが閉じると、短い成功としてではなく、SSE stream closed before {completion_signal}: response truncated というエラーとして扱われます。これはZeroClawではなく、エンドポイントの不具合です。文書化された例外が1つあります。Anthropicパーサーは現在、空でない message_delta.stop_reason の後のEOFを、message_stop がなくても完了として扱います。また、それを必須にすることを提案する プルリクエスト は、どちらのrefにもまだ取り込まれていません。

2つ目の原因は、開いたソケット上の無通信です。ZeroClawはリクエスト全体の期限ではなく、バイトの受信がない時間に基づくタイムアウトを使用しており、OpenAI ResponsesおよびOpenAI互換プロバイダーでは300秒、Anthropicでは90秒と文書化されています。ボディを読み取るたびにタイマーがリセットされます。上流レスポンスをバッファリングして1分半の間何も転送しないエンドポイントは、Anthropicファミリーのスロットではタイムアウトを引き起こしますが、OpenAI互換のスロットではタイムアウトに至りません。Anthropic Messagesエンドポイントは、custom ではなく、uri による上書き設定を伴う anthropic スロットに設定するため、この違いを知っておく価値があります。2つのワイヤープロトコルについては、MessagesのベースURLドキュメント と OpenAI互換API を参照してください。

停止したターンのコストを、例示的な算術で見る

2つの請求を分けて考えてください。ZeroClawランタイムは$0です。zeroclaw.com によれば、オープンソースであり、MITまたはApache-2.0のデュアルライセンスで、サブスクリプションもホスト型シートもありません。支払うのは自分のLLMプロバイダーのコストだけであり、Ollamaでローカルモデルを実行すればまったく費用はかかりません。再開、大きな再試行予算、誘導付き復旧を解除するティアはありません。ティア自体が存在しないためです。

中断が影響するのはモデルの請求です。これらの数値は 仮定に基づくトークン算術であり、測定されたタスクコストでも請求額の上限でもありません。1ターンで キャッシュされていない入力トークン110,000個 を送信し、ストリームが停止する前に 出力トークン2,000個 を受信すると仮定します。この入力数は、#10787に記録された、日付が明記された単一の過負荷事例でのプロンプトサイズです。その事例では、上流がリクエストを受理し、prefillを実行してからリクエストを破棄しました。3回試行の列は、文書化されたデフォルト値2における provider_retries + 1 です。料金は、100万トークンあたりの現在の Kunavoカタログ 価格です。

各エンドポイントが負荷制御のために受け付けずに破棄したリクエストに課金するかどうかは、そのエンドポイント独自の課金ポリシーによります。ZeroClawのソースコードにもドキュメントにも、その点に関する記載はありません。また、このページでは、どのプロバイダーについてもその課金の有無を測定していません。ここで示す計算は、この問題の規模を把握するためのものであり、答えを出すためのものではありません。Kunavoのカタログ記載額は請求額の上限ではなく下限です。上流プロバイダーが課金額を報告した場合、請求額は、カタログ記載の費用と、上流プロバイダーの費用に適用されるマークアップを掛けた額のうち、大きい方になります。最小チャージ額はプリペイドクレジットで$10です。これは入金額の下限であり、タスク料金やサブスクリプションではありません。課金の詳細をご覧ください。

この障害に最も耐えられるルートはどれか

どれを選んでも、運用上のルールはZeroClawがすでにエンコードしているものです。[stream interrupted] の後、永続化された部分出力を読み、すでに効果が発生したものを確認してから、元のものより狭い内容を再送します。OpenAI互換およびMessages形式のエンドポイントに関するKunavoの設定リファレンスは、互換性テストではなくセットアップドキュメントです。上記の10月1日の実行では、Kunavoではなくローカルテストサーバーを使用しました。エラーリファレンスから始めて、エンドポイントが返した内容を読み解き、キーに資金を追加する準備ができたら Kunavoアカウントを作成してください。上記の単一候補対複数候補の判断に最も近い比較は、OpenRouterとLiteLLMの比較です。

よくある質問

2026年10月1日に実行：ストリームを切断したローカルテストサーバーに対して、対話型ターミナルモードでv0.8.5のリリースバイナリを実行しました。結果表の4行がその内容であり、それ以外は何も実行せず、Kunavoへリクエストは送信していません。Issueの状態は同日に再確認しました（#10787はその後クローズされ、#10634はまだオープンしています）。リポジトリのソースはリリースタグv0.8.5で読み、ドキュメントはバージョン固定された /v0.8.5/ パスで読み、issueとプルリクエストの状態は2026年9月21日に確認しました。これらのissueのいくつかは進行中とマークされており、変化する可能性があります。Kunavoのトークン料金は最新カタログに基づき、ここに示すすべてのドル金額は、測定されたタスクコストではなく、例示的なトークン算術です。