Kılavuzlara dön
Kurulum·21 Eylül 2026·Son güncelleme: 24 Eylül 2026·9 dk okuma

Nanobot sonsuz döngüleri ve token kullanımı: sınırlandırılmış bir Dream çalışmasını teşhis etme

Hata başlığının işaret ettiği ayar silindi, onu geri getirecek pull request birleştirilmeden kapatıldı ve geriye kalan tek sınır işlem genelindedir.

Son inceleme tarihi: .

Sonsuz döngü gibi görünen bir nanobot çalıştırması sınırlı bir çalıştırmadır: gönderilen v0.3.5 kaynak kodunda her agent turu, varsayılanı 200 olan agents.defaults.maxToolIterations tarafından sınırlandırılır ve bir bakımcı bunun kelimenin tam anlamıyla sonsuz bir döngü olmadığını açıkça belirtir. Asıl sorun belirteç kullanımıdır; çünkü bu sınıra ulaşan bir çalıştırma 201 asistan turunu günlüğe kaydeder ve her seferinde büyüyen bir istemi yeniden gönderir. Hangisine sahip olduğunuzu belirlemek dört soruluk bir teşhistir ve kanıta dayanan düzeltme bir yapılandırma değeri değildir.

Önce bariz ipucunu eleyin. Üst sistem bildirimi, başlığı dream.maxIterations olan issue #5781'dir; PR #5782 ise "fix(dream): enforce configured iteration limit" başlığını taşır. Bu anahtar v0.3.5'te mevcut değildir ve PR 16 Eylül 2026'da birleştirilmeden kapatılmıştır. Buna dayanan bir eğitim hiçbir şeyi yapılandırmaz.

Bir ayrım daha: sorgu yanlış takip sistemini öne çıkarıyor. Bu sayfa, MIT lisanslı HKUDS/nanobot projesiyle ve PyPI paketi nanobot-ai ile ilgilidir — 0.3.5, Python 3.11 veya daha yeni, 15 Eylül 2026'da yüklenmiştir. obot-platform/nanobot, README'si bakım modunu ve devre dışı bırakılmış issue'ları belirten farklı bir Go projesidir; onun issue numaraları burada kanıt değildir. Soneksiz pip install nanobot, ilgisiz bir robot navigasyon paketi yükler.

Ne bildirildi ve hangi sürüm için

Dream, nanobot'un ağ geçidi tarafından dream adlı bir cron görevi olarak çalıştırılan zamanlanmış bellek birleştirme işidir. Bu bir embedding veya vektör dizini işi değildir: Kunavo hiçbir embedding modeli sunmaz ve Dream'in buna ihtiyacı yoktur; çünkü nanobot'un kalıcı belleği çalışma alanı altında düz dosyalardır ve Dream çalıştırması sıradan sohbet trafiğidir.

#5781 numaralı issue, 15 Eylül 2026'da BrianMwangi21 tarafından Python 3.12 üzerinde, OpenRouter üzerinden ulaşılan bir reasoning modeliyle nanobot v0.3.0 hakkında açıldı. Belirti şuydu: Dream görevi read_file çağrısını memory/history.jsonl dosyası üzerinde çalıştırıyor, ardından tek bir SKILL.md dosyası üzerinde read_file çağrısını çalıştırıyordu; bu iki çağrı düzinelerce kez dönüşümlü olarak tekrarlanırken reasoning izi tek bir küçük gerçeğin nereye yazılacağını yeniden değerlendiriyordu. Yaklaşık 26 saat boyunca günlüğe alınan yedi çalıştırma yaklaşık 25 dakika ile yaklaşık 111 dakika arasında sürdü; yaklaşık 200 araç çağrısı yapanlar genel sınıra ulaşıyordu ve bir oturum kontrol noktası aynı read_file çağrısında runtime_checkpoint.iteration: 164, aşama tools_completed gösteriyordu.

