ZeroClaw 絕不會恢復中斷的串流。它是否會再次傳送回合，取決於你的設定檔有多少個候選項目；而在目前唯一的發布版本中，實際行為並不完全如文件所承諾。ZeroClaw v0.8.5 的文件（發布於 2026 年 9 月 5 日）表示，在任何輸出前失敗的串流會以非串流方式重試，而在輸出後失敗的串流永遠不會重播。2026 年 10 月 1 日，針對一個在回覆中途切斷串流的端點執行時，v0.8.5 的終端機用戶端採取了更簡單的行為：只有一個候選項目時，無論文字是否已出現都完全不重試；有第二個候選項目時，則以非串流方式將回合重新傳送至第二個模型——即使部分答案已顯示在畫面上。部分輸出後的引導式復原仍是開放功能請求，尚未取得設計核准。因此，真正有用的問題不是如何讓 ZeroClaw 重試，而是你的回合是否適合重新傳送，以及那次失敗的嘗試已經造成什麼成本。
在將這些資訊付諸行動前，先說明兩點範圍限制。本次實際測試的範圍很窄：以互動式終端機模式執行的 v0.8.5 發布二進位檔、一個與 OpenAI 相容的端點，以及一個刻意中斷串流的本機測試伺服器——結果如下。未測試頻道、閘道 WebSocket、RPC、ACP、Anthropic 插槽及真實供應商服務中斷。其他所有說法均於 2026 年 9 月 21 日查閱，來源為發布標籤 v0.8.5 的儲存庫、固定版本的文件 docs.zeroclaw.com/v0.8.5/，或註明日期的上游問題報告。另請自行將該 URL 固定至指定版本：README 將讀者導向 /master/ 路徑，其 HEAD 比發布版本新十六天，且恰好在這個主題上與發布版本的說法矛盾；而 /latest/ 回傳 404。本文的 ZeroClaw 指的是 zeroclaw-labs/zeroclaw 執行環境；若你不確定自己執行的是不是這個，ZeroClaw 與 OpenClaw 可協助你將它與共用此名稱的專案及分支區分開來。
v0.8.5 的四個標記，其中只有一個代表網路
在做任何判斷前，先確認你實際取得的是哪個標記。ZeroClaw 在 v0.8.5 的英文語系檔，將這些標記定義為不同的 Fluent 金鑰；標頭註解說明，當回合提前中斷時，這些標記會附加到或持續保留在助理輸出中，並在所有傳輸方式——頻道、WS、RPC、ACP 及 CLI——中顯示給終端使用者。
| 標記 | Fluent 金鑰 | 它告訴你的資訊 |
|---|---|---|
[stream interrupted] | turn-stream-interrupted | 傳輸串流在回合中途中斷。沒有人按下停止。 |
[interrupted by user] | turn-interrupted-by-user | 人為中斷。 |
[turn cancelled via client] | turn-cancelled-client-rpc | 是頻道，而不是執行者。其程式碼註解明確指出，人為中斷與程式化用戶端取消都會經由這條路徑傳入，因此文字描述的是頻道。 |
[interrupted by user before this tool produced a result] | turn-tool-interrupted-before-result | 工具在回傳前被中斷。 |
同一檔案的 master 上還有第五個金鑰，turn-failed = [turn failed]，但 v0.8.5 的語系檔中沒有，因此已發布的建置版本不會產生它。有一項值得了解的行為，因為它會改變你之後能讀取的內容：回合引擎只有在部分文字<strong>不為空</strong>時，才會將附加標記的部分文字持續保存 。 如果某個回合產生了推理或供應商端預先執行的工具事件，卻沒有可見文字，則完全不會保存任何內容——程式碼註解將持續保存描述為提交消費者已經看見的內容。其他語系也帶有相同金鑰及翻譯後的值，因此非英文安裝顯示的不是字面上的英文方括號字串。
重試邊界實際位於何處
整個判斷歸結為一個問題：是否已有任何內容抵達不可變更的事件接收槽？
| 發生了什麼 | v0.8.5 的文件化行為 | 注意事項 |
|---|---|---|
| 串流在任何可見輸出前失敗 | 執行環境會經由非串流路徑重試整個呼叫，重新進入完整的可靠性流程 | 文件有記載，但已發布建置版本中單一候選設定的觀察結果並非如此——如下所述 |
| 串流完成，但沒有最終文字，也沒有工具呼叫 | 這是語義上為空的回應，而不是答案。當結果標記為可安全重播，且 provider_retries 非零時，會對完全相同的供應商與模型發出一次非串流復原呼叫，並僅消費一次 | 透過拉取要求 #10602 於 v0.8.5 中發布，並於 2026 年 9 月 4 日合併。適用於空串流，不適用於輸出中途中斷的串流 |
| 文字、推理或預先執行的工具事件已抵達不可變更的事件接收槽 | StreamInterruptedAfterOutput。執行環境不會重播請求，已轉送給消費者的文字就是會被保存的部分助理文字 | master 上的行為刻意如此，且完全一致。回歸測試已鎖定此行為：可見輸出後發生串流錯誤時，回合必須失敗，不得進行備援重試 |
| 上述任一情況 | 串流只會開啟一次，開始後不會切換項目 | 復原一律是新的請求。包括自訂插槽在內，沒有任何供應商家族具備續接路徑 |
確實存在的設定旋鈕是全域性的，而非每個端點各自設定。[reliability] 包含 provider_retries（文件化預設值為 2）及 provider_backoff_ms（預設值為 500），生命週期文件指出，每個實際建立的項目最多會嘗試 provider_retries + 1 次。v0.8.5 設定參考文件並未在這些設定旁記載每個供應商或別名的重試覆寫。也不要依賴金鑰池：v0.8.5 文件指出，reliability.api_keys 目前不是可運作的故障轉移，因為包裝器會在可重試的速率限制後選取並記錄替代金鑰，卻無法將其套用至已建立的供應商，因此重試仍使用原始憑證。你為了期待救援而新增的第二把金鑰，並不能提供救援。
指向單一端點的設定最容易受到影響
對於讓 ZeroClaw 連接單一閘道或單一供應商端點的人而言，這是最關鍵的邊界，因為單一端點按定義就是單一候選的可靠性設定。問題 #10736 報告指出，在已發布建置版本的這種設定中，輸出前串流失敗會記錄切換至非串流聊天，接著卻永遠不會送出該請求，並以 All model providers/models failed after 0 failure event(s) 終止回合。該問題於 2026 年 9 月 18 日關閉——時間晚於 v0.8.5 發布——因此修正只存在於 master。2026 年 10 月 1 日執行時，已發布的 v0.8.5 表現完全如該問題所述：先發出一個請求，接著出現該錯誤；無論串流是在文字出現前或出現後中斷，結果都相同。
這裡有兩個互相矛盾但都值得保留的官方立場。v0.8.5 架構文件承諾非串流重試；問題報告則證明已發布建置版本未執行該重試，其預期行為段落並要求只有在確實會嘗試備援時，日誌才宣稱會進行備援。之後 master 新增了發布版本沒有的單一候選復原許可——而 問題 #10787 指出，無論 provider_retries 為何，該許可都以 RetryDecision::Admit(0) 授予，且沒有退避，因此請求會立即重新送往過載的上游，仍落在同一個負載卸除時段內。該問題於 2026 年 9 月 26 日以已完成狀態關閉——修正位於 master 上，時間晚於 v0.8.5 發布，因此也不在任何已發布版本中。master 的行為仍在變動；不要以它為依據規劃。
文件所述的緩解方式是設定，而不是某個選項：為設定檔提供第二個候選項目，讓可靠性流程有地方可轉移。2026 年 10 月 1 日，這在終端中的 v0.8.5 上有效——但在依賴前有一項值得知道的限制：復原請求送往第二個模型，而不是第一個，因此中斷後取得的答案來自你的備援模型。ZeroClaw API 成本與設定指南說明這些項目的設定格式。
串流中斷時 v0.8.5 的處理方式
2026 年 10 月 1 日，通過發布版本 SHA256SUMS 校驗的 v0.8.5 發布二進位檔，在一次性容器中以互動式終端模式執行——這是會進行串流的模式；單訊息 -m 模式會送出一個非串流請求，永遠不會進入此路徑。一個與 OpenAI 相容的自訂插槽設定檔 provider_retries = 2 指向本機測試伺服器；該伺服器先以正常串流回應，然後在第一個事件前或一個文字區塊後關閉連線，且未傳送 [DONE]。
| 設定檔 | 串流中斷位置 | 送出的請求 | 終端顯示內容 |
|---|---|---|---|
| 單一候選 | 任何文字之前 | 一個串流請求，沒有重試 | 錯誤：選取的模型供應商失敗。請檢查供應商設定，或選擇其他供應商。 記錄：所有模型供應商／模型均失敗，失敗事件數為 0 |
| 單一候選 | 文字輸出後 | 一個串流請求，沒有重試 | 部分文字，接著是相同錯誤。未輸出 [stream interrupted] 標記 |
加上第二個模型的 fallback_models | 任何文字之前 | 先發出串流請求，接著對第二個模型發出一個非串流請求 | 第二個模型的回覆 |
加上第二個模型的 fallback_models | 文字輸出後 | 相同的兩個請求 | 部分文字，接著是第二個模型的完整回覆——因此答案會出現兩次 |
對於在 v0.8.5 上從終端執行 ZeroClaw 的人，這會帶來三項結果。單一候選失敗就是已重現的 #10736；provider_retries 並未改變它。文件所述的「可見輸出後不重播」邊界在此並未適用：終端中已輸出的文字沒有阻止重新送出，因此你看著只完成一半的回合仍可能再次送出，而且會送往不同模型。此外，回合記錄將第一個模型記為該回合的模型，但文字來自第二個模型，這正是 v0.8.5 自身文件警告的歸屬落差。本次執行未涵蓋：Telegram 或 Slack 等頻道、閘道 WebSocket、RPC 及 ACP 用戶端——不重播規則所針對其事件接收槽的傳輸方式——Anthropic 插槽、真實供應商中斷，以及任何經由 Kunavo 發出的請求。
重新送出前：哪些內容已執行，哪些內容已計費
ZeroClaw 本身的工具迴圈會讀取串流直到結束，在串流結束後還原工具呼叫並執行，接著為下一個助理回合開啟新的串流呼叫。因此，發生中斷的那次迭代所要求的工具尚未執行——但這所能提供的保障，比聽起來更有限。供應商端預先執行的工具呼叫屬於另一類事件，早已在上游產生影響，而這正是它們會阻止重播的原因。此外，長回合往往到後段才中斷：#10736 指出，失敗前的上一個工具呼叫已成功完成；#10787 的日誌則顯示，中斷發生在第 2 次迭代，當時請求中包含 126 則訊息。重新傳送原始提示詞，會重播模型可能重複執行的所有先前副作用。
看似乾淨的文字記錄也不是證明。問題 #9421 目前以 p1 優先級開放，涵蓋 Anthropic 與 OpenAI 相容供應商家族；標題指出，不完整的終端回應可能被回報為成功。在 Code／ACP 介面上，另外兩個開放的 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 缺陷。文件記載有一項例外：Anthropic 剖析器目前也會將非空 message_delta.stop_reason 後的 EOF 視為完成，即使沒有 message_stop；要求必須具備該訊號的拉取要求在兩個參照版本上都尚未合併。
第二個原因是開啟的 socket 上沒有資料。ZeroClaw 使用位元組閒置逾時，而不是整個請求的期限；文件記載 OpenAI Responses 與 OpenAI 相容供應商為 300 秒、Anthropic 為 90 秒，且每次讀取本文都會重設計時器。若端點緩衝上游回應，並在一分半鐘內沒有轉送任何內容，就會觸發 Anthropic 家族插槽的逾時，但 OpenAI 相容插槽仍可存活——這點值得知道，因為 Anthropic Messages 端點會使用帶有 uri 覆寫的 anthropic 插槽，而不是 custom。請參閱Messages 基底 URL 文件與OpenAI 相容 API，了解兩種線路協定。
一次死亡回合的成本：範例計算
將兩筆帳分開。ZeroClaw 執行環境的費用是 $0——zeroclaw.com表示它是開放原始碼，採 MIT 或 Apache-2.0 雙重授權，沒有訂閱費，也沒有託管席位；你只需支付自己的 LLM 供應商成本，若使用 Ollama 執行本機模型，則完全不需支付任何費用。因為根本沒有方案層級，所以沒有任何方案會解鎖續接、更大的重試額度或引導式復原。
中斷會影響的是模型費用。這些數字是根據假設進行的 token 費用計算，並非實測的任務成本，也不是帳單上限。假設一個回合傳送了 110,000 個未快取的輸入 token——這是 #10787 記錄的單一、附有日期的過載事件中的提示詞大小；在該事件中，上游接受了請求並執行預填充，之後才卸載該請求——並在串流中斷前接收了 2,000 個輸出 token。三次嘗試欄的計算方式為 provider_retries + 1，採用文件記載的預設值 2。費率採用 Kunavo 目錄中每百萬 token 的即時價格。
| 模型 | 每 1M 的輸入／輸出 | 一次失敗的嘗試 | 三次嘗試 |
|---|---|---|---|
| Claude Haiku 4.5 | $0.70 / $3.50 | $0.084 | $0.252 |
| GPT-5.6 Terra | $0.70 / $4.20 | $0.085 | $0.256 |
| Claude Sonnet 4.6 | $2.10 / $10.50 | $0.252 | $0.756 |
| Claude Opus 5 | $3.50 / $17.50 | $0.420 | $1.260 |
任何特定端點是否會對其卸載的請求收費，取決於該端點自身的計費政策；ZeroClaw 的原始碼或文件都沒有說明這點——本頁未替任何供應商測量。這些算術是用來估算問題規模，而不是回答問題。Kunavo 的目錄金額是計費下限，而非上限：當上游回報其費用時，帳單金額取目錄成本與上游成本乘以適用加成兩者中較高者。最低加值為預付額度 $10，這是資金最低要求，而非任務費或訂閱費——請參閱計費詳細資訊。
哪種路徑最能承受此故障
| 方式 | 串流中途中斷時的行為 | 你放棄的功能 |
|---|---|---|
| 單一端點，直接供應商 | 單一候選的可靠性設定，因此在 v0.8.5 上屬於 #10736 所報告的範圍 | 是否為第一方供應商不會改變流程；一個候選就是一個候選 |
| 單一端點，閘道 | 完全相同的單一候選結構。閘道在此能提供的是在一把金鑰與一個餘額下切換模型，而不是串流韌性 | 額外的一跳本身可能在沒有完成訊號的情況下關閉，而 ZeroClaw 只有在你自行撰寫其 [cost.rates] 項目時才會替它計價 |
| 設定檔中有兩個或更多候選項目 | 可靠性流程有地方可轉移。在 2026 年 10 月 1 日的終端執行中，它在早期中斷和回覆中途中斷後都成功復原——透過第二個模型 | 需要維護第二個模型或別名，而且復原後的答案來自你的備援，而不是你的第一選擇 |
| 透過 Ollama 使用本機模型 | 重新送出消耗的是時間與硬體，而不是金錢，因此保守重試的成本低 | 相對於託管前沿模型的能力差距，以及執行其中一個模型的機器 |
| 固定費率的訂閱代理程式 | 完全不是 ZeroClaw 路徑——該專案沒有訂閱費，也沒有託管席位 | 你改變的是用戶端，而不是 ZeroClaw 的復原行為 |
無論選擇哪一種，操作原則都是 ZeroClaw 已經編碼的原則：在 [stream interrupted] 之後，讀取已保存的部分內容，確認哪些內容已經生效，然後重新送出比原始請求更窄的內容。Kunavo 對 OpenAI 相容端點及 Messages 風格端點的設定參考是設定文件，而非相容性測試——上方 10 月 1 日的執行使用的是本機測試伺服器，而不是 Kunavo。請從錯誤參考開始，解讀端點回傳的內容；準備為金鑰提供資金時，請建立 Kunavo 帳戶。OpenRouter 與 LiteLLM是上述單一候選與多候選決策最接近的比較。
常見問題
ZeroClaw 會重試遭中斷的串流嗎？
這完全取決於你是否已經看到了輸出。ZeroClaw 已發布的 v0.8.5 供應商路由文件表示，串流只會開啟一次，開始後不會切換項目，因此永遠不會恢復原串流——若存在復原，會是全新的要求。如果串流在任何不可變事件輸出可見之前失敗，文件記載的行為是執行階段會透過非串流路徑重試整個呼叫。一旦文字、推理或預先執行的工具事件抵達不可變事件接收器，中斷就會變成 StreamInterruptedAfterOutput，而執行階段不會重播要求。第二項規則在 master 上也相同。但在 2026 年 10 月 1 日於 v0.8.5 的互動式終端機用戶端中執行時，兩項規則都未如文字所述出現：使用一個候選項目時，無論文字出現前後都沒有重試；使用 fallback_models 中的第二個候選項目時，兩種情況下該回合都會以非串流方式重新傳送至第二個模型，包括部分答案已列印之後。未執行通道與閘道 WebSocket 的測試。文件檢查日期為 2026 年 9 月 21 日。
ZeroClaw 中的 [串流已中斷] 是什麼意思？
這是傳輸串流在一輪回合中途中止時，對使用者顯示的標記；ZeroClaw 的英文語系檔將它定義為 Fluent 金鑰 turn-stream-interrupted，並在所有傳輸方式——channels、WS、RPC、ACP 與 CLI——中顯示。它刻意與 [interrupted by user] 和 [turn cancelled via client] 使用不同標記，因此看到這個標記表示沒有人按下停止。當串流在已有可見輸出後中止時，部分文字會以附加該標記的 assistant 訊息形式保存，但僅限部分文字非空：只產生推理或只產生預先執行工具事件的回合不會保存任何內容。非英文安裝會使用相同金鑰及翻譯後的文字，因此不要在非英文環境中搜尋英文方括號字串。已於 2026 年 9 月 21 日在發布標籤 v0.8.5 檢查。在 2026 年 10 月 1 日的 v0.8.5 互動式終端機用戶端中，回覆中途切斷的串流沒有列印此標記；終端機反而顯示供應商失敗錯誤。
ZeroClaw 串流中斷後，可以直接重新傳送提示嗎？
不能自動這樣做，ZeroClaw 自己的維護者也如此處理。執行階段會將串流讀取至完成，結束後復原工具呼叫，再執行這些工具——因此發生故障的那次迭代中的工具尚未執行。但長回合也可能在後續迭代中斷裂：一份上游報告指出，前一個工具呼叫已成功完成後才發生故障，另一份日誌則顯示故障發生在第 2 次迭代，且要求中有 126 則訊息。較早迭代已完成的任何動作——寫入檔案、執行指令、傳送訊息——若你盲目重新傳送相同提示，都會再次發生。針對引導式復原的開放功能請求，將盲目重播包含工具或核准的回合，以及將每個供應商錯誤視為暫時性錯誤，列為自身不在目標範圍內。先讀取已保存的部分文字，確認哪些動作已經生效，再傳送範圍更窄的提示，而不是原始提示。
可以設定 ZeroClaw 來恢復中斷的串流嗎？
不可以。任何已發布版本都沒有相關設定，也沒有能解鎖該功能的付費方案——ZeroClaw 是免費且開放原始碼的軟體，採 MIT OR Apache-2.0 雙重授權，沒有訂閱，也沒有託管席位，因此這項限制是工程邊界，而非方案邊界。串流在已有可見輸出後不重播的規則存在於原始碼中，並由回歸測試鎖定；該測試自身的失敗訊息表示，已有可見輸出後發生串流錯誤時，回合必須失敗且不得進行備援重試——但在 2026 年 10 月 1 日的 v0.8.5 互動式終端機用戶端中，具有第二個候選項目的設定檔確實在文字列印後重新傳送，因此該規則並非所有傳輸方式上的保證。中斷回合後的引導式復原是問題 #10634——截至 2026 年 9 月 21 日仍為開放狀態、標記為 status:accepted 和 priority:p2，且首先被安排進行設計或 RFC 討論。已接受表示分流流程接受了問題陳述，不表示程式碼已撰寫或合併。
我的日誌顯示它正在退回非串流聊天，然後回合就中止了。為什麼？
在已發布的 v0.8.5 中，該日誌行可能不實。上游 issue #10736 的標題指出，輸出前的串流失敗會跳過所宣稱的非串流備援；該 issue 回報執行階段記錄自己正在退回非串流聊天，但並未傳送非串流要求，回合隨即以 All model providers/models failed after 0 failure event(s) 終止。其影響說明將受影響族群列為只有單一供應商候選項目的使用者，尤其是重試次數為零的設定。零次重試並非唯一情況：其重現案例將 provider_retries 設為 0，但後續 issue #10787 在 provider_retries 保持文件所述預設值 2 時，也重現相同的立即失敗。該 issue 於 2026 年 9 月 18 日關閉，當時 v0.8.5 已於 9 月 5 日發布，因此沒有任何已發布版本包含修正。它於 2026 年 10 月 1 日在 v0.8.5 上重現：一次串流要求、沒有非串流後續要求，以及該錯誤——provider_retries = 2，且無論串流在文字出現前或後中斷都相同。加入 fallback_models 中的第二個模型便足以讓回合復原。在 v0.8.5 上根據日誌進行除錯，代表你讀到的是一個並未發生的備援。
中斷的回合有被計費嗎？要如何確認？
請檢查端點自身的用量紀錄，而不是 ZeroClaw 的紀錄，因為 v0.8.5 的文件告訴你不要信任其每次嘗試的數字：文件將最終備援通知描述為成功通知，而不是記錄每次嘗試的權威帳本，並表示不要據此推論每次嘗試的成本準確性。能解決此問題的每次嘗試 usage_by_provider 帳本，是透過提取要求 #8966 於 2026 年 9 月 18 日合併至 master，時間晚於 v0.8.5 發布，因此不在任何已發布版本中——而 master 將它限定於設有事件記錄機制的回合路徑。ZeroClaw 確實會在中斷的串流上擷取用量快照，但該欄位是選用的，可能不存在；它也會向 OpenAI 相容端點要求在最後一個 SSE 區塊中提供用量，而截斷的串流可能永遠不會傳送該區塊。最後一點是根據原始碼解讀，而非執行時觀察所得。另外，ZeroClaw 自身的成本數字來自你設定檔中由操作者撰寫的 [cost.rates] 費率表，因此你未在其中定價的端點，ZeroClaw 也不會為其定價。
2026 年 10 月 1 日執行：v0.8.5 發布二進位檔以互動式終端模式連接本機測試伺服器，該伺服器中斷了串流——結果表的四列；沒有執行其他內容，也沒有請求送往 Kunavo。問題狀態於同日重新確認（#10787 此後已關閉；#10634 仍開放）。儲存庫原始碼讀取自 v0.8.5 發布標籤，文件讀取自版本固定的 /v0.8.5/ 路徑；問題及拉取要求狀態於 2026 年 9 月 21 日讀取，其中數個問題當時標記為進行中，狀態可能變動。Kunavo 權杖費率來自即時目錄，此處所有美元數字都是示意性的權杖算術，而非測量得到的任務成本。