ZeroClaw tidak pernah melanjutkan stream yang rusak. Apakah sistem mengirim ulang giliran bergantung pada jumlah kandidat dalam profil Anda, dan pada satu-satunya rilis saat ini, perilakunya tidak sepenuhnya sesuai dengan yang dijanjikan dokumentasi. Dokumentasi ZeroClaw untuk v0.8.5 (diterbitkan pada 5 September 2026) menyatakan bahwa stream yang gagal sebelum output apa pun akan dicoba lagi tanpa streaming, sedangkan stream yang gagal setelah output tidak pernah diputar ulang. Saat dijalankan pada 1 Oktober 2026 terhadap endpoint yang memutus stream di tengah balasan, klien terminal v0.8.5 melakukan hal yang lebih sederhana: dengan satu kandidat, tidak ada percobaan ulang sama sekali, baik sebelum maupun setelah teks muncul; dengan kandidat kedua, sistem mengirim ulang giliran tersebut tanpa streaming ke model kedua — bahkan setelah sebagian jawaban sudah tampil di layar. Pemulihan terpandu setelah output parsial adalah permintaan fitur terbuka yang belum memperoleh persetujuan desain. Jadi pertanyaan yang berguna bukanlah bagaimana membuat ZeroClaw mencoba lagi. Pertanyaannya adalah apakah giliran Anda aman untuk dikirim ulang, dan berapa biaya yang sudah ditimbulkan oleh percobaan yang gagal tersebut.
Dua catatan cakupan sebelum semua ini dapat ditindaklanjuti. Yang dijalankan cakupannya sempit: biner rilis v0.8.5 dalam mode terminal interaktifnya, satu endpoint yang kompatibel dengan OpenAI, dan server pengujian lokal yang sengaja menutup stream — hasilnya ada di bawah. Channels, WebSocket gateway, RPC, ACP, slot Anthropic, dan gangguan provider nyata tidak dijalankan. Setiap klaim lainnya dibaca dari repositori pada tag rilis v0.8.5, dari dokumentasi yang dipatok versinya di docs.zeroclaw.com/v0.8.5/, atau dari laporan issue upstream bertanggal, semuanya pada 21 September 2026. Dan sematkan URL itu sendiri: README mengarahkan pembaca ke path /master/, yang HEAD-nya enam belas hari lebih maju daripada rilis tersebut dan bertentangan dengannya tepat pada subjek ini, sementara /latest/ mengembalikan 404. ZeroClaw di sini berarti runtime zeroclaw-labs/zeroclaw; jika Anda tidak yakin bahwa itulah yang sedang Anda jalankan, ZeroClaw vs OpenClaw membedakannya dari proyek dan fork yang menggunakan nama yang sama.
Empat penanda pada v0.8.5, dan hanya satu di antaranya yang merupakan jaringan
Sebelum mengambil keputusan apa pun, baca penanda mana yang sebenarnya Anda dapatkan. File locale bahasa Inggris ZeroClaw pada v0.8.5 mendefinisikan ini sebagai kunci Fluent yang berbeda di bawah komentar header yang menyatakan bahwa penanda tersebut ditambahkan ke, atau dipertahankan sebagai, output asisten ketika giliran terputus sebelum selesai, dan ditampilkan kepada pengguna akhir di seluruh transport — channels, WS, RPC, ACP, dan CLI.
| Penanda | Kunci Fluent | Informasi yang diberikannya |
|---|---|---|
[stream interrupted] | turn-stream-interrupted | Stream transport mati di tengah giliran. Tidak ada yang menekan tombol berhenti. |
[interrupted by user] | turn-interrupted-by-user | Interupsi manusia. |
[turn cancelled via client] | turn-cancelled-client-rpc | Channel, bukan aktornya. Komentar kode miliknya sendiri menyatakan bahwa interupsi manusia dan pembatalan klien secara programatik sama-sama tiba di jalur ini, sehingga susunan katanya menyebutkan channel. |
[interrupted by user before this tool produced a result] | turn-tool-interrupted-before-result | Sebuah tool terputus sebelum mengembalikan hasil. |
Kunci kelima, turn-failed = [turn failed], ada di file yang sama pada master tetapi tidak ada di file locale v0.8.5, sehingga build rilis tidak akan mengeluarkannya. Ada satu perilaku yang perlu diketahui karena mengubah apa yang dapat Anda baca setelahnya: mesin giliran mempertahankan teks parsial dengan penanda yang ditambahkan hanya ketika teks parsial tersebut tidak kosong. Giliran yang menghasilkan penalaran atau event tool yang telah dieksekusi di sisi provider tetapi tidak menghasilkan teks yang terlihat tidak mempertahankan apa pun — komentar kode menjelaskan persistensi sebagai tindakan menyimpan apa yang sudah dilihat konsumen. Locale lain membawa kunci yang sama dengan nilai terjemahan, sehingga string kurung bahasa Inggris literal bukanlah yang ditampilkan oleh instalasi non-Inggris.
Di mana batas percobaan ulang sebenarnya berada
Seluruh keputusan bermuara pada satu pertanyaan: apakah sesuatu sudah mencapai sink event yang tidak dapat diubah?
| Apa yang terjadi | Perilaku yang didokumentasikan pada v0.8.5 | Catatan |
|---|---|---|
| Stream gagal sebelum ada output yang terlihat | Runtime mencoba ulang seluruh panggilan melalui jalur non-streaming, dengan memasuki kembali seluruh alur keandalan | Didokumentasikan, tetapi bukan yang diamati oleh penyiapan dengan satu kandidat pada build rilis — lihat di bawah |
| Stream selesai tanpa teks final dan tanpa pemanggilan tool | Respons yang kosong secara semantik, bukan jawaban. Ketika hasil ditandai aman untuk diputar ulang dan provider_retries bernilai bukan nol, satu panggilan pemulihan non-streaming ke provider dan model yang sama persis, digunakan sekali | Dikirimkan dalam v0.8.5 melalui pull request #10602, yang digabungkan pada 4 September 2026. Berlaku untuk stream kosong, bukan untuk stream yang terputus di tengah output |
| Teks, penalaran, atau event tool yang telah dieksekusi sebelumnya sudah mencapai sink event yang tidak dapat diubah | StreamInterruptedAfterOutput. Runtime tidak memutar ulang request, dan hanya teks yang sudah diteruskan ke konsumen yang menjadi teks parsial asisten yang dipertahankan | Disengaja dan identik pada master. Dikunci oleh regression test yang menegaskan bahwa error stream setelah output yang terlihat harus menggagalkan giliran tanpa percobaan ulang fallback |
| Salah satu di atas | Stream dibuka sekali dan entri tidak diganti setelah stream dimulai | Pemulihan selalu berupa request baru. Tidak ada keluarga provider, termasuk slot kustom, yang mendapatkan jalur resume |
Knob yang memang ada bersifat global, bukan per endpoint. [reliability] membawa provider_retries, default yang didokumentasikan adalah 2, serta provider_backoff_ms, default 500, dan dokumentasi siklus hidup menyatakan bahwa setiap entri yang terwujud dicoba hingga provider_retries + 1 kali. Referensi konfigurasi v0.8.5 tidak mendokumentasikan penggantian percobaan ulang per provider atau per alias di sampingnya. Jangan pula mengandalkan pool kunci: dokumentasi v0.8.5 menyatakan bahwa reliability.api_keys belum menjadi failover yang berfungsi saat ini, karena wrapper memilih dan mencatat kunci alternatif setelah rate limit yang dapat dicoba ulang, tetapi tidak dapat menerapkannya pada provider yang dibangun, sehingga percobaan ulang tetap menggunakan kredensial asli. Kunci kedua yang Anda tambahkan dengan harapan menjadi penyelamat tidak memberikan penyelamatan.
Menunjuk ke satu endpoint adalah konfigurasi yang paling terdampak
Ini adalah batas paling tegas bagi siapa pun yang menjalankan ZeroClaw terhadap satu gateway atau satu endpoint vendor, karena satu endpoint secara definisi merupakan konfigurasi keandalan dengan satu kandidat. Issue #10736 melaporkan bahwa pada build rilis, kegagalan stream sebelum output dalam bentuk tersebut mencatat fallback ke chat non-streaming lalu tidak pernah mengirimkannya, sehingga giliran berakhir dengan All model providers/models failed after 0 failure event(s). Issue tersebut ditutup pada 18 September 2026 — setelah v0.8.5 diterbitkan — sehingga perbaikannya hanya ada di master. Saat dijalankan pada 1 Oktober 2026, v0.8.5 yang dirilis berperilaku persis seperti yang dijelaskan issue tersebut: satu request, lalu error itu, baik stream terputus sebelum maupun sesudah teks muncul.
Dua posisi resmi tidak sepakat di sini dan keduanya layak dibawa. Dokumentasi arsitektur v0.8.5 menjanjikan percobaan ulang non-streaming; issue tersebut menunjukkan bahwa build rilis tidak melakukannya, dan bagian perilaku yang diharapkan meminta agar log hanya mengklaim fallback ketika fallback benar-benar akan dicoba. Master kemudian menambahkan kelonggaran pemulihan untuk satu kandidat yang tidak dimiliki rilis — dan issue #10787 menyatakan bahwa kelonggaran tersebut diberikan dengan RetryDecision::Admit(0) terlepas dari provider_retries dan tanpa backoff, sehingga upstream yang kelebihan beban segera dikirimi ulang dalam jendela beban yang sama. Issue tersebut ditutup sebagai selesai pada 26 September 2026 — di master, setelah v0.8.5, sehingga tidak ada rilis yang memilikinya. Perilaku master masih berubah; jangan membuat rencana berdasarkan perilaku tersebut.
Bentuk mitigasi yang didokumentasikan adalah konfigurasi, bukan sebuah pengaturan: berikan profil kandidat kedua agar alur keandalan memiliki tujuan berikutnya. Pada 1 Oktober 2026, cara ini berhasil pada v0.8.5 di terminal — dengan satu catatan yang perlu diketahui sebelum Anda mengandalkannya: request pemulihan dikirim ke model kedua, bukan yang pertama, sehingga jawaban yang Anda dapatkan setelah terputus berasal dari fallback Anda. Panduan biaya dan penyiapan API ZeroClaw membahas bentuk konfigurasi tempat entri tersebut dimasukkan.
Yang dilakukan v0.8.5 ketika stream terputus
Pada 1 Oktober 2026, biner rilis v0.8.5, yang checksum-nya diverifikasi terhadap SHA256SUMS milik rilis tersebut, dijalankan dalam container sementara dalam mode terminal interaktif — mode yang melakukan streaming; mode -m untuk satu pesan mengirim satu request non-streaming dan tidak pernah mencapai jalur ini. Satu profil slot kustom yang kompatibel dengan OpenAI, provider_retries = 2, diarahkan ke server pengujian lokal yang menjawab dengan stream normal lalu menutup koneksi tanpa [DONE], baik sebelum event pertama maupun setelah satu chunk teks.
| Profil | Di mana stream terputus | Request yang dikirim | Yang ditampilkan terminal |
|---|---|---|---|
| Satu kandidat | Sebelum teks apa pun | Satu request streaming, tanpa percobaan ulang | Error: Provider model yang dipilih gagal. Tinjau konfigurasi provider atau pilih provider lain. Log: All model providers/models failed after 0 failure event(s) |
| Satu kandidat | Setelah teks dicetak | Satu request streaming, tanpa percobaan ulang | Teks parsial, lalu error yang sama. Tidak ada penanda [stream interrupted] yang dicetak |
Ditambah fallback_models dengan model kedua | Sebelum teks apa pun | Request streaming, lalu satu request non-streaming ke model kedua | Balasan model kedua |
Ditambah fallback_models dengan model kedua | Setelah teks dicetak | Dua request yang sama | Teks parsial, lalu seluruh balasan model kedua — sehingga jawaban muncul dua kali |
Ada tiga hal yang perlu diperhatikan oleh siapa pun yang menjalankan ZeroClaw dari terminal pada v0.8.5. Kegagalan satu kandidat adalah #10736, dan berhasil direproduksi; provider_retries tidak mengubahnya. Batas yang didokumentasikan, yaitu "tidak ada pemutaran ulang setelah output terlihat", tidak berlaku di sini: teks yang sudah dicetak di terminal tidak menghentikan pengiriman ulang, sehingga giliran yang Anda lihat tiba sebagian masih dapat dikirim lagi ke model yang berbeda. Dan log giliran mencatat model pertama sebagai model giliran tersebut, sementara teks berasal dari model kedua, yang merupakan celah atribusi yang diperingatkan oleh dokumentasi v0.8.5 sendiri. Yang tidak dicakup oleh proses ini: channels seperti Telegram atau Slack, WebSocket gateway, klien RPC dan ACP — transport yang sink event-nya menjadi dasar aturan tanpa pemutaran ulang — slot Anthropic, gangguan provider nyata, dan request apa pun melalui Kunavo.
Sebelum mengirim ulang: apa yang sudah berjalan, dan apa yang sudah ditagihkan
Loop tool milik ZeroClaw membaca stream hingga selesai, memulihkan pemanggilan tool setelah stream berakhir, menjalankannya, lalu membuka panggilan streaming baru untuk giliran asisten berikutnya. Jadi tool yang diminta oleh iterasi yang terputus belum dijalankan — tetapi ini merupakan kepastian yang lebih sempit daripada kedengarannya. Pemanggilan tool yang telah dieksekusi sebelumnya di sisi provider adalah kelas event terpisah yang sudah menimbulkan efek di upstream, dan justru itulah sebabnya pemanggilan tersebut menghalangi pemutaran ulang. Giliran yang panjang juga dapat terputus di akhir: #10736 mencatat bahwa pemanggilan tool sebelumnya berhasil diselesaikan sebelum kegagalannya, dan log #10787 menunjukkan putusnya koneksi terjadi pada iterasi 2 dengan 126 pesan dalam request. Mengirim ulang prompt asli akan memutar ulang setiap efek samping sebelumnya yang akan diulangi oleh model.
Transkrip yang tampak bersih juga bukan bukti. Issue #9421, yang terbuka dengan prioritas p1 untuk keluarga provider Anthropic dan yang kompatibel dengan OpenAI, berjudul bahwa respons terminal yang tidak lengkap dapat dilaporkan sebagai berhasil. Pada permukaan Code/ACP, dua laporan p1 terbuka lainnya menjelaskan bahwa giliran yang gagal membuang prompt yang telah diterima dan pertukaran tool yang telah selesai dari histori persisten (#10788) serta giliran yang melampaui anggaran kehilangan progres yang terlihat setelah pemulihan sesi (#10659), sementara pull request untuk mempertahankan progres giliran yang terputus masih belum digabungkan. Semuanya masih terbuka pada 21 September 2026 dan beberapa ditandai sedang dalam proses, jadi periksa kembali alih-alih mengutip snapshot ini.
Dalam hal biaya, v0.8.5 dan master benar-benar berbeda dan Anda harus membaca yang sesuai dengan build Anda. Dokumentasi rilis menyebut catatan final sebagai pemberitahuan keberhasilan, bukan ledger kanonis untuk setiap percobaan, dan menyatakan agar tidak menyimpulkan akurasi biaya per percobaan darinya; master mengganti paragraf tersebut dengan ledger usage_by_provider per percobaan dari pull request #8966, yang digabungkan pada 18 September 2026, yang tidak dimiliki rilis mana pun dan oleh master sendiri dibatasi pada jalur giliran yang diinstrumentasikan dengan event. Sementara itu, snapshot penggunaan interrupted-stream adalah field opsional yang dapat tidak ada, dan ZeroClaw meminta endpoint yang kompatibel dengan OpenAI untuk penggunaan dalam chunk SSE final — chunk yang mungkin tidak pernah dikirim oleh stream yang terpotong. Perlakukan poin terakhir itu sebagai mekanisme yang perlu diperiksa dalam output biaya Anda sendiri, bukan sebagai hasil yang diukur. Rekonsiliasikan dengan catatan penggunaan milik endpoint itu sendiri; di Kunavo, catatan tersebut adalah log penggunaan.
Mengapa gateway di depan model menghasilkan penanda ini
Penyebab pihak ketiga yang paling mungkin adalah sinyal penyelesaian yang tidak pernah tiba. Dokumentasi streaming ZeroClaw v0.8.5 menyatakan bahwa transport tidak mengandalkan penutupan koneksi sebagai sinyal keberhasilan: stream yang kompatibel dengan OpenAI selesai pada [DONE], stream OpenAI Responses pada event respons terminalnya, dan stream Anthropic pada message_stop, sementara server dapat mempertahankan koneksi HTTP tetap terbuka setelah event tersebut. Stream yang ditutup tanpa sinyalnya ditampilkan sebagai error — SSE stream closed before {completion_signal}: response truncated — bukan sebagai keberhasilan singkat. Itu adalah cacat endpoint, bukan cacat ZeroClaw. Ada satu pengecualian yang didokumentasikan: parser Anthropic saat ini juga memperlakukan EOF setelah message_delta.stop_reason yang tidak kosong sebagai selesai meskipun tanpa message_stop, dan pull request yang mengusulkan agar sinyal tersebut diwajibkan belum diterapkan pada kedua ref.
Penyebab kedua adalah keheningan pada socket yang tetap terbuka. ZeroClaw menggunakan batas waktu idle byte, bukan tenggat seluruh request, yang didokumentasikan sebagai 300 detik untuk OpenAI Responses dan provider yang kompatibel dengan OpenAI serta 90 detik untuk Anthropic, dengan setiap pembacaan body mengatur ulang penghitung waktu. Endpoint yang melakukan buffering terhadap respons upstream dan tidak meneruskan apa pun selama satu setengah menit akan memicu slot keluarga Anthropic sementara tetap bertahan pada slot yang kompatibel dengan OpenAI — hal yang perlu diketahui karena endpoint Anthropic Messages masuk ke slot anthropic dengan penggantian uri, bukan ke custom. Lihat dokumentasi base URL Messages dan API yang kompatibel dengan OpenAI untuk kedua protokol wire tersebut.
Biaya giliran yang terputus, dalam perhitungan ilustratif
Pisahkan kedua tagihan tersebut. Runtime ZeroClaw berharga $0 — zeroclaw.com menyatakan bahwa runtime ini bersifat open source, berlisensi ganda MIT ATAU Apache-2.0, tanpa langganan dan tanpa seat ter-host, serta Anda hanya membayar biaya provider LLM Anda sendiri, atau tidak membayar apa pun ketika menjalankan model lokal dengan Ollama. Tidak ada tingkat layanan yang membuka resume, anggaran percobaan ulang yang lebih besar, atau pemulihan terpandu, karena memang tidak ada tingkat layanan.
Tagihan model adalah bagian yang terdampak oleh interupsi. Angka-angka ini adalah perhitungan token berdasarkan asumsi, bukan biaya tugas yang diukur dan bukan batas maksimum tagihan. Asumsikan satu giliran mengirim 110.000 token input yang tidak di-cache — ukuran prompt dalam satu episode overload bertanggal #10787, ketika upstream menerima request dan menjalankan prefill sebelum menolaknya — serta menerima 2.000 token output sebelum stream mati. Kolom tiga percobaan adalah provider_retries + 1 pada default terdokumentasi sebesar 2. Tarif adalah harga live katalog Kunavo per juta token.
| Model | Input / output per 1M | Satu percobaan yang gagal | Tiga percobaan |
|---|---|---|---|
| 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 |
Apakah endpoint tertentu menagih request yang ditolaknya merupakan kebijakan penagihan endpoint itu sendiri, dan tidak ada apa pun dalam source atau dokumentasi ZeroClaw yang menyatakannya — halaman ini tidak mengukurnya untuk provider mana pun. Perhitungan tersebut ada untuk memperkirakan besarnya pertanyaan, bukan untuk menjawabnya. Jumlah katalog Kunavo adalah batas bawah penagihan, bukan batas atas: ketika upstream melaporkan biayanya, tagihan adalah nilai yang lebih besar antara biaya katalog dan biaya upstream dikalikan markup yang berlaku. Top-up minimum adalah $10 dalam kredit prabayar, yaitu minimum pendanaan, bukan biaya tugas atau langganan — lihat detail penagihan.
Rute mana yang paling mampu bertahan terhadap kegagalan ini
| Rute | Perilakunya saat terjadi putus di tengah stream | Yang Anda korbankan |
|---|---|---|
| Satu endpoint, vendor langsung | Konfigurasi keandalan dengan satu kandidat, sehingga termasuk dalam populasi yang dilaporkan #10736 pada v0.8.5 | Tidak ada yang berubah hanya karena merupakan vendor pihak pertama; satu kandidat tetap satu kandidat |
| Satu endpoint, gateway | Bentuk satu kandidat yang identik. Yang dibeli gateway di sini adalah perpindahan model pada satu kunci dan satu saldo, bukan ketahanan stream | Hop tambahan yang juga dapat ditutup tanpa sinyal penyelesaian, dan ZeroClaw hanya menentukan harganya jika Anda menulis sendiri entri [cost.rates] |
| Dua kandidat atau lebih dalam profil | Alur keandalan memiliki tujuan berikutnya. Dalam proses terminal pada 1 Oktober 2026, sistem pulih setelah putus di awal dan di tengah balasan — melalui model kedua | Model atau alias kedua yang perlu dipelihara, serta jawaban yang dipulihkan yang berasal dari fallback Anda, bukan pilihan pertama Anda |
| Model lokal melalui Ollama | Pengiriman ulang memerlukan waktu dan perangkat keras, bukan uang, sehingga percobaan ulang yang konservatif biayanya rendah | Kesenjangan kapabilitas terhadap model frontier ter-host, serta mesin untuk menjalankannya |
| Agen berlangganan tarif tetap | Bukan rute ZeroClaw sama sekali — proyek ini tidak memiliki langganan dan tidak memiliki seat ter-host | Anda akan mengubah klien, bukan mengubah perilaku pemulihan ZeroClaw |
Apa pun yang Anda pilih, aturan operasionalnya adalah yang sudah dikodekan ZeroClaw: setelah [stream interrupted], baca bagian parsial yang dipertahankan, pastikan apa yang sudah berdampak, lalu kirim ulang sesuatu yang lebih sempit daripada yang asli. Referensi konfigurasi Kunavo untuk endpoint yang kompatibel dengan OpenAI dan endpoint bergaya Messages adalah dokumentasi penyiapan, bukan pengujian kompatibilitas — proses pada 1 Oktober di atas menggunakan server pengujian lokal, bukan Kunavo. Mulai dari referensi error untuk menguraikan apa yang dikembalikan endpoint Anda, dan buat akun Kunavo ketika Anda siap mendanai kunci. OpenRouter vs LiteLLM adalah perbandingan terdekat untuk keputusan satu kandidat versus banyak kandidat di atas.
Pertanyaan umum
Apakah ZeroClaw mencoba lagi stream yang terputus?
Itu sepenuhnya bergantung pada apakah Anda sudah melihat output. Dokumentasi perutean penyedia ZeroClaw untuk v0.8.5 yang dirilis menyatakan bahwa stream dibuka sekali dan entri tidak dialihkan setelah dimulai, sehingga tidak ada yang pernah dilanjutkan — pemulihan, jika tersedia, merupakan permintaan baru. Jika stream gagal sebelum output peristiwa yang tidak dapat diubah terlihat, perilaku yang terdokumentasi adalah runtime mencoba kembali seluruh panggilan melalui jalur non-streaming. Setelah teks, penalaran, atau peristiwa alat yang telah dieksekusi sebelumnya mencapai sink peristiwa yang tidak dapat diubah, interupsi menjadi StreamInterruptedAfterOutput dan runtime tidak memutar ulang permintaan. Aturan kedua tersebut sama pada master. Namun, saat dijalankan pada 1 Oktober 2026 di klien terminal interaktif v0.8.5, tidak satu pun aturan muncul seperti yang tertulis: dengan satu kandidat tidak ada percobaan ulang, baik sebelum maupun sesudah teks muncul, sedangkan dengan kandidat kedua di fallback_models, giliran tersebut dikirim ulang tanpa streaming ke model kedua dalam kedua kasus, termasuk setelah sebagian jawaban telah dicetak. Channels dan WebSocket gateway tidak dijalankan. Dokumentasi diperiksa pada 21 September 2026.
Apa arti [stream interrupted] di ZeroClaw?
Itu adalah penanda yang terlihat oleh pengguna untuk stream transport yang mati di tengah giliran, yang didefinisikan dalam file locale bahasa Inggris ZeroClaw sebagai kunci Fluent turn-stream-interrupted dan ditampilkan di seluruh transport — channels, WS, RPC, ACP, dan CLI. Penanda ini sengaja berbeda dari [interrupted by user] dan [turn cancelled via client], sehingga melihat penanda ini berarti tidak ada yang menekan tombol berhenti. Ketika stream mati setelah output terlihat, teks parsial disimpan sebagai pesan asisten dengan penanda yang ditambahkan, tetapi hanya jika teks parsial tersebut tidak kosong: giliran yang hanya menghasilkan penalaran atau hanya peristiwa alat yang telah dieksekusi sebelumnya tidak menyimpan apa pun. Instalasi non-Inggris membawa kunci yang sama dengan teks terjemahan, jadi jangan mencari string bahasa Inggris dalam tanda kurung pada instalasi tersebut. Dibaca pada tag rilis v0.8.5 pada 21 September 2026. Pada klien terminal interaktif v0.8.5 tanggal 1 Oktober 2026, stream yang terputus di tengah balasan tidak mencetak penanda ini; terminal menampilkan error kegagalan penyedia.
Apakah aman untuk langsung mengirim ulang prompt setelah stream ZeroClaw terputus?
Tidak secara otomatis, dan pengelola ZeroClaw sendiri memperlakukannya demikian. Runtime membaca stream hingga selesai, memulihkan pemanggilan alat setelah stream berakhir, lalu menjalankannya — jadi alat dari iterasi yang terputus belum dijalankan. Namun, giliran panjang juga dapat terputus pada iterasi berikutnya: satu laporan upstream mencatat bahwa pemanggilan alat sebelumnya berhasil diselesaikan sebelum kegagalan, dan log laporan lain menunjukkan gangguan terjadi pada iterasi 2 dengan 126 pesan dalam permintaan. Apa pun yang sudah dilakukan oleh iterasi sebelumnya — file ditulis, perintah dijalankan, pesan dikirim — akan terjadi lagi jika Anda mengirim ulang prompt yang sama secara buta. Permintaan fitur terbuka untuk pemulihan terpandu mencantumkan sasaran yang tidak termasuk di dalamnya: memutar ulang secara buta giliran yang membawa alat atau persetujuan, serta menganggap setiap error penyedia sebagai sementara. Baca teks parsial yang tersimpan terlebih dahulu, periksa apa yang sudah berlaku, lalu kirim ulang prompt yang dipersempit, bukan prompt asli.
Dapatkah saya mengonfigurasi ZeroClaw untuk melanjutkan stream yang rusak?
Tidak. Tidak ada pengaturan untuk itu dalam versi apa pun yang telah dirilis, dan tidak ada tingkat berbayar yang membukanya — ZeroClaw gratis dan bersumber terbuka, berlisensi ganda MIT OR Apache-2.0, tanpa langganan dan tanpa kursi ter-host, sehingga batas ini merupakan batas rekayasa, bukan batas paket. Aturan tidak memutar ulang setelah output terlihat terdapat dalam source dan dikunci oleh pengujian regresi yang pesan kegagalannya sendiri menyatakan bahwa error stream setelah output terlihat harus menggagalkan giliran tanpa percobaan ulang fallback — meskipun pada klien terminal interaktif v0.8.5 tanggal 1 Oktober 2026, profil dengan kandidat kedua memang mengirim ulang setelah teks dicetak, sehingga aturan tersebut bukan jaminan pada setiap transport. Pemulihan terpandu setelah giliran terinterupsi adalah issue #10634 — masih terbuka, berlabel status:accepted dan prioritas:p2, serta diarahkan ke needs design atau diskusi RFC terlebih dahulu per 21 September 2026. Accepted berarti triase menerima pernyataan masalah, bukan berarti kode telah ditulis atau digabungkan.
Log saya menyatakan bahwa sistem beralih ke chat non-streaming lalu giliran mati. Mengapa?
Pada v0.8.5 yang dirilis, baris log tersebut bisa tidak benar. Upstream issue #10736, yang berjudul bahwa kegagalan stream sebelum output melewati fallback non-streaming yang diiklankan, melaporkan bahwa runtime mencatat dirinya beralih ke chat non-streaming tetapi tidak mengirim permintaan non-streaming, dan giliran langsung berakhir dengan All model providers/models failed after 0 failure event(s). Pernyataan dampaknya sendiri menyebut populasi yang terdampak sebagai pengguna dengan satu kandidat penyedia, khususnya konfigurasi dengan nol percobaan ulang. Nol percobaan ulang bukan satu-satunya kasus: reproduksinya menetapkan provider_retries = 0, tetapi issue lanjutan #10787 mereproduksi kegagalan langsung yang sama dengan provider_retries dibiarkan pada nilai bawaan terdokumentasi, yaitu 2. Issue tersebut ditutup pada 18 September 2026, setelah v0.8.5 diterbitkan pada 5 September, sehingga tidak ada rilis yang diterbitkan yang memuat perbaikannya. Hal ini direproduksi pada v0.8.5 pada 1 Oktober 2026: satu permintaan streaming, tanpa tindak lanjut non-streaming, dan error tersebut — dengan provider_retries = 2, baik stream terputus sebelum maupun sesudah teks muncul. Menambahkan model kedua di bawah fallback_models cukup untuk memulihkan giliran. Men-debug hal ini dari log pada v0.8.5 berarti membaca fallback yang sebenarnya tidak terjadi.
Apakah saya ditagih untuk giliran yang terinterupsi, dan bagaimana cara memeriksanya?
Periksa catatan penggunaan milik endpoint itu sendiri, bukan milik ZeroClaw, karena dokumentasi v0.8.5 memperingatkan agar angka per percobaannya tidak dipercaya: dokumentasi tersebut menjelaskan pemberitahuan fallback terakhir sebagai pemberitahuan keberhasilan, bukan buku besar kanonis untuk setiap percobaan, dan menyatakan agar akurasi biaya per percobaan tidak disimpulkan darinya. Buku besar per percobaan usage_by_provider yang menyelesaikan masalah ini masuk ke master melalui pull request #8966, digabungkan pada 18 September 2026 setelah v0.8.5 dirilis, sehingga belum ada dalam rilis mana pun — dan master membatasinya pada jalur giliran yang diinstrumentasikan dengan peristiwa. ZeroClaw memang menangkap snapshot penggunaan pada stream yang terinterupsi, tetapi field tersebut bersifat opsional dan dapat tidak ada, serta ZeroClaw meminta endpoint yang kompatibel dengan OpenAI untuk menyertakan penggunaan dalam chunk SSE final — chunk yang mungkin tidak pernah dikirim oleh stream yang terpotong. Poin terakhir itu dibaca dari source, bukan diamati saat runtime. Secara terpisah, angka biaya ZeroClaw sendiri berasal dari lembar tarif [cost.rates] yang ditulis operator dalam konfigurasi Anda, sehingga endpoint yang belum Anda beri harga di sana juga tidak diberi harga oleh ZeroClaw.
Dijalankan pada 1 Oktober 2026: biner rilis v0.8.5 dalam mode terminal interaktif terhadap server pengujian lokal yang memutus stream — empat baris tabel hasil; tidak ada hal lain yang dijalankan, dan tidak ada request yang dikirim ke Kunavo. Status issue diperiksa ulang pada hari yang sama (#10787 sejak itu telah ditutup; #10634 masih terbuka). Source repositori dibaca pada tag rilis v0.8.5, dokumentasi dibaca pada path /v0.8.5/ yang dipatok versinya, dan status issue serta pull request dibaca pada 21 September 2026; beberapa issue tersebut ditandai sedang dalam proses dan dapat berubah. Tarif token Kunavo berasal dari katalog live, dan setiap angka dolar di sini adalah perhitungan token ilustratif, bukan biaya tugas yang diukur.