Bu sayılarla birlikte üç kapsam sınırı da dikkate alınmalıdır. Bunlar tek bir kullanıcının kendisinin bildirdiği, tek bir modelle ve v0.3.0 üzerinde elde ettiği ağ geçidi günlükleridir — hiçbir bakımcı bunları yeniden üretmemiş ve hiç kimse v0.3.5 üzerinde yeniden test etmemiştir. Issue enhancement ve priority: p2 olarak etiketlenmiştir, bug olarak değil ve hâlâ açıktır. Ayrıca bu biçim daha önce de görülmüştür: 12 Nisan 2026 tarihli, history.jsonl üzerindeki neredeyse aynı read_file döngüsünü bildiren issue #3073, not planned olarak kapatılmıştır. Bunların hiçbiri nanobot'u genel olarak pahalı kabul etmeyi desteklemez; kendi kurulumunuzun bunu yapıp yapmadığını kontrol etmenizi destekler.

Kullanımdan kaldırılan anahtar ve gerçekten etkin sınır

Tüm karışıklık bir sürüm farkından kaynaklanır ve kaynak kodu bunu kesinleştirir. İki yayın etiketi 21 Eylül 2026'da okundu:

Yapılandırma anahtarıv0.3.0'dav0.3.5'teŞimdi ne yapmalı
dream.maxIterationsVarsayılan 15, # Deprecated: no longer used olarak işaretliŞemadan kaldırıldıYazmayın; hiçbir şeyi yapılandırmaz
dream.maxBatchSizeVarsayılan 20, aynı kullanımdan kaldırma yorumuKaldırıldıYazmayın
dream.annotateLineAgesVarsayılan true, aynı kullanımdan kaldırma yorumuKaldırıldıYazmayın
dream.enabledVarsayılan trueVarsayılan trueWebUI çalışma zamanı ayarlarında düzenlenebilir
dream.intervalHVarsayılan 2Varsayılan 2config.json değerini düzenleyin; WebUI yaprağı değildir
dream.cronNull; eski geçersiz kılmaNull; eski geçersiz kılmaAyarlanmışsa intervalH değerine göre önceliklidir
dream.modelOverrideTanımlı, pending implementation olarak yorumlanmışUygulandıYalnızca ön ayar adları, hiçbir zaman ham model kimliği değil
agents.defaults.maxToolIterations200200Tek sınırdır ve süreç genelinde geçerlidir

Bu tabloda hata yapmayı kolaylaştıran iki nokta var. 200 değeri iki açıdan da doğru — hem sorunu bildiren kişinin yapılandırmasındaki değer hem de nanobot/config/schema.py dosyasının 129. satırında yer alan, yazılımla birlikte gelen varsayılan değer; v0.3.5 etiketinde ve main üzerinde aynı olduğundan, bu değeri hiç ayarlamamış bir okuyucu için de değer 200'dür. Ayrıca bu değer belgelenmemiştir: nanobot'un kendi 0.3.5 yapılandırma başvuru belgesi 21 Eylül 2026 tarihinde getirildiğinde, içinde tek bir maxToolIterations bile geçmeyen 488.608 baytlık HTML döndürmüştür; deponun bu etiketteki docs/configuration.md dosyasında da hiç geçmemektedir. Bu sayı bir dokümantasyon sayfasından değil, kaynak koddan ve bir proje bakımcısının yorumundan doğrulanabilir — dolayısıyla farklı bir rakam veren herhangi bir öğreticiye şüpheyle yaklaşın.

modelOverride sürüm koşuluna sahip tek çözümdür. v0.3.0'da alan, pending implementation yorumuyla mevcut olmasına rağmen bunu çözen hiçbir kod yoktu; 27 Temmuz 2026'da birleştirilen PR #5107, bunu v0.3.5 için uyguladı. Resmî 0.3.5 bellek sayfası, bunun Dream için model_presets içinden adlandırılmış bir giriş seçtiğini, yalnızca ön ayar adlarını kabul ettiğini ve ham model tanımlayıcılarının desteklenmediğini belirtir. Bu sayfa üç Dream anahtarını belgeler ve hiçbir yerde yineleme sınırından söz etmez. İşte dayandığı providers bloğunun nanobot kurulum sayfasında ele alındığı, mevcut yüzeyin tamamı:

~/.nanobot/config.json — v0.3.5 Dream yüzeyinin tamamı
{
  "modelPresets": {
    "dream-cheap": {
      "provider": "kunavo",
      "model": "claude-haiku-4-5",
      "maxTokens": 8192
    }
  },
  "agents": {
    "defaults": {
      "maxToolIterations": 200,
      "dream": {
        "enabled": true,
        "intervalH": 2,
        "modelOverride": "dream-cheap"
      }
    }
  }
}

