ZeroClaw bozuk bir akışı asla sürdürmez. Turu yeniden gönderip göndermeyeceği, profilinizde kaç aday bulunduğuna bağlıdır ve mevcut tek sürümde davranış belgelerin vaat ettiğiyle tam olarak örtüşmez. ZeroClaw'un v0.8.5 için 5 Eylül 2026'da yayımlanan belgeleri, herhangi bir çıktıdan önce başarısız olan bir akışın akışsız olarak yeniden denendiğini, çıktıdan sonra başarısız olanın ise asla yeniden oynatılmadığını söyler. 1 Ekim 2026'da akışı yanıtın ortasında kesen bir uç noktaya karşı çalıştırıldığında v0.8.5'in terminal istemcisi daha basit bir şey yaptı: tek adayla, metin görünmeden önce veya göründükten sonra hiçbir yeniden deneme göndermedi; ikinci adayla ise yanıtın bir bölümü ekranda göründükten sonra bile turu akışsız olarak ikinci modele yeniden gönderdi. Kısmi çıktıdan sonra rehberli kurtarma, henüz tasarım onayına ulaşmamış açık bir özellik isteğidir. Bu nedenle asıl yararlı soru ZeroClaw'un yeniden denemesini nasıl sağlayacağınız değil; turun sizin için yeniden gönderilmeye güvenli olup olmadığı ve başarısız denemenin zaten neye mal olduğudur.
Bunların herhangi birini uygulanabilir hâle getirmeden önce iki kapsam notu. Çalıştırılan şey dar kapsamlıydı: etkileşimli terminal modunda v0.8.5 sürüm ikilisi, OpenAI uyumlu tek bir uç nokta ve akışı kasıtlı olarak kapatan yerel bir test sunucusu — sonuçlar aşağıda. Kanallar, ağ geçidi WebSocket'i, RPC, ACP, Anthropic yuvası ve gerçek sağlayıcı kesintileri test edilmedi. Diğer tüm iddialar, 21 Eylül 2026 tarihinde sürüm etiketi v0.8.5'teki depodan, sürüme sabitlenmiş docs.zeroclaw.com/v0.8.5/ belgelerinden veya tarihli ana proje sorun raporlarından okunmuştur. Ayrıca bu URL'yi kendiniz sabitleyin: README okuyucuları /master/ yoluna yönlendiriyor; bu yolun HEAD sürümü, yayımlanan sürümden on altı gün ileridedir ve tam da bu konuda onunla çelişir. /latest/ ise 404 döndürüyor. Buradaki ZeroClaw, zeroclaw-labs/zeroclaw çalışma zamanını ifade eder; çalıştırdığınızın bu olduğundan emin değilseniz ZeroClaw ve OpenClaw karşılaştırması, onu aynı adı paylaşan proje ve çatallardan ayırır.
v0.8.5'te dört işaret ve bunlardan yalnızca biri ağdır
Herhangi bir karar vermeden önce gerçekten hangi işareti aldığınızı okuyun. ZeroClaw'ın v0.8.5'teki İngilizce yerel ayar dosyası, bunları kısa kesilen bir dönüşte asistan çıktısına eklenecek veya onunla kalıcılaştırılacak ve tüm taşıma katmanlarında — kanallar, WS, RPC, ACP ve CLI — son kullanıcılara gösterilecek farklı Fluent anahtarları olarak tanımlar.
| İşaret | Fluent anahtarı | Size ne anlatıyor |
|---|---|---|
[stream interrupted] | turn-stream-interrupted | Taşıma akışı dönüşün ortasında sonlandı. Kimse durdur düğmesine basmadı. |
[interrupted by user] | turn-interrupted-by-user | İnsan kaynaklı bir kesme. |
[turn cancelled via client] | turn-cancelled-client-rpc | Aktör değil, kanal. Kendi kod yorumu, insan kaynaklı kesmelerin ve programatik istemci iptallerinin her ikisinin de bu yola geldiğini söylüyor; bu nedenle ifade kanalı adlandırır. |
[interrupted by user before this tool produced a result] | turn-tool-interrupted-before-result | Bir araç yanıt vermeden önce kesildi. |
Aynı dosyada master üzerinde turn-failed = [turn failed] adlı beşinci bir anahtar bulunur, ancak v0.8.5'in yerel ayar dosyasında yoktur; dolayısıyla yayımlanmış bir derleme bunu üretmez. Sonrasında okuyabileceklerinizi değiştirdiği için bilinmesi gereken bir davranış: dönüş motoru, kısmi metin boş değilse yalnızca işareti eklenmiş kısmi metni kalıcılaştırır. Görünür metin üretmeden akıl yürütme veya sağlayıcı tarafında önceden yürütülmüş araç olayları üreten bir dönüş hiçbir şeyi kalıcılaştırmaz — kod yorumu, kalıcılaştırmayı tüketicinin zaten gördüğü şeyi kaydetmek olarak çerçeveler. Diğer yerel ayarlar aynı anahtarları çevrilmiş değerlerle taşır; dolayısıyla İngilizce değişmez köşeli parantez dizesi, İngilizce olmayan bir kurulumda gösterilen şey değildir.
Yeniden deneme sınırı gerçekte nerede bulunuyor
Tüm karar tek bir soruya indirgenir: herhangi bir şey değişmez bir olay havuzuna ulaştı mı?
| Ne oldu | v0.8.5'te belgelenen davranış | Uyarı |
|---|---|---|
| Herhangi bir görünür çıktıdan önce akış başarısız oluyor | Çalışma zamanı, tam güvenilirlik akışına yeniden girerek tüm çağrıyı akışsız yol üzerinden yeniden dener | Belgelenmiştir, ancak yayımlanmış derlemede tek adaylı bir kurulumun gözlemlediği şey bu değildir — aşağıya bakın |
| Akış, nihai metin ve araç çağrıları olmadan tamamlanıyor | Bir yanıt değil, anlamsal olarak boş bir yanıt. Sonuç yeniden oynatılabilir olarak işaretlendiğinde ve provider_retries sıfırdan büyük olduğunda, tam olarak aynı sağlayıcı ve modele gönderilen ve bir kez tüketilen bir akışsız kurtarma çağrısı | v0.8.5'te #10602 numaralı pull request aracılığıyla yayımlandı ve 4 Eylül 2026'da birleştirildi. Boş akışlar için geçerlidir; çıktının ortasında bozulan akışlar için değil |
| Metin, akıl yürütme veya önceden yürütülmüş araç olayları zaten değişmez bir olay havuzuna ulaştı | StreamInterruptedAfterOutput. Çalışma zamanı isteği yeniden oynatmaz ve tüketiciye zaten iletilmiş metin, kalıcılaştırılan kısmi asistan metninin tamamını oluşturur | Master üzerinde kasıtlı ve aynıdır. Görünür çıktıdan sonra oluşan akış hatasının, geri dönüş amaçlı yeniden deneme olmadan dönüşü başarısız kılması gerektiğini doğrulayan bir gerileme testiyle kilitlenmiştir |
| Yukarıdakilerden herhangi biri | Akış bir kez açılır ve başladıktan sonra girdiler değiştirilmez | Kurtarma her zaman yeni bir istektir. Özel yuva dâhil hiçbir sağlayıcı ailesi devam yolu almaz |
Mevcut ayarlar uç nokta başına değil, geneldir. [reliability] bölümü, belgelenen varsayılanı 2 olan provider_retries ayarını ve varsayılanı 500 olan provider_backoff_ms ayarını içerir; yaşam döngüsü belgesi, somutlaştırılan her girdinin en fazla provider_retries + 1 kez denendiğini belirtir. v0.8.5 yapılandırma referansı bunların yanında sağlayıcı veya takma ad başına bir yeniden deneme geçersiz kılma ayarı belgelemiyor. Anahtar havuzuna da güvenmeyin: v0.8.5 belgeleri, reliability.api_keys özelliğinin bugün çalışan bir yük devretme mekanizması olmadığını söylüyor; çünkü sarmalayıcı, yeniden denenebilir bir hız sınırından sonra alternatif anahtarı seçip günlüğe kaydediyor, ancak bunu oluşturulan sağlayıcıya uygulayamıyor; dolayısıyla yeniden deneme hâlâ özgün kimlik bilgilerini kullanıyor. Kurtarma bekleyerek eklediğiniz ikinci anahtar bunu sağlamaz.
Tek bir uç noktaya işaret etmek, zarar gören yapılandırmadır
Bu, ZeroClaw'ı tek bir ağ geçidine veya tek bir sağlayıcı uç noktasına karşı çalıştıran herkes için en keskin sınırdır; çünkü tek uç nokta, tanım gereği tek adaylı bir güvenilirlik yapılandırmasıdır. Issue #10736, yayımlanmış derlemede bu biçimdeki çıktı öncesi akış hatasının akışsız sohbete geri dönüşü günlüğe kaydettiğini, ardından bunu hiç göndermediğini ve dönüşü All model providers/models failed after 0 failure event(s) ile sonlandırdığını bildiriyor. 18 Eylül 2026'da — v0.8.5 yayımlandıktan sonra — kapatıldı; dolayısıyla düzeltme yalnızca master'da. 1 Ekim 2026'da çalıştırılan yayımlanmış v0.8.5, akış metin görünmeden veya göründükten sonra bozulsun, sorunun tarif ettiği gibi davrandı: bir istek, ardından bu hata.
Burada iki resmî konum birbiriyle çelişiyor ve ikisini de aktarmaya değer. v0.8.5 mimari belgesi akışsız yeniden denemeyi vaat ediyor; sorun, yayımlanmış derlemenin bunu gerçekleştirmediğini gösteriyor ve beklenen davranış bölümü, günlüğün geri dönüşü yalnızca gerçekten denenmesi durumunda iddia etmesini istiyor. Ardından master, sürümde bulunmayan tek adaylı bir kurtarma izni ekliyor — ve issue #10787, bu iznin RetryDecision::Admit(0) ile provider_retries değerinden bağımsız ve geri çekilme olmadan verildiğini; bu nedenle aşırı yüklenmiş bir upstream'in aynı yoğunluk penceresine hemen yeniden gönderildiğini söyledi. Bu sorun 26 Eylül 2026'da tamamlandı olarak kapatıldı — v0.8.5 sonrasında master üzerinde; dolayısıyla hiçbir sürümde yok. Master'ın davranışı hâlâ değişiyor; planınızı buna dayandırmayın.
Bir azaltmanın belgelenen biçimi bir ayar değil yapılandırmadır: güvenilirlik akışının ilerleyebileceği ikinci bir aday vermek. 1 Ekim 2026'da bu, terminalde v0.8.5 üzerinde çalıştı — ancak güvenmeden önce bilinmesi gereken bir koşulla: kurtarma isteği ilk modele değil ikinci modele gitti; yani kesintiden sonra aldığınız yanıt yedek modelinizden gelir. ZeroClaw API maliyeti ve kurulum kılavuzu, bu girdilerin yer aldığı yapılandırma biçimini kapsar.
Akış kesildiğinde v0.8.5 ne yaptı
1 Ekim 2026'da, sağlama toplamı sürümün SHA256SUMS dosyasına göre doğrulanan v0.8.5 sürüm ikilisi, akış kullanan mod olan etkileşimli terminal modunda geçici bir kapsayıcıda çalıştırıldı — tek mesajlık -m modu tek bir akışsız istek gönderir ve bu yola hiç ulaşmaz. Bir OpenAI uyumlu özel yuva profili olan provider_retries = 2, normal bir akışla yanıt veren ve bağlantıyı [DONE] göndermeden kapatan yerel bir test sunucusuna yönlendirildi; bu, ilk olaydan önce veya bir metin parçasından sonra gerçekleşti.
| Profil | Akışın bozulduğu yer | Gönderilen istekler | Terminalde gösterilen |
|---|---|---|---|
| Tek aday | Herhangi bir metinden önce | Bir akış isteği, yeniden deneme yok | Hata: Seçilen model sağlayıcısı başarısız oldu. Sağlayıcı yapılandırmasını gözden geçirin veya başka bir sağlayıcı seçin. Günlük: All model providers/models failed after 0 failure event(s) |
| Tek aday | Metin yazdırıldıktan sonra | Bir akış isteği, yeniden deneme yok | Kısmi metin, ardından aynı hata. [stream interrupted] işareti yazdırılmadı |
İkinci modelle birlikte fallback_models | Herhangi bir metinden önce | Akış isteği, ardından ikinci modele bir akışsız istek | İkinci modelin yanıtı |
İkinci modelle birlikte fallback_models | Metin yazdırıldıktan sonra | Aynı iki istek | Kısmi metin, ardından ikinci modelin tüm yanıtı — yani yanıt iki kez görünür |
v0.8.5'te ZeroClaw'ı terminalden çalıştıran herkes için üç sonuç var. Tek adaylı hata, yeniden üretilen #10736'dır; provider_retries bunu değiştirmedi. Belgelenen "görünür çıktıdan sonra yeniden oynatma yok" sınırı burada geçerli olmadı: terminalde zaten yazdırılmış metin yeniden göndermeyi durdurmadı; dolayısıyla yarım geldiğini gördüğünüz bir dönüş yine, farklı bir modele gönderilebilir. Ayrıca dönüş günlüğü ilk modeli dönüşün modeli olarak kaydederken metin ikinciden geldi; bu, v0.8.5'in kendi belgelerinin uyardığı ilişkilendirme boşluğudur. Bu çalışmanın kapsamadıkları: Telegram veya Slack gibi kanallar, ağ geçidi WebSocket'i, olay havuzları için yeniden oynatmama kuralının yazıldığı RPC ve ACP istemcileri, Anthropic yuvası, gerçek sağlayıcı kesintileri ve Kunavo üzerinden gönderilen herhangi bir istek.
Yeniden göndermeden önce: ne zaten çalıştı ve ne zaten ücretlendirildi
ZeroClaw'ın kendi araç döngüsü, akışı tamamlanana kadar okur, sona erdikten sonra araç çağrılarını kurtarır, bunları çalıştırır ve sonraki asistan dönüşü için yeni bir akış çağrısı açar. Dolayısıyla bozulan yinelemenin istediği araçlar çalıştırılmadı — ancak bu, göründüğünden daha sınırlı bir güvence. Sağlayıcı tarafında önceden yürütülmüş araç çağrıları, upstream'de zaten etkiler oluşturmuş ayrı bir olay sınıfıdır; yeniden oynatmayı engellemelerinin nedeni tam olarak budur. Uzun dönüşler geç bozulur: #10736, hatadan önceki araç çağrısının başarıyla tamamlandığını belirtiyor; #10787 günlüğü ise 126 mesajlık istekte kopmanın 2. yinelemede gerçekleştiğini gösteriyor. Özgün istemi yeniden göndermek, modelin tekrarlayacağı tüm önceki yan etkileri yeniden oynatır.
Temiz görünen bir döküm de kanıt değildir. Hem Anthropic hem de OpenAI uyumlu sağlayıcı ailelerine karşı p1 önceliğinde açık olan Issue #9421, tamamlanmamış terminal yanıtlarının başarılı olarak bildirilebileceği başlığını taşıyor. Code/ACP yüzeyinde iki ek açık p1 raporu, başarısız bir dönüşün kabul edilmiş istemleri ve tamamlanmış araç alışverişlerini kalıcı geçmişten silmesini (#10788) ve bütçesi aşılmış bir dönüşün oturum geri yüklendikten sonra görünür ilerlemeyi kaybetmesini (#10659) açıklıyor; kesintiye uğrayan dönüş ilerlemesini kalıcılaştırmayı amaçlayan pull request hâlâ birleştirilmedi. Bunların tümü 21 Eylül 2026'da açıktı ve birkaçı devam ediyor olarak işaretlenmişti; bu nedenle bu anlık görüntüyü alıntılamak yerine yeniden kontrol edin.
Maliyet konusunda v0.8.5 ile master gerçekten farklı bilgiler verir; kullandığınız derlemeyle eşleşen belgeyi okumalısınız. Sürümün belgesi, son kaydı her denemenin esas alınacak dökümü olarak değil, bir başarı bildirimi olarak tanımlar ve bu kayıttan deneme başına maliyetin doğruluğu hakkında çıkarım yapılmaması gerektiğini belirtir. master ise bu paragrafı, 18 Eylül 2026 tarihinde birleştirilen pull request #8966 ile eklenen deneme başına usage_by_provider dökümüyle değiştirir. Bu döküm hiçbir sürümde yer almaz ve master da bunun kapsamını olay izleme mekanizmalarıyla donatılmış tur yürütme yollarıyla sınırlar. Öte yandan, kesintiye uğrayan akışın kullanım anlık görüntüsü, bulunmayabilecek isteğe bağlı bir alandır ve ZeroClaw, OpenAI uyumlu uç noktalardan kullanım bilgisini son SSE parçasında ister; ancak yarıda kesilen bir akış bu parçayı hiç göndermeyebilir. Bu son noktayı ölçülmüş bir sonuç olarak değil, kendi maliyet çıktınızda kontrol etmeniz gereken bir mekanizma olarak ele alın. Bunun yerine uç noktanın kendi kullanım kaydıyla karşılaştırarak mutabakat sağlayın; Kunavo'da bu kayıt kullanım günlüğüdür.
Bir modelin önüne konan ağ geçidi neden bu işareti üretir
En olası üçüncü taraf nedeni, tamamlanma sinyalinin hiç ulaşmamasıdır. ZeroClaw'ın v0.8.5 akış belgeleri, taşıma katmanlarının başarı sinyali olarak bağlantının kapanmasına güvenmediğini belirtir: OpenAI uyumlu akışlar [DONE], OpenAI Responses akışları terminal yanıt olayında ve Anthropic akışları message_stop üzerinde tamamlanır; sunucular bu olaylardan sonra HTTP bağlantısını açık tutabilir. Sinyali olmadan kapanan bir akış, kısa bir başarı olarak değil, hata — SSE stream closed before {completion_signal}: response truncated — olarak yüzeye çıkar. Bu, ZeroClaw'a değil uç noktaya ait bir kusurdur. Belgelenmiş bir istisna vardır: Anthropic ayrıştırıcısı şu anda, message_stop olmadan da boş olmayan bir message_delta.stop_reason sonrasında EOF'u tamamlanmış olarak ele alır; bunu zorunlu kılmayı öneren pull request ise her iki referansta da henüz birleştirilmemiştir.
İkinci neden, açık bir soketteki sessizliktir. ZeroClaw, tüm istek için bir son tarih yerine bayt boşta kalma zaman aşımlarını kullanır; belgelenen süre OpenAI Responses ve OpenAI uyumlu sağlayıcılar için 300 saniye, Anthropic için 90 saniyedir ve her gövde okuması sayacı sıfırlar. Upstream yanıtını tamponlayıp bir buçuk dakika boyunca hiçbir şey iletmeyen bir uç nokta, Anthropic ailesi yuvasında zaman aşımına yol açarken OpenAI uyumlu yuvada zaman aşımına uğramaz — bunu bilmek önemlidir; çünkü bir Anthropic Messages uç noktası anthropic yuvasında uri geçersiz kılmasıyla kullanılır, custom yuvasında değil. İki API protokolü için Messages temel URL belgesine ve OpenAI uyumlu API sayfasına bakın.
Ölü bir dönüşün maliyeti, örnek hesapla
İki faturayı ayırın. ZeroClaw çalışma zamanının maliyeti 0 ABD dolarıdır — zeroclaw.com, bunun MIT VEYA Apache-2.0 çift lisanslı açık kaynak olduğunu, abonelik ve barındırılan koltuk bulunmadığını ve yalnızca kendi LLM sağlayıcınızın maliyetlerini ödediğinizi; Ollama ile yerel bir model çalıştırırken ise hiçbir şey ödemediğinizi belirtir. Katman olmadığı için hiçbir katman devam etmeyi, daha büyük bir yeniden deneme bütçesini veya yönlendirilmiş kurtarmayı açmaz.
Kesintinin etkilediği fatura model faturasıdır. Bu rakamlar ölçülmüş görev maliyeti veya fatura tavanı değil, varsayımlara dayalı token hesabıdır. Tek bir dönüşün 110.000 önbelleğe alınmamış giriş token'ı gönderdiğini — upstream'in isteği kabul edip ön doldurma çalıştırdıktan sonra isteği düşürdüğü, #10787'de kaydedilen tek tarihli aşırı yüklenme olayındaki istem boyutunu — ve akış ölmeden önce 2.000 çıkış token'ı aldığını varsayın. Üç denemelik sütun, belgelenen varsayılan 2 değerindeki provider_retries + 1'dir. Ücretler, milyon token başına Kunavo kataloğu güncel fiyatlarıdır.
| Model | 1 milyon başına giriş / çıkış | Başarısız bir deneme | Üç deneme |
|---|---|---|---|
| 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 |
Herhangi bir uç noktanın düşürdüğü bir istek için ücret alıp almadığı, o uç noktanın kendi faturalandırma politikasıdır; ZeroClaw kaynak veya belgelerinde bunu belirten hiçbir şey yoktur — bu sayfa hiçbir sağlayıcı için bunu ölçmedi. Hesap, soruyu yanıtlamak için değil, boyutunu anlamak için burada. Kunavo kataloğundaki tutar bir tavan değil, faturalandırma tabanıdır: upstream kendi ücretini bildirdiğinde fatura, katalog maliyeti ile upstream maliyetinin geçerli katsayıyla çarpımından büyük olanıdır. Minimum yükleme, görev ücreti veya abonelik değil, ön ödemeli kredide $10 tutarıdır — faturalandırma ayrıntılarına bakın.
Bu arızaya karşı hangi yol daha dayanıklı
| Yol | Akışın ortasında kopma olduğunda nasıl davranıyor | Nelerden vazgeçersiniz |
|---|---|---|
| Tek uç nokta, doğrudan sağlayıcı | Tek adaylı bir güvenilirlik yapılandırmasıdır; bu nedenle v0.8.5'te #10736'nın bildirdiği kümeye girer | Birinci taraf sağlayıcı olmak akışı değiştirmez; bir aday, bir adaydır |
| Tek uç nokta, ağ geçidi | Aynı tek adaylı biçim. Bir ağ geçidinin burada sağladığı şey, tek anahtar ve tek bakiye üzerinde model değiştirmektir; akış dayanıklılığı değil | Kendisi de tamamlanma sinyali olmadan kapanabilen ek bir sıçrama; ZeroClaw bunu yalnızca [cost.rates] girdilerini kendiniz yazarsanız fiyatlandırır |
| Profilde iki veya daha fazla aday | Güvenilirlik akışının ilerleyeceği bir yer vardır. 1 Ekim 2026'daki terminal çalıştırmasında hem erken hem de yanıt ortasındaki kopmadan sonra ikinci model üzerinden kurtarıldı | Bakımı yapılacak ikinci bir model veya takma ad ve ilk tercihinizden değil yedeğinizden gelen kurtarılmış bir yanıt |
| Ollama üzerinden yerel model | Yeniden gönderim para yerine zaman ve donanıma mal olur; bu nedenle temkinli bir yeniden deneme ucuzdur | Barındırılan öncü modeller karşısındaki yetenek açığı ve bunlardan birini çalıştıracak bir makine |
| Sabit ücretli abonelik aracısı | Hiçbir şekilde ZeroClaw yolu değil — projenin aboneliği ve barındırılan koltuğu yok | ZeroClaw'ın kurtarma davranışını değil, istemciyi değiştiriyor olurdunuz |
Hangisini seçerseniz seçin, işletim kuralı ZeroClaw'ın zaten kodladığı kuraldır: [stream interrupted]'dan sonra kalıcılaştırılmış kısmı okuyun, neyin zaten etkili olduğunu belirleyin ve ardından özgün istekten daha dar bir şeyi yeniden gönderin. OpenAI uyumlu ve Messages tarzı uç noktalar için Kunavo yapılandırma referansları uyumluluk testi değil, kurulum belgeleridir — yukarıdaki 1 Ekim çalıştırmasında Kunavo değil, yerel bir test sunucusu kullanıldı. Uç noktanızın döndürdüğü şeyi çözmek için hata referansından başlayın; bir anahtara para yatırmaya hazır olduğunuzda Kunavo hesabı oluşturun. OpenRouter vs LiteLLM, yukarıdaki tek adaylı-çok adaylı kararının en yakın karşılaştırmasıdır.
Sık sorulan sorular
ZeroClaw, kesintiye uğrayan bir akışı yeniden dener mi?
Bu tamamen çıktıyı daha önce görüp görmediğinize bağlıdır. Yayınlanan v0.8.5 için ZeroClaw'un sağlayıcı yönlendirme belgeleri, akışın bir kez açıldığını ve başladıktan sonra girdilerin değiştirilmediğini söyler; dolayısıyla hiçbir şey kaldığı yerden sürdürülmez — varsa kurtarma, tamamen yeni bir istektir. Akış, değişmez bir olay çıktısı görünür olmadan önce başarısız olursa, belgelenen davranış çalışma zamanının tüm çağrıyı akışsız yol üzerinden yeniden denemesidir. Metin, akıl yürütme veya önceden yürütülmüş araç olayları değişmez bir olay havuzuna ulaştığında kesinti StreamInterruptedAfterOutput olur ve çalışma zamanı isteği yeniden oynatmaz. İkinci kural master'da da aynıdır. Ancak 1 Ekim 2026'da v0.8.5'in etkileşimli terminal istemcisinde yapılan çalıştırmada iki kural da yazıldığı gibi ortaya çıkmadı: tek adayla, metin görünmeden önce de göründükten sonra da hiçbir şey yeniden denenmedi; fallback_models içindeki ikinci adayla ise her iki durumda da, yanıtın bir bölümü yazdırıldıktan sonra bile tur akışsız olarak ikinci modele yeniden gönderildi. Channels ve ağ geçidi WebSocket'i çalıştırılmadı. Belgeler 21 Eylül 2026'da kontrol edildi.
ZeroClaw'da [stream interrupted] ne anlama gelir?
Bu, tur ortasında kesilen bir taşıma akışı için kullanıcıya görünen işarettir; ZeroClaw'un İngilizce yerel ayar dosyasında turn-stream-interrupted Fluent anahtarı olarak tanımlanır ve tüm taşıma yollarında — kanallar, WS, RPC, ACP ve CLI — gösterilir. Bilerek [interrupted by user] ve [turn cancelled via client] işaretlerinden farklıdır; dolayısıyla bunu görmeniz durdur düğmesine kimsenin basmadığını gösterir. Akış görünür çıktıdan sonra kesilirse, kısmi metin yalnızca boş olmadığı durumda, sonuna işaret eklenmiş bir asistan mesajı olarak kalıcı olarak kaydedilir: yalnızca akıl yürütme veya yalnızca önceden yürütülmüş araç olayları üreten bir turda hiçbir şey kalıcı olarak kaydedilmez. İngilizce olmayan kurulumlarda aynı anahtarın metni çevrilmiştir; bu nedenle böyle bir kurulumda İngilizce köşeli parantezli dizeyi aramayın. 21 Eylül 2026'da v0.8.5 sürüm etiketinde okundu. 1 Ekim 2026'da v0.8.5'in etkileşimli terminal istemcisinde, yanıt ortasında kesilen bir akış bu işareti yazdırmadı; terminal bunun yerine bir sağlayıcı hatası gösterdi.
ZeroClaw akış kesintisinden sonra istemi yeniden göndermek güvenli midir?
Otomatik olarak güvenli değildir ve ZeroClaw'un kendi geliştiricileri de bunu bu şekilde ele alır. Çalışma zamanı bir akışı tamamlanana kadar okur, sona erdikten sonra araç çağrılarını kurtarır ve ardından çalıştırır — yani kesilen yinelemenin araçları henüz çalıştırılmamıştır. Ancak uzun bir tur sonraki yinelemelerde de kesilebilir: bir üst akış raporu, önceki araç çağrısının hata oluşmadan önce başarıyla tamamlandığını belirtir; başka bir raporun günlüğü ise kesintinin istekte 126 mesaj varken 2. yinelemede gerçekleştiğini gösterir. Önceki bir yinelemenin yaptığı her şey — yazılan dosya, çalıştırılan komut veya gönderilen mesaj — aynı istemi körlemesine yeniden gönderirseniz tekrar gerçekleşir. Rehberli kurtarma için açık özellik isteği, hedef dışı işlemler arasında araç veya onay içeren bir turun körlemesine yeniden oynatılmasını ve her sağlayıcı hatasının geçici kabul edilmesini sayar. Önce kalıcılaştırılmış kısmi metni okuyun, hangi işlemlerin zaten etkili olduğunu kontrol edin, ardından orijinal yerine daraltılmış bir istemi yeniden gönderin.
ZeroClaw'u bozuk akışı sürdürmek üzere yapılandırabilir miyim?
Hayır. Yayımlanmış hiçbir sürümde bunun için bir ayar yoktur ve böyle bir ayarı açan ücretli bir seviye de bulunmaz — ZeroClaw ücretsiz ve açık kaynaklıdır, MIT OR Apache-2.0 çift lisansına sahiptir; abonelik veya barındırılan hizmette kullanıcı koltuğu yoktur. Dolayısıyla sınır, plan sınırından ziyade mühendislik sınırıdır. Görünür çıktıdan sonra yeniden oynatmama kuralı kaynak kodundadır ve kendi hata mesajı, görünür çıktıdan sonraki bir akış hatasının alternatif bir yol üzerinden yeniden deneme olmadan turu başarısız kılması gerektiğini belirten bir regresyon testiyle güvence altına alınmıştır — ancak 1 Ekim 2026'da v0.8.5'in etkileşimli terminal istemcisinde ikinci adaya sahip bir profil, metin yazdırıldıktan sonra yeniden gönderim yaptı; bu nedenle kural her taşıma için garanti değildir. Kesintiye uğramış bir turun ardından rehberli kurtarma, #10634 numaralı sorun kaydında ele alınmaktadır; bu kayıt 21 Eylül 2026 itibarıyla açıktır, status:accepted ve priority:p2 etiketlerine sahiptir ve önce tasarım veya RFC görüşmesi yapılması için yönlendirilmiştir. Accepted, sorunun tanımının triyaj tarafından kabul edildiği anlamına gelir; kodun yazıldığı veya birleştirildiği anlamına gelmez.
Günlüğüm, akışsız sohbete geri dönüldüğünü ve ardından turun öldüğünü söylüyor. Neden?
Yayımlanan v0.8.5'te bu günlük satırı gerçeği yansıtmayabilir. Ana projenin #10736 numaralı sorun kaydının başlığı, çıktı verilmeden önceki bir akış hatasının belirtilen akışsız geri dönüşü atladığını söyler. Kayıt, çalışma zamanının akışsız sohbete geri dönüldüğünü günlüğe yazdığını, ancak akışsız isteği göndermediğini ve turun All model providers/models failed after 0 failure event(s) ile hemen sona erdiğini bildirir. Kaydın kendi etki açıklaması, etkilenen grubu tek bir sağlayıcı adayına sahip kullanıcılar, özellikle de sıfır yeniden denemeli yapılandırmalar olarak belirtir. Sıfır yeniden deneme tek durum değildir: sorunu yeniden üretmek için provider_retries = 0 ayarlanmıştır, ancak devam niteliğindeki #10787 numaralı sorun kaydı, provider_retries belgelenen varsayılan değer olan 2'de bırakıldığında da aynı ani hatayı yeniden üretir. Sorun kaydı, v0.8.5'in 5 Eylül'de yayımlanmasından sonra 18 Eylül 2026'da kapatıldı; dolayısıyla yayımlanmış hiçbir sürüm düzeltmeyi içermez. Sorun, 1 Ekim 2026'da v0.8.5'te yeniden üretildi: tek bir akış isteği, akışsız takip isteği yok ve aynı hata — provider_retries = 2 ile, akışın metin görünmeden önce veya sonra kesilmesinden bağımsız olarak. fallback_models altında ikinci bir model eklemek turun kurtulması için yeterliydi. v0.8.5'te bunu günlüklerden hata ayıklamak, gerçekleşmemiş bir geri dönüşü okumak anlamına gelir.
Kesintiye uğrayan tur için ücretlendirildim mi ve nasıl kontrol ederim?
ZeroClaw'un kendi kaydı yerine uç noktanın kullanım kaydını kontrol edin; çünkü v0.8.5 belgeleri, deneme başına rakamına güvenmemenizi söyler: son geri dönüş bildirimini her denemenin kanonik defteri olarak değil, başarı bildirimi olarak açıklar ve deneme başına maliyet doğruluğunun bundan çıkarılmaması gerektiğini belirtir. Bunu çözen deneme başına usage_by_provider defteri, v0.8.5 yayımlandıktan sonra 18 Eylül 2026'da birleştirilen #8966 numaralı pull request aracılığıyla master'a geldi; dolayısıyla hiçbir sürümde bulunmaz ve master bunu olay enstrümantasyonu yapılmış tur yollarıyla sınırlar. ZeroClaw, kesintiye uğramış bir akışta kullanım anlık görüntüsünü alır, ancak alan isteğe bağlıdır ve bulunmayabilir; ayrıca OpenAI uyumlu uç noktalardan kullanımı son bir SSE parçasında ister — kesilmiş bir akışın hiç teslim etmeyebileceği parçada. Bu son nokta çalışma zamanında gözlemlenmiş değil, kaynak kodundan okunmuştur. Ayrı olarak, ZeroClaw'un kendi maliyet rakamları yapılandırmanızdaki operatör tarafından yazılmış [cost.rates] oran tablolarından gelir; dolayısıyla orada fiyatlandırmadığınız bir uç nokta ZeroClaw tarafından da fiyatlandırılmaz.
1 Ekim 2026'da çalıştırıldı: akışı kesen yerel bir test sunucusuna karşı etkileşimli terminal modundaki v0.8.5 sürüm ikilisi — sonuç tablosunun dört satırı; başka hiçbir şey çalıştırılmadı ve Kunavo'ya hiçbir istek gitmedi. Sorun durumları aynı gün yeniden kontrol edildi (#10787 o zamandan beri kapandı; #10634 hâlâ açık). Depo kaynağı sürüm etiketi v0.8.5'te, belgeler sürüme sabitlenmiş /v0.8.5/ yolunda ve sorun ile pull request durumları 21 Eylül 2026'da okundu; bu sorunların birkaçı devam ediyor olarak işaretlenmişti ve değişebilir. Kunavo token ücretleri güncel katalogdan gelir ve buradaki her dolar tutarı ölçülmüş görev maliyeti değil, örnek token hesabıdır.