ZeroClaw không bao giờ tiếp tục một luồng bị gián đoạn. Việc nó có gửi lại lượt chạy hay không phụ thuộc vào số lượng ứng viên trong cấu hình của bạn, và trên bản phát hành hiện tại duy nhất thì hành vi này không hoàn toàn giống tài liệu. Tài liệu ZeroClaw cho v0.8.5 (phát hành ngày 5 tháng 9 năm 2026) nói rằng luồng lỗi trước mọi đầu ra sẽ được thử lại mà không truyền luồng, còn luồng lỗi sau đầu ra thì không bao giờ được phát lại. Khi chạy ngày 1 tháng 10 năm 2026 với một endpoint cắt luồng giữa lúc trả lời, ứng dụng terminal của v0.8.5 làm điều đơn giản hơn: với một ứng viên, nó hoàn toàn không thử lại, dù văn bản đã xuất hiện hay chưa; với ứng viên thứ hai, nó gửi lại lượt chạy, không truyền luồng, đến mô hình thứ hai — ngay cả sau khi một phần câu trả lời đã hiển thị trên màn hình. Khôi phục có hướng dẫn sau đầu ra một phần vẫn là yêu cầu tính năng đang mở và chưa được phê duyệt thiết kế. Vì vậy, câu hỏi hữu ích không phải là làm thế nào để ZeroClaw thử lại. Đó là liệu lượt chạy của bạn có an toàn để gửi lại hay không, và lần thử đã chết đó đã tốn những gì.
Hai lưu ý về phạm vi trước khi bất kỳ điều gì trong số này có thể áp dụng. Những gì đã chạy có phạm vi hẹp: binary phát hành v0.8.5 ở chế độ terminal tương tác, một endpoint tương thích OpenAI và một máy chủ kiểm thử cục bộ cố ý đóng luồng — kết quả ở bên dưới. Channels, gateway WebSocket, RPC, ACP, slot Anthropic và các sự cố nhà cung cấp thực tế chưa được chạy. Mọi nhận định khác được đọc từ kho mã tại thẻ phát hành v0.8.5, từ tài liệu cố định phiên bản tại docs.zeroclaw.com/v0.8.5/, hoặc từ các báo cáo issue upstream có ngày tháng, tất cả vào ngày 21 tháng 9 năm 2026. Và hãy tự ghim URL đó: README dẫn người đọc đến đường dẫn /master/, có HEAD đi trước bản phát hành mười sáu ngày và mâu thuẫn với bản phát hành đúng về chủ đề này, trong khi /latest/ trả về 404. ZeroClaw ở đây nghĩa là runtime zeroclaw-labs/zeroclaw; nếu bạn không chắc đó là runtime mình đang chạy, So sánh ZeroClaw và OpenClaw phân biệt nó với các dự án và fork dùng chung tên.
Bốn dấu hiệu ở v0.8.5, và chỉ một trong số đó là mạng
Trước khi quyết định bất cứ điều gì, hãy đọc xem bạn thực sự nhận được dấu hiệu nào. Tệp locale tiếng Anh của ZeroClaw ở v0.8.5 định nghĩa chúng là các khóa Fluent riêng biệt dưới một chú thích tiêu đề nói rằng chúng được nối vào hoặc lưu lại như đầu ra của trợ lý khi một lượt chạy bị cắt ngắn, và được hiển thị cho người dùng cuối trên mọi phương thức truyền tải — channels, WS, RPC, ACP và CLI.
| Dấu hiệu | Khóa Fluent | Điều dấu hiệu cho bạn biết |
|---|---|---|
[stream interrupted] | turn-stream-interrupted | Luồng truyền tải đã chết giữa lượt chạy. Không ai nhấn dừng. |
[interrupted by user] | turn-interrupted-by-user | Một lần ngắt do con người. |
[turn cancelled via client] | turn-cancelled-client-rpc | Kênh, không phải tác nhân. Chú thích mã riêng của nó nói rằng cả lần ngắt do con người lẫn thao tác hủy của client theo chương trình đều đi qua đường dẫn này, nên cách diễn đạt gọi tên kênh. |
[interrupted by user before this tool produced a result] | turn-tool-interrupted-before-result | Một công cụ đã bị cắt trước khi trả về. |
Một khóa thứ năm, turn-failed = [turn failed], tồn tại trong cùng tệp trên master nhưng không có trong tệp locale của v0.8.5, nên bản dựng phát hành không phát ra khóa này. Một hành vi đáng biết vì nó thay đổi những gì bạn có thể đọc sau đó: engine lượt chạy lưu văn bản một phần với dấu hiệu được nối thêm chỉ khi văn bản một phần đó không rỗng. Một lượt chạy tạo ra suy luận hoặc các sự kiện công cụ được thực thi trước ở phía nhà cung cấp nhưng không có văn bản hiển thị thì hoàn toàn không lưu gì — chú thích mã mô tả việc lưu là commit những gì consumer đã thấy. Các locale khác mang cùng những khóa đó với giá trị đã dịch, nên chuỗi ngoặc tiếng Anh nguyên văn không phải thứ bản cài đặt không phải tiếng Anh hiển thị.
Ranh giới thử lại thực sự nằm ở đâu
Toàn bộ quyết định quy về một câu hỏi: đã có thứ gì đi vào một event sink bất biến chưa?
| Điều đã xảy ra | Hành vi được tài liệu hóa ở v0.8.5 | Lưu ý |
|---|---|---|
| Luồng lỗi trước mọi đầu ra hiển thị | Runtime thử lại toàn bộ lệnh gọi qua đường dẫn không truyền luồng, đi lại qua toàn bộ quy trình reliability | Được tài liệu hóa, nhưng không phải điều được quan sát trên bản dựng phát hành với cấu hình một ứng viên — xem bên dưới |
| Luồng hoàn tất nhưng không có văn bản cuối cùng và không có lần gọi công cụ | Một phản hồi rỗng về ngữ nghĩa, không phải câu trả lời. Khi kết quả được đánh dấu là an toàn để phát lại và provider_retries khác không, một lệnh gọi khôi phục không truyền luồng đến đúng nhà cung cấp và mô hình đó, được tiêu thụ một lần | Được phát hành trong v0.8.5 qua pull request #10602, hợp nhất ngày 4 tháng 9 năm 2026. Áp dụng cho luồng rỗng, không áp dụng cho luồng bị ngắt giữa đầu ra |
| Văn bản, suy luận hoặc các sự kiện công cụ được thực thi trước đã đi vào một event sink bất biến | StreamInterruptedAfterOutput. Runtime không phát lại yêu cầu, và văn bản đã chuyển tiếp đến consumer là toàn bộ phần trở thành văn bản trợ lý một phần được lưu | Cố ý và giống hệt trên master. Được khóa bằng bài kiểm thử hồi quy khẳng định rằng lỗi luồng sau đầu ra hiển thị phải làm lượt chạy thất bại mà không thử lại dự phòng |
| Bất kỳ trường hợp nào ở trên | Luồng được mở một lần và các mục không được chuyển đổi sau khi đã bắt đầu | Khôi phục luôn là một yêu cầu mới. Không họ nhà cung cấp nào, kể cả slot tùy chỉnh, có đường dẫn tiếp tục |
Các nút điều khiển tồn tại là toàn cục, không phải theo từng endpoint. [reliability] mang theo provider_retries, mặc định được tài liệu hóa là 2, và provider_backoff_ms, mặc định là 500; tài liệu vòng đời nêu rằng mỗi mục được hiện thực hóa được thử tối đa provider_retries + 1 lần. Tài liệu tham chiếu cấu hình v0.8.5 không ghi nhận tùy chọn ghi đè số lần thử lại theo từng nhà cung cấp hoặc alias bên cạnh chúng. Cũng đừng trông chờ vào nhóm khóa: tài liệu v0.8.5 nói rằng reliability.api_keys hiện chưa phải failover hoạt động, vì wrapper chọn và ghi nhật ký một khóa thay thế sau giới hạn tốc độ có thể thử lại nhưng không thể áp dụng nó vào nhà cung cấp đã tạo, nên lần thử lại vẫn dùng thông tin xác thực ban đầu. Khóa thứ hai bạn thêm với kỳ vọng được giải cứu không cung cấp điều đó.
Trỏ vào một endpoint là cấu hình chịu ảnh hưởng nặng nhất
Đây là giới hạn rõ rệt nhất đối với bất kỳ ai chạy ZeroClaw qua một cổng kết nối duy nhất hoặc một điểm cuối duy nhất của nhà cung cấp, vì theo định nghĩa, một điểm cuối là cấu hình đảm bảo độ tin cậy chỉ có một ứng viên. Báo cáo lỗi #10736 cho biết rằng trên bản dựng đã phát hành, lỗi luồng trước khi có đầu ra trong cấu hình đó khiến hệ thống ghi nhật ký rằng sẽ chuyển sang trò chuyện không truyền luồng, nhưng sau đó không bao giờ gửi yêu cầu đó, khiến lượt chạy kết thúc với All model providers/models failed after 0 failure event(s). Báo cáo được đóng ngày 18 tháng 9 năm 2026 — sau khi v0.8.5 được phát hành — nên bản sửa chỉ có trên master. Trong lần chạy ngày 1 tháng 10 năm 2026, bản phát hành v0.8.5 hoạt động đúng như báo cáo mô tả: một yêu cầu, rồi lỗi đó, bất kể luồng bị ngắt trước hay sau khi văn bản xuất hiện.
Hai lập trường chính thức không đồng nhất ở đây và cả hai đều đáng được giữ lại. Tài liệu kiến trúc v0.8.5 hứa hẹn lần thử lại không truyền luồng; issue cho thấy bản dựng phát hành không thực hiện điều đó, và phần hành vi kỳ vọng yêu cầu nhật ký chỉ tuyên bố có dự phòng khi thực sự sẽ thử. Sau đó master thêm một khoản cho phép khôi phục đối với cấu hình một ứng viên mà bản phát hành không có — và issue #10787 nói rằng khoản cho phép đó được cấp bằng RetryDecision::Admit(0) bất kể provider_retries và không có backoff, nên upstream quá tải bị gửi lại ngay vào cùng khoảng thời gian quá tải. Issue này được đóng với trạng thái hoàn tất ngày 26 tháng 9 năm 2026 — trên master, sau v0.8.5, nên cũng chưa có trong bản phát hành nào. Hành vi của master vẫn đang thay đổi; đừng lập kế hoạch dựa vào nó.
Biện pháp giảm thiểu được tài liệu mô tả là thay đổi cấu hình thay vì một tùy chọn: thêm ứng viên thứ hai vào hồ sơ cấu hình để quy trình đảm bảo độ tin cậy có nơi chuyển đến. Ngày 1 tháng 10 năm 2026, cách này hoạt động trên v0.8.5 trong terminal — với một lưu ý cần biết trước khi dựa vào nó: yêu cầu khôi phục được gửi đến mô hình thứ hai, không phải mô hình thứ nhất, nên câu trả lời bạn nhận được sau khi bị gián đoạn đến từ mô hình dự phòng. Hướng dẫn chi phí và thiết lập ZeroClaw API trình bày cấu trúc cấu hình chứa các mục đó.
v0.8.5 đã làm gì khi luồng bị cắt
Ngày 1 tháng 10 năm 2026, binary phát hành v0.8.5, được xác minh checksum đối chiếu với SHA256SUMS của bản phát hành, chạy trong một container dùng tạm ở chế độ terminal tương tác — chế độ có truyền luồng; chế độ -m một tin nhắn gửi một yêu cầu không truyền luồng và không bao giờ đi vào đường dẫn này. Một profile slot tùy chỉnh tương thích OpenAI, provider_retries = 2, trỏ đến máy chủ kiểm thử cục bộ trả về một luồng bình thường rồi đóng kết nối mà không có [DONE], trước sự kiện đầu tiên hoặc sau một đoạn văn bản.
| Hồ sơ cấu hình | Luồng bị ngắt ở đâu | Các yêu cầu đã gửi | Terminal hiển thị gì |
|---|---|---|---|
| Một ứng viên | Trước mọi văn bản | Một yêu cầu truyền luồng, không thử lại | Lỗi: Nhà cung cấp mô hình đã chọn không thành công. Hãy xem lại cấu hình nhà cung cấp hoặc chọn một nhà cung cấp khác. Nhật ký: All model providers/models failed after 0 failure event(s) |
| Một ứng viên | Sau khi văn bản được in | Một yêu cầu truyền luồng, không thử lại | Văn bản một phần, rồi cùng lỗi đó. Không in dấu hiệu [stream interrupted] |
Cộng thêm fallback_models với mô hình thứ hai | Trước mọi văn bản | Yêu cầu truyền luồng, rồi một yêu cầu không truyền luồng đến mô hình thứ hai | Phản hồi của mô hình thứ hai |
Cộng thêm fallback_models với mô hình thứ hai | Sau khi văn bản được in | Cùng hai yêu cầu đó | Văn bản một phần, rồi toàn bộ phản hồi của mô hình thứ hai — nên câu trả lời xuất hiện hai lần |
Có ba điều cần rút ra đối với bất kỳ ai chạy ZeroClaw từ terminal trên v0.8.5. Lỗi một ứng viên là #10736, đã được tái hiện; provider_retries không thay đổi điều đó. Ranh giới được tài liệu hóa “không phát lại sau đầu ra hiển thị” không áp dụng ở đây: văn bản đã in trong terminal không ngăn việc gửi lại, nên một lượt chạy bạn đã chứng kiến đến nửa chừng vẫn có thể được gửi lại đến một mô hình khác. Nhật ký của lượt chạy ghi mô hình thứ nhất là mô hình của lượt chạy, trong khi văn bản đến từ mô hình thứ hai, chính là khoảng trống quy kết mà tài liệu v0.8.5 cảnh báo. Những gì lần chạy này không bao phủ: các channel như Telegram hoặc Slack, gateway WebSocket, client RPC và ACP — các phương thức truyền tải mà event sink của chúng là đối tượng của quy tắc không phát lại — slot Anthropic, sự cố nhà cung cấp thực tế và bất kỳ yêu cầu nào qua Kunavo.
Trước khi gửi lại: điều gì đã chạy và điều gì đã bị tính phí
Vòng lặp công cụ của ZeroClaw đọc luồng đến khi hoàn tất, khôi phục các lần gọi công cụ sau khi luồng kết thúc, chạy chúng, rồi mở một lệnh gọi truyền luồng mới cho lượt trợ lý tiếp theo. Vì vậy, các công cụ được yêu cầu bởi lần lặp bị lỗi chưa chạy — nhưng đó là sự an tâm hẹp hơn vẻ ngoài. Các lần gọi công cụ được thực thi trước ở phía nhà cung cấp là một lớp sự kiện riêng đã tạo tác động ở upstream, chính xác là lý do chúng chặn việc phát lại. Các lượt chạy dài bị lỗi muộn: #10736 ghi nhận lần gọi công cụ trước đó đã hoàn tất thành công trước khi lỗi xảy ra, còn nhật ký của #10787 cho thấy lỗi rơi vào lần lặp 2 với 126 tin nhắn trong yêu cầu. Gửi lại prompt ban đầu sẽ phát lại mọi tác động phụ trước đó mà mô hình sẽ lặp lại.
Một bản ghi hội thoại trông có vẻ đầy đủ cũng không phải bằng chứng. Báo cáo lỗi #9421, đang mở với mức ưu tiên p1 đối với cả nhóm nhà cung cấp Anthropic và nhóm tương thích OpenAI, có tiêu đề cho biết rằng các phản hồi chưa hoàn tất trong terminal có thể được báo cáo là thành công. Trên giao diện Code/ACP, hai báo cáo p1 đang mở khác mô tả việc một lượt chạy thất bại loại bỏ các lời nhắc đã được chấp nhận và các trao đổi công cụ đã hoàn tất khỏi lịch sử được lưu bền vững (#10788), và việc một lượt chạy vượt ngân sách làm mất tiến trình đang hiển thị sau khi khôi phục phiên (#10659), trong khi pull request để lưu tiến trình lượt chạy bị gián đoạn vẫn chưa được hợp nhất. Tất cả đều đang mở vào ngày 21 tháng 9 năm 2026 và một số được đánh dấu đang xử lý, nên hãy kiểm tra lại thay vì trích dẫn thông tin tại thời điểm này.
Về chi phí, v0.8.5 và master thực sự không đồng nhất, và bạn nên đọc phiên bản phù hợp với bản dựng của mình. Tài liệu của bản phát hành gọi bản ghi cuối là thông báo thành công thay vì sổ cái chuẩn của mọi lần thử, đồng thời nói không được suy ra độ chính xác chi phí từng lần thử từ đó; master thay đoạn này bằng sổ cái usage_by_provider cho từng lần thử từ pull request #8966, hợp nhất ngày 18 tháng 9 năm 2026, chưa có trong bản phát hành nào và chính master cũng giới hạn nó cho các đường dẫn lượt chạy có ghi nhận sự kiện. Trong khi đó, ảnh chụp nhanh mức sử dụng của luồng bị gián đoạn là một trường tùy chọn có thể vắng mặt, và ZeroClaw yêu cầu endpoint tương thích OpenAI cung cấp mức sử dụng trong một đoạn SSE cuối — đoạn mà luồng bị cắt ngắn có thể không bao giờ gửi. Hãy coi điểm cuối cùng là một cơ chế cần kiểm tra trong đầu ra chi phí của chính bạn, không phải kết quả đã đo. Thay vào đó, hãy đối soát với bản ghi sử dụng của chính endpoint; trên Kunavo, đó là nhật ký sử dụng.
Tại sao gateway đứng trước mô hình lại tạo ra dấu hiệu này
Nguyên nhân bên thứ ba có khả năng nhất là tín hiệu hoàn tất không bao giờ đến. Tài liệu truyền luồng v0.8.5 của ZeroClaw nêu rằng các phương thức truyền tải không dựa vào việc đóng kết nối làm tín hiệu thành công: luồng tương thích OpenAI kết thúc bằng [DONE], luồng OpenAI Responses bằng sự kiện phản hồi đầu cuối của nó, và luồng Anthropic bằng message_stop, còn máy chủ có thể giữ kết nối HTTP mở sau các sự kiện đó. Luồng đóng mà không có tín hiệu tương ứng được hiển thị như lỗi — SSE stream closed before {completion_signal}: response truncated — thay vì thành công ngắn. Đó là lỗi của endpoint, không phải của ZeroClaw. Có một ngoại lệ được tài liệu hóa: trình phân tích Anthropic hiện cũng coi EOF sau một message_delta.stop_reason không rỗng là hoàn tất dù không có message_stop, và pull request đề xuất bắt buộc tín hiệu này chưa được đưa vào một trong hai ref.
Nguyên nhân thứ hai là sự im lặng trên socket đang mở. ZeroClaw dùng thời gian chờ khi không có byte thay vì deadline cho toàn bộ yêu cầu, được tài liệu hóa là 300 giây đối với OpenAI Responses và các nhà cung cấp tương thích OpenAI, và 90 giây đối với Anthropic; mỗi lần đọc body sẽ đặt lại đồng hồ. Một endpoint đệm phản hồi upstream rồi không chuyển tiếp gì trong một phút rưỡi sẽ kích hoạt slot họ Anthropic trong khi vẫn tồn tại trên slot tương thích OpenAI — điều đáng biết vì endpoint Anthropic Messages đi vào slot anthropic với tùy chọn ghi đè uri, không phải slot custom. Xem tài liệu base URL của Messages và API tương thích OpenAI để biết hai giao thức wire.
Chi phí của một lượt chạy chết, theo phép tính minh họa
Hãy tách hai khoản phí. Runtime ZeroClaw là $0 — zeroclaw.com nêu rằng nó là mã nguồn mở, được cấp phép kép MIT HOẶC Apache-2.0, không có gói đăng ký và không có chỗ ngồi lưu trữ, đồng thời bạn chỉ trả chi phí cho nhà cung cấp LLM của mình, hoặc hoàn toàn không trả gì khi chạy mô hình cục bộ với Ollama. Không gói nào mở khóa tính năng tiếp tục, ngân sách thử lại lớn hơn hoặc khôi phục có hướng dẫn, vì không có gói nào cả.
Khoản phí của mô hình mới là khoản bị ảnh hưởng bởi gián đoạn. Các con số này là phép tính token dựa trên giả định, không phải chi phí tác vụ đã đo và không phải mức trần hóa đơn. Giả sử một lượt chạy gửi 110.000 token đầu vào không được lưu trong bộ nhớ đệm — kích thước prompt trong sự kiện quá tải có ngày tháng duy nhất mà #10787 ghi lại, khi upstream chấp nhận yêu cầu và chạy prefill trước khi loại bỏ — và nhận 2.000 token đầu ra trước khi luồng chết. Cột ba lần thử là provider_retries + 1 với mặc định được tài liệu hóa là 2. Mức giá là giá hiện hành trong danh mục Kunavo, tính cho mỗi triệu token.
| Mô hình | Đầu vào / đầu ra trên mỗi 1M | Một lần thử đã chết | Ba lần thử |
|---|---|---|---|
| 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 |
Việc một endpoint cụ thể có tính phí cho một yêu cầu mà nó loại bỏ hay không là chính sách thanh toán riêng của endpoint đó, và không có gì trong mã nguồn hoặc tài liệu ZeroClaw nêu điều này — trang này không đo điều đó cho bất kỳ nhà cung cấp nào. Phép tính ở đây nhằm định lượng câu hỏi, không phải trả lời nó. Số tiền trong catalog Kunavo là mức sàn thanh toán chứ không phải mức trần: khi upstream báo chi phí, hóa đơn là giá trị lớn hơn giữa chi phí catalog và chi phí upstream nhân với markup áp dụng. Khoản nạp tối thiểu là $10 tín dụng trả trước, một mức tối thiểu để nạp tiền chứ không phải phí tác vụ hay gói đăng ký — xem chi tiết thanh toán.
Tuyến nào chống chịu tốt nhất trước lỗi này
| Phương thức | Cách hoạt động khi luồng bị gián đoạn giữa chừng | Bạn phải từ bỏ điều gì |
|---|---|---|
| Một endpoint, nhà cung cấp trực tiếp | Cấu hình độ tin cậy chỉ có một ứng viên, nên thuộc nhóm được báo cáo trong #10736 trên v0.8.5 | Việc là nhà cung cấp bên thứ nhất không thay đổi quy trình; một ứng viên vẫn là một ứng viên |
| Một endpoint, gateway | Cấu trúc chỉ có một ứng viên giống hệt. Gateway ở đây cho phép chuyển đổi mô hình trên một khóa và một số dư, không phải tăng khả năng chống gián đoạn luồng | Một bước trung gian bổ sung cũng có thể tự đóng mà không gửi tín hiệu hoàn tất, và ZeroClaw chỉ tính giá cho nó nếu bạn tự viết các mục [cost.rates] |
| Hai ứng viên trở lên trong hồ sơ | Quy trình độ tin cậy có nơi để tiếp tục. Trong lần chạy trên terminal ngày 1 tháng 10 năm 2026, hệ thống đã phục hồi sau cả sự cố xảy ra sớm và giữa phản hồi — thông qua mô hình thứ hai | Một mô hình hoặc bí danh thứ hai cần duy trì, và câu trả lời được phục hồi đến từ phương án dự phòng thay vì lựa chọn đầu tiên |
| Mô hình cục bộ qua Ollama | Gửi lại tiêu tốn thời gian và phần cứng chứ không phải tiền, nên thử lại thận trọng là lựa chọn ít tốn kém | Khoảng cách về năng lực so với các mô hình frontier được lưu trữ, cùng một máy để chạy một mô hình |
| Một agent đăng ký theo mức phí cố định | Hoàn toàn không phải tuyến ZeroClaw — dự án không có gói đăng ký và không có chỗ ngồi được lưu trữ | Bạn sẽ thay đổi client, không thay đổi hành vi khôi phục của ZeroClaw |
Dù chọn phương án nào, quy tắc vận hành vẫn là quy tắc ZeroClaw đã mã hóa: sau [stream interrupted], đọc phần dữ liệu từng phần đã lưu, xác định những gì đã có hiệu lực, rồi gửi lại nội dung hẹp hơn bản gốc. Tài liệu tham khảo cấu hình của Kunavo cho các endpoint tương thích OpenAI và kiểu Messages là tài liệu thiết lập chứ không phải bài kiểm tra tương thích — lần chạy ngày 1 tháng 10 ở trên sử dụng máy chủ kiểm thử cục bộ, không phải Kunavo. Bắt đầu tại tài liệu tham khảo lỗi để giải mã những gì endpoint trả về, và tạo tài khoản Kunavo khi bạn sẵn sàng nạp tiền cho một khóa. OpenRouter so với LiteLLM là phép so sánh gần nhất cho quyết định một ứng viên so với nhiều ứng viên ở trên.
Câu hỏi thường gặp
ZeroClaw có thử lại một stream bị gián đoạn không?
Điều đó hoàn toàn phụ thuộc vào việc bạn đã thấy đầu ra hay chưa. Tài liệu định tuyến nhà cung cấp của ZeroClaw cho bản phát hành v0.8.5 cho biết luồng được mở một lần và không chuyển sang mục khác sau khi luồng đã bắt đầu, vì vậy không có luồng nào được tiếp tục — nếu có khôi phục thì đó là một yêu cầu hoàn toàn mới. Nếu luồng thất bại trước khi bất kỳ đầu ra sự kiện bất biến nào hiển thị, hành vi được mô tả trong tài liệu là runtime thử lại toàn bộ lệnh gọi qua đường dẫn không truyền luồng. Khi văn bản, suy luận hoặc các sự kiện công cụ được thực thi trước đã đến một bộ nhận sự kiện bất biến, sự gián đoạn trở thành StreamInterruptedAfterOutput và runtime không phát lại yêu cầu. Quy tắc thứ hai cũng giống trên master. Tuy nhiên, khi chạy ngày 1 tháng 10 năm 2026 trong ứng dụng dòng lệnh tương tác của v0.8.5, không quy tắc nào diễn ra đúng như được viết: với một ứng viên, không có lần thử lại nào trước hoặc sau khi văn bản xuất hiện, còn với ứng viên thứ hai trong fallback_models, lượt đó được gửi lại không truyền luồng đến mô hình thứ hai trong cả hai trường hợp, kể cả sau khi một phần câu trả lời đã được in ra. Các kênh và WebSocket của gateway không được chạy thử. Tài liệu được kiểm tra ngày 21 tháng 9 năm 2026.
[stream interrupted] trong ZeroClaw có nghĩa là gì?
Đây là marker hiển thị cho người dùng đối với một stream truyền tải đã chết giữa lượt, được định nghĩa trong tệp locale tiếng Anh của ZeroClaw bằng khóa Fluent turn-stream-interrupted và hiển thị trên mọi phương thức truyền tải — channels, WS, RPC, ACP và CLI. Nó cố ý khác với marker [interrupted by user] và [turn cancelled via client], vì vậy khi thấy marker này, bạn biết không ai nhấn dừng. Khi stream chết sau khi đã có output hiển thị, văn bản một phần được lưu thành tin nhắn của assistant với marker được nối vào, nhưng chỉ khi văn bản một phần không rỗng: một lượt chỉ tạo ra suy luận hoặc chỉ tạo ra các sự kiện công cụ đã được thực thi trước đó sẽ không lưu gì. Các bản cài đặt không phải tiếng Anh vẫn mang cùng khóa với văn bản đã dịch, vì vậy đừng grep chuỗi trong ngoặc tiếng Anh trên một bản cài đặt như vậy. Được đọc tại thẻ phát hành v0.8.5 ngày 21 tháng 9 năm 2026. Trên client terminal tương tác của v0.8.5 vào ngày 1 tháng 10 năm 2026, một stream bị ngắt giữa câu trả lời không in marker này; terminal hiển thị lỗi nhà cung cấp thất bại.
Có an toàn không nếu chỉ gửi lại prompt sau khi stream ZeroClaw bị gián đoạn?
Không tự động, và chính những người duy trì ZeroClaw cũng xử lý theo cách đó. Runtime đọc stream đến khi hoàn tất, khôi phục các lệnh gọi công cụ sau khi stream kết thúc, rồi chạy chúng — vì vậy các công cụ của lần lặp bị lỗi chưa được chạy. Nhưng một lượt dài cũng có thể bị lỗi ở các lần lặp sau: một báo cáo upstream ghi nhận lệnh gọi công cụ trước đó đã hoàn tất thành công trước khi lỗi xảy ra, còn log khác cho thấy lỗi rơi vào lần lặp 2 với 126 tin nhắn trong yêu cầu. Bất cứ điều gì một lần lặp trước đó đã thực hiện — ghi tệp, chạy lệnh, gửi tin nhắn — sẽ xảy ra lần nữa nếu bạn mù quáng gửi lại cùng prompt. Yêu cầu tính năng đang mở về khôi phục có hướng dẫn liệt kê các mục không thuộc phạm vi là phát lại mù quáng một lượt có công cụ hoặc yêu cầu phê duyệt, và coi mọi lỗi nhà cung cấp là tạm thời. Trước tiên hãy đọc văn bản một phần đã lưu, kiểm tra những gì đã có hiệu lực, rồi gửi lại một prompt được thu hẹp thay vì prompt ban đầu.
Tôi có thể cấu hình ZeroClaw để tiếp tục luồng bị gián đoạn không?
Không. Không có tùy chọn nào cho việc này trong bất kỳ phiên bản đã phát hành nào, cũng không có gói trả phí nào mở khóa tính năng đó — ZeroClaw miễn phí và mã nguồn mở, được cấp phép kép MIT OR Apache-2.0, không có gói đăng ký và không có suất người dùng trên dịch vụ được lưu trữ sẵn, nên giới hạn này là ranh giới kỹ thuật chứ không phải ranh giới gói dịch vụ. Quy tắc không phát lại sau khi đã có đầu ra hiển thị nằm trong mã nguồn và được khóa bằng một bài kiểm thử hồi quy, với thông báo lỗi rằng lỗi luồng sau đầu ra hiển thị phải làm lượt chạy thất bại mà không thử lại dự phòng — tuy nhiên, trong ứng dụng terminal tương tác của v0.8.5 vào ngày 1 tháng 10 năm 2026, một cấu hình có ứng viên thứ hai đã gửi lại sau khi văn bản được in, nên quy tắc này không được đảm bảo trên mọi phương thức truyền tải. Khôi phục có hướng dẫn sau một lượt bị gián đoạn là issue #10634 — đang mở, có nhãn status:accepted và priority:p2, đồng thời được chuyển đến needs design hoặc thảo luận RFC trước, tính đến ngày 21 tháng 9 năm 2026. Accepted nghĩa là bộ phận phân loại đã chấp nhận mô tả vấn đề, không có nghĩa là mã đã được viết hoặc hợp nhất.
Nhật ký của tôi cho biết hệ thống đang chuyển sang trò chuyện không truyền luồng rồi lượt chạy bị chết. Tại sao?
Trên v0.8.5 đã phát hành, dòng nhật ký đó có thể không đúng. Upstream issue #10736, có tiêu đề nói rằng lỗi luồng trước đầu ra bỏ qua phương án dự phòng không truyền luồng được quảng bá, báo cáo rằng runtime ghi nhật ký đang chuyển sang trò chuyện không truyền luồng nhưng không gửi yêu cầu không truyền luồng, rồi lượt chạy kết thúc ngay với All model providers/models failed after 0 failure event(s). Phần tác động của issue nêu nhóm bị ảnh hưởng là người dùng có một ứng viên nhà cung cấp duy nhất, đặc biệt là các cấu hình có số lần thử lại bằng không. Số lần thử lại bằng không không phải trường hợp duy nhất: bản tái hiện đặt provider_retries = 0, nhưng issue tiếp theo #10787 tái hiện cùng lỗi ngay lập tức khi provider_retries giữ nguyên mặc định được tài liệu hóa là 2. Issue này được đóng ngày 18 tháng 9 năm 2026, sau khi v0.8.5 được phát hành ngày 5 tháng 9, nên không bản phát hành nào chứa bản sửa. Lỗi được tái hiện trên v0.8.5 ngày 1 tháng 10 năm 2026: một yêu cầu truyền luồng, không có lần theo sau không truyền luồng, và lỗi đó — với provider_retries = 2, bất kể luồng bị ngắt trước hay sau khi văn bản xuất hiện. Thêm mô hình thứ hai vào fallback_models là đủ để lượt chạy khôi phục. Gỡ lỗi từ nhật ký trên v0.8.5 có nghĩa là đọc thấy một phương án dự phòng đã không xảy ra.
Lượt chạy bị gián đoạn có bị tính phí không, và tôi kiểm tra bằng cách nào?
Hãy kiểm tra bản ghi sử dụng của chính endpoint thay vì của ZeroClaw, vì tài liệu v0.8.5 yêu cầu bạn không tin vào số liệu cho từng lần thử của nó: tài liệu mô tả thông báo dự phòng cuối cùng là thông báo thành công, không phải sổ cái chuẩn ghi nhận mọi lần thử, và nói không được suy ra độ chính xác chi phí từng lần thử từ đó. Sổ cái usage_by_provider cho từng lần thử giải quyết vấn đề này đã được đưa vào master qua pull request #8966, hợp nhất ngày 18 tháng 9 năm 2026, sau khi v0.8.5 phát hành, nên chưa có trong bản phát hành nào — và master giới hạn nó cho các đường dẫn lượt chạy có ghi nhận sự kiện. ZeroClaw có chụp ảnh nhanh mức sử dụng trên một luồng bị gián đoạn, nhưng trường này là tùy chọn và có thể vắng mặt; đồng thời nó yêu cầu các endpoint tương thích OpenAI gửi mức sử dụng trong một đoạn SSE cuối — đoạn mà luồng bị cắt ngắn có thể không bao giờ gửi. Điểm cuối cùng được đọc từ mã nguồn, không phải quan sát trong runtime. Ngoài ra, số liệu chi phí của chính ZeroClaw lấy từ các bảng giá [cost.rates] do người vận hành viết trong cấu hình của bạn, nên endpoint chưa được định giá ở đó cũng không được ZeroClaw định giá.
Chạy ngày 1 tháng 10 năm 2026: tệp nhị phân bản phát hành v0.8.5 ở chế độ terminal tương tác, kết nối với máy chủ kiểm thử cục bộ đã ngắt luồng — bốn hàng của bảng kết quả; không chạy thêm gì khác và không có yêu cầu nào gửi đến Kunavo. Trạng thái issue được kiểm tra lại cùng ngày (#10787 nay đã đóng; #10634 vẫn đang mở). Mã nguồn kho lưu trữ được đọc tại thẻ phát hành v0.8.5, tài liệu được đọc tại đường dẫn /v0.8.5/ cố định theo phiên bản, còn trạng thái issue và pull request được đọc ngày 21 tháng 9 năm 2026; một số issue trong đó được đánh dấu đang xử lý và có thể thay đổi. Mức giá token của Kunavo lấy từ danh mục giá hiện hành, và mọi con số đô la ở đây chỉ là phép tính token minh họa chứ không phải chi phí tác vụ được đo lường.