Bu dosyada olmayan şeye dikkat edin: Dream'i tek başına sınırlandırmanın herhangi bir yolu yoktur. AgentLoop, süreç varsayılanlarından alınan max_iterations ile bir kez oluşturulur ve hem Dream cron yolu hem de manuel /dream yolu, alt aracılar gibi, process_direct(...) çağrısını yineleme argümanı olmadan yapar. Sınırı düşürmek, onu sohbet, Dream, heartbeat ve alt aracılar için birlikte düşürür.

Bu sırayla teşhis edin

Bir şeyi değiştirmeden önce bu dört soruyu yanıtlayın; çünkü üçünün maliyeti yoktur ve dördüncüsü ilk üçünün önemli olup olmadığını gösterir. Günlük dizeleri v0.3.5'teki gerçek metindir; süslü parantezler çalışma zamanı değerleridir.

SoruNereye bakmalıYanıt ne anlama gelir
1. Çalıştırma kendi kendine mi durdu, yoksa tavana mı ulaştı?Ağ geçidi günlüğü: Max iterations (200) reached, kaynak: agent/loop.pyVarsa bu, sınırlandırılmış bir çalıştırma ve yaklaşık 201 asistan turu anlamına gelir. Yoksa çalıştırma tavana ulaşmadan sona ermiştir — model yakınsamış olabilir veya çalıştırma tamamen başarısız olup Dream cron job failed günlüğünü yazmış olabilir
2. Dream imleci ilerledi mi?cli/gateway_runtime.py içinde üç ayrı satır: Dream cron job completed, cursor advanced to …; … completed with no memory changes; cursor advanced to …; Dream cron job did not complete (…); cursor remains at …Üçüncü satır, v0.3.5 güvenlik mekanizmasının çalıştığını gösterir: tamamlanmamış bir çalıştırma, partinin yeniden denenmek üzere bırakılmasına neden olur. Bu aynı zamanda aynı partinin bir sonraki tikte yeniden gelmesi anlamına gelir
3. Aynı araç, aynı bağımsız değişkenlerle tekrarlanıyor mu?Bu iki işaret arasındaki Tool call: satırlarıAynı araç ve bağımsız değişkenlerin tekrar tekrar kullanılması, üst akışın vardığı sonuç olan model yakınsamamasıdır. v0.3.5'teki tek tekrar koruması web_fetch ve web_search ile eşleşir; tekrarlanan bir read_file yakalanmaz
4. Maliyeti ne oldu?Yapılandırma dizinindeki llm_usage.sqlite3, tarih ve kaynağa göre toplulaştırılmış olarak; ağ geçidi tarafında ise usage içinde anahtar ve gün başınaDream, dream olarak etiketlenir. Heartbeat ise cron olarak etiketlenir; bu nedenle "heartbeat" filtresi hiçbir sonuç bulmaz

Bunu yeniden üretmek için cron tikini iki saat beklemeniz gerekmez. /dream komutu aynı işi isteğe bağlı olarak çalıştırır ve sohbette aynı ayrımı bildirir: başarı durumunda Dream completed in Ns. veya Dream completed in Ns; no memory changes., tamamlanmadığında ise Dream did not complete after Ns (reason); memory cursor was not advanced.. Kanıt ararken önemli olan bir başka v0.3.5 değişikliği daha var: oturum JSONL dosyaları yapılandırma dizininin sessions/<workspace-id>/ ağacına taşındı; dolayısıyla sorun başlığında alıntılanan v0.3.0 yolları kontrol noktanızın bulunduğu yer değildir.

Beş kaldıraç ve her birinin gerçekte dayandığı kanıt

KaldıraçArkasındaki kanıtŞu durumda avantajlıdırBunun size maliyeti
v0.3.0'ı v0.3.5'e yükseltinv0.3.5'te bulunan, v0.3.0'da bulunmayan 4e2640f commit'i, imleci yalnızca durma nedeni completed olduğunda ilerletirBelirtiniz harcama yerine belleğin atlanmasıYakınsamayan bir döngüyü kısaltmaz ve hiç kimse #5781'i 0.3.5 üzerinde yeniden test etmedi
Dream modelini değiştirinÖncesi ve sonrası bulunan tek çözüm budur: raporlayanın denetiminde, bir modelin tamamlamadan 91 dakika harcadığı bir parti, aynı istem, aynı geçmiş ve aynı araçlarla farklı bir modelde sonraki çalıştırmada yaklaşık bir dakikada ve 6 araç çağrısıyla tamamlandıSohbet kalitesi pahalı modelinizde kalmalıv0.3.5 ve tanımlı bir ön ayar gerektirir; v0.3.0'da alan hiçbir şeye çözümlenmez
maxToolIterations'ı düşürünWebUI çalışma zamanı ayarlarında düzenlenebilir; minimum 1, webui/settings_runtime.py başınaTeşhis sırasında bir en kötü durum üst sınırı istiyorsunuzSohbet, Dream, heartbeat ve alt aracılar için tek bir ayar; ayrıca sınırlandırılmış bir çalıştırma imleci ilerletmez, bu nedenle aynı parti bir sonraki tikte yeniden denenir
Dream'i yavaşlatın veya devre dışı bırakınWebUI'de intervalH veya dream.enabled; birleştirilen PR #5407, devre dışı bırakıldığında kalıcı işi sonlandırırİş yükünüzde birleştirme maliyetine değmezÖzellik olan bellek birleştirmesini kaybedersiniz
Yeniden gönderimi daha ucuz olacak şekilde yönlendirinv0.3.5'te tam olarak iki sağlayıcı spesifikasyonu supports_prompt_caching alanını ayarlar: anthropic ve openrouter; alan varsayılan olarak false değerindedirUzun çalıştırmaların gerçekleşmesini kabul ediyor ve daha ucuza mal olmalarını istiyorsunuzYapılandırdığınız protokol yoluna ve döndürülen kullanımı kendiniz doğrulamanıza bağlıdır

Raporlayanın iki model kimliği, OpenRouter üzerinden yazdığı şekliyle deepseek/deepseek-v4-flash-0731 ve openai/gpt-5.6-luna idi; bu kimlikler ve fiyatları burada kontrol edilmedi, dolayısıyla karşılaştırmayı modellerin yakınsamayı belirlediğine dair kanıt olarak okuyun, ikisinden birine yönelik öneri olarak değil. Üst akış da aynı sonuca ulaştı: issue #5781 üzerindeki PR #5782'nin kapatıldığını duyururken chengyongru, sabit bir Dream iterasyon sınırının model bağımlı temel yakınsama sorununu çözmediğini ve aksi halde uygulanabilir çalıştırmaların tekrar tekrar denenmesine neden olabileceğini yazdı.

Sınırlandırılmış bir çalıştırmanın maliyeti: açıklayıcı aritmetik

Bunlar açıklayıcı token aritmetiğidir; ölçülmüş bir görev maliyeti veya fatura üst sınırı değildir. nanobot, Dream için çalıştırma başına token rakamı yayımlamadığından buradaki her girdi bir varsayımdır ve kendi ölçümünüzle değiştirilmelidir. Raporlayanın denetimindeki sayı olan 201 asistan dönüşünde sınıra ulaşan ve her seferinde istemi sabit 25.000 token olarak yeniden gönderen tek bir çalıştırma varsayın; bu, kendi çalışma alanını nasıl tanımladığıdır, yayımlanmış bir rakam değildir. Bu 5,03M girdi token'ı eder. Çıktı token'ları dahil değildir ve gerçek bir istem her araç sonucuyla büyür; dolayısıyla bu, gerçek bir çalıştırmayı aynı anda iki yönde olduğundan düşük tahmin eder. Fiyatlar güncel Kunavo kataloğu fiyatlarıdır.

Model1M başına girdi1M başına önbellek okumaÖnbelleksiz, tek bir sınırlandırılmış çalıştırmaAynı çalıştırma, yeniden gönderimler önbellekten okunuyor
Claude Haiku 4.5$0,70$0,07$3,52$0,37
GPT-5.6 Terra$0,70$0,07$3,52$0,37
Claude Sonnet 5$1,40$0,14$7,04$0,74

Son sütun, burada test edilmeyen bir en iyi durum varsayar: ilk gönderim normal girdi fiyatından ve tüm 200 yeniden gönderimler önbellek okumaları olarak sunulur. Önbellek yazma kendi fiyatından ücretlendirilir; bazı modellerde bu fiyat normal girdi fiyatından yüksektir; bir önbellek girdisi sona erer ve büyüyen bir istem yeniden okunmak yerine yeniden yazılır. Bu nedenle son iki sütun arasındaki farkı bir fiyat teklifi olarak değil, kazanılabilecek miktarın büyüklüğü olarak değerlendirin. Buradaki tek nokta, uzun ve tekrarlı bir çalıştırmada paranın modelden değil yeniden gönderimden gittiğidir.

Önbellek işaretlerinin ağa ulaşıp ulaşmaması tamamen nanobot yapılandırmanızda belirlenir ve gönderilen kaynak kodda görülebilir. providers altında uydurulmuş bir sağlayıcı anahtarı, düz bir OpenAI uyumlu sağlayıcı olarak değerlendirilir ve supports_prompt_caching ayarını varsayılan false değerinde bırakır; bu nedenle nanobot istemcisi, Claude biçimli bir model kimliği için bile bu yolda cache_control işaretleri göndermez. Ön ayarı yerleşik anthropic sağlayıcısında tutup providers.anthropic.apiBase ayarını geçersiz kılmak, bunları etkin tutar. Bu, nanobot istemcisinin gönderdiği şey hakkındadır; herhangi bir uç noktanın kendi tarafında ne yaptığı hakkında değildir ve Kunavo nanobot'u çalışma zamanında test etmemiştir. Yinelenen bir işi önbelleğe alınmış olarak bütçelemeden önce gerçek bir çağrının döndürdüğü kullanımı okuyun — önbellekleme belgesi çalışan bir önbelleğin nasıl göründüğünü ve temel URL referansı her iki uç nokta kuralını gösterir.

Kunavo kataloğundaki tutar, üst sınır değil faturalandırma tabanıdır: üst akış kendi ücretini bildirdiğinde fatura, katalog maliyeti ile üst akış maliyetinin geçerli kâr oranıyla çarpımından büyük olanıdır. Minimum yükleme ön ödemeli kredide 10$ — bir finansman minimumudur; görev ücreti veya abonelik değildir. Faturalandırma ayrıntılarına ve yukarıdaki varsayımların yerini alan ölçüm yöntemi için maliyet optimizasyonuna bakın.

Düzeltmeyi tek bir çalıştırmada doğrulayın

Tek bir şeyi değiştirin, ardından zamanlamayı beklemek yerine /dream komutunu bir kez çalıştırın ve üç işareti sırayla kontrol edin: Max iterations (200) reached uyarısının bulunmaması, cursor advanced to … satırının görünmesi ve bunun cursor remains at … olmaması, ayrıca arada makul bir araç çağrısı sayısı. Ardından kendi hesabınızın bu zaman aralığı için kaydettiği ücreti anahtar ve gün başına usage içinde okuyun; nanobot'un deposu parayı değil token'ları sayar. Uç noktayı ilk kez yapılandırıyorsanız hızlı başlangıç ve nanobot kurulum sayfası her iki protokol yolunu kapsar; Kunavo hesabı oluşturmak ise bir anahtara fon sağlamadan önceki adımdır. Çalışma sürelerini mi karşılaştırıyorsunuz? nanobot ve OpenClaw iki arka plan sıklığını yan yana koyar ve agent API dizini istemcileri iletişim protokolüne göre indeksler.

Sık sorulan sorular

nanobot gerçekten sonsuz bir döngüde mi takılıyor?

Hayır; bir bakımcı da bunu açıkça söylüyor. chengyongru, 10 Ağustos 2026'da #5324 numaralı issue hakkındaki yorumunda nanobot'un aracı çalıştırıcısının varsayılan olarak 200 olan agents.defaults.maxToolIterations ile sınırlandığını yazdı; dolayısıyla bu kelimenin tam anlamıyla sonsuz bir döngü değildir — ancak uzun ve sınırlı bir döngünün toplam belirteç kullanımını yine de çok yükseltebileceğini, yani pratik etkinin gerçek olduğunu ekledi. Gönderilen v0.3.5 kaynak kodu da bunu doğrular: nanobot/config/schema.py içinde max_tool_iterations varsayılanı 200'dür ve agent/loop.py bir çalıştırma bu sınıra ulaştığında "Max iterations (200) reached" uyarısını günlüğe yazar. İnsanların sonsuz döngü dediği şey bu tavana ulaşan bir çalıştırmadır; bir bildiricinin günlüklerinde bu, aynı iki dosyanın yeniden okunmasıyla sonuçlanan 201 asistan turu anlamına gelmiştir.

dream.maxIterations ayarlamak neden hiçbir şey yapmıyor?

Çünkü bu alan artık mevcut değil. nanobot v0.3.0'da Dream yapılandırmasında max_iterations, max_batch_size ve annotate_line_ages alanları bulunuyordu ve kaynakta her biri "Deprecated: no longer used" yorumuyla işaretlenmişti; v0.3.5 etiketinde üçünün de tümüyle kaldırıldığı ve sınıfın yalnızca enabled, intervalH, cron ve modelOverride tanımladığı görülür. Bakımcı chengyongru, 15 Eylül 2026'da Dream normal agent loop üzerine taşındığında dream.maxIterations'ın kasıtlı olarak kullanımdan kaldırılmış ve kullanılmıyor olarak işaretlendiğini, sonrasında da main'den kaldırıldığını belirtti. Bunu geri getirecek pull request #5782 ertesi gün birleştirilmeden kapatıldı. Bu anahtarı v0.3.5 yapılandırmasına yazmak, şemada tanımlanmayan bir anahtar yazmak demektir.

Yalnızca nanobot Dream görevi için belirteçleri nasıl sınırlarım?

nanobot v0.3.5'te bunu kümülatif bütçe olarak yapamazsınız. Dağıtılan kodun hiçbir yerinde bir çalıştırmanın belirteçleri toplanıp belirli bir rakama ulaşıldığında çalıştırma durdurulmaz; tek yineleme sınırı agents.defaults.maxToolIterations'dır ve süreç genelinde uygulanır: normal sohbet turları, Dream, heartbeat ve alt aracılar için aynı sınır ayarı geçerlidir. agents.defaults.dream.modelOverride üzerinden iki şeyi yalnızca Dream için ayarlayabilirsiniz: modeli ve bu ön ayarın çağrı başına kendi limitlerini; çünkü ModelPresetConfig maxTokens ve contextWindowTokens içerir ve dream_runtime() adlandırılmış ön ayarı Dream çalıştırmasının kullanacağı çalışma zamanına çözümler. Bunlar çalıştırmanın toplamını değil, her bir çağrıyı sınırlar; dolayısıyla düşük maxTokens ile yapılan 200 çağrı hâlâ 200 çağrıdır. Zamanlama da intervalH üzerinden Dream'e özel olarak ayarlanabilir. Kümülatif bütçe, projenin bakımcılarının şimdilik eklemeyi reddettiği şeydir: chengyongru, 16 Eylül 2026'da, yani PR #5782'yi kapattığı gün, #5781 numaralı issue'da arka plan görevleri için bir belirteç veya kaynak bütçesinin bütçe birimi ve kapsamı, sonlandırma semantiği, yeniden deneme ve imleç davranışı, gözlemlenebilirlik ve farklı modellerle etkileşimi kapsayan daha ayrıntılı bir tasarıma ihtiyaç duyduğunu ve şimdilik bunu ilerletmeyi planlamadıklarını yazdı.

Hâlihazırda çalışan bir nanobot Dream çalıştırmasını nasıl durdururum?

v0.3.5 kaynak kodunun okunmasına göre /stop ile durduramazsınız. /stop, bu sohbet için etkin agent turunu iptal etmek olarak belgelenmiştir ve bu sohbetin oturum anahtarı altında kayıtlı görevler üzerinden iptal işlemi olarak uygulanır; Dream çalıştırması ise dream:YYYYMMDD-HHMMSS biçimindeki kendi geçici anahtarıyla oluşturulur. Bu, test edilmiş bir sonuç değil, kod yolu okumasıdır — /stop burada canlı bir Dream çalıştırmasına karşı yürütülmemiştir. Belgelenen seçenekler /restart, agents.defaults.dream.enabled değerini kapatmak veya ağ geçidi sürecini durdurmaktır. v0.3.5'te birleştirilen PR #5407, devre dışı bırakmanın kalıcı sistem görevini gerçekten kaldırmasını ve zamanlanmış hâlde bırakmamasını sağlar.

nanobot'un arka plan görevlerinin kaç belirteç kullandığını nasıl görürüm?

Bir slash komutu değil, yerel kullanım deposunu okuyun. nanobot v0.3.5 her model çağrısını user, api, cron, dream veya system olarak türlendirilmiş bir source alanıyla kaydeder; bunları yapılandırma dizinindeki — varsayılan olarak ~/.nanobot — llm_usage.sqlite3 dosyasına input, output, cache-read ve cache-write belirteç sütunlarıyla yazar ve tarih ile kaynağa göre gruplanmış toplamlara dönüştürür. İki tuzak vardır. /insights veya /cost komutu yoktur: bunlardan birini öneren #3735 ve #3921 numaralı iki pull request birleştirilmeden kapatılmıştır ve v0.3.5 yerleşik komut listesi /new, /compact, /stop, /restart, /status, /model, /history, /goal, /trigger, /dream, /dream-log, /dream-restore, /dream-prompt, /evaluator-prompt, /skill, /help ve /pairing'dir. Etiketler de asimetriktir: Dream harcaması dream olarak etiketlenir, ancak heartbeat harcaması cron olarak etiketlenir; çünkü heartbeat oturum anahtarı kelimesi kelimesine "heartbeat"tir. Bunlar para değil belirteç sayılarıdır; bu nedenle sağlayıcınızın kendi defteriyle mutabakat yapın.

nanobot v0.3.5'e yükseltmek döngüyü düzeltir mi?

Bunu söylediğini kimse belirtmedi ve bu sayfa da belirtmeyecek. #5781 numaralı issue v0.3.0'a karşı açılmıştır ve hâlâ açıktır; enhancement ve priority p2 olarak etiketlenmiştir; bildirici yükseltme sonrasında yeniden test etmemiş ve hiçbir bakımcı bunu yeniden üretmemiştir. v0.3.5'in düzelttiği şey daha dar kapsamlıdır ama yine de değerlidir: 4e2640f commit'i tamamlanmamış bir çalıştırmanın Dream imlecini ilerletmesini ve geçmişi sessizce atlamasını durdurur, birleştirilmiş PR #5442 tamamlanmamış bir çalıştırmanın neden tamamlanmadığını bildirmesini sağlar ve birleştirilmiş PR #5325 edit_file'ın işlemsiz bir düzenlemede başarı bildirmek yerine "Error: new_text must be different from old_text." döndürmesini sağlar. Sonuncusu #5324'teki oku-sonra-düzenle döngüsünü ele alır, #5781'deki salt okunur döngüyü değil. v0.3.5'te genel bir yinelenen aynı araç çağrısı koruması da bulunmaz. Gönderilen kaynakta bulunan tek tekrar koruması, nanobot/utils/runtime.py içindeki repeated_external_lookup_error'dır; iki denemeden sonra aynı web_fetch veya web_search çağrısını engeller ve başka hiçbir araç adıyla eşleşmez. Bu nedenle tekrarlanan read_file yineleme sınırına kadar devam eder. Genel koruma öneren beş pull request — #3077, #4522, #5344, #3701 ve #4154 — henüz birleştirilmemiştir.

21 Eylül 2026'da kontrol edildi: HKUDS/nanobot için ve #5781, #5324 ve #3073 issue'ları ile #5782, #5107, #5325, #5442, #5407, #3077, #4522, #5344, #3701, #4154, #3735, #3921 ve #4622 pull request'leri için GitHub API'si; nanobot-ai 0.3.5 için PyPI kaydı; nanobot'un 0.3.5 bellek ve yapılandırma belgeleri; ayrıca yukarıda alıntılanan her varsayılan, günlük dizesi ve kod yolu için v0.3.5 etiketindeki gönderilen kaynak kodu, iki sürümün farklı olduğu yerlerde v0.3.0 ile karşılaştırıldı. Kunavo nanobot'u kurmamış veya çalıştırmamıştır; buradaki hiçbir davranış Kunavo tarafından test edilmemiştir ve #5781 issue'sundaki döngü v0.3.5 üzerinde hiç kimse tarafından yeniden test edilmemiştir. Token oranları güncel katalogdan gelir ve her dolar rakamı belirtilen varsayımlara dayalı açıklayıcı aritmetiktir.