Ketika bot Telegram NanoClaw berhenti merespons, langkah pertama bukanlah memperbaiki — melainkan menentukan apakah pesan inbound sama sekali mencapai host, karena dua kegagalan NanoClaw yang dilaporkan secara terpisah menghasilkan keluhan tersebut dengan tanda yang berlawanan. Dalam satu kasus, inbound mati sementara pengiriman outbound dan tugas terjadwal tetap berfungsi, sehingga setiap permukaan yang diperiksa operator tampak sehat. Dalam kasus lain, tidak ada yang terkirim, dan log menandai pesan sebagai terkirim padahal tidak pernah dikirim. Keluhannya sama, penyebabnya berbeda, dan solusi untuk satu kasus tidak berpengaruh pada kasus lainnya.
Satu pembedaan sebelum hal lain, karena hasil pencarian untuk frasa ini sebagian besar membahas produk yang berbeda. OpenClaw adalah proyek terpisah dan jauh lebih besar — 390.207 bintang dan lisensi NOASSERTION ketika catatan API repositorinya dibaca pada 21 September 2026 — dan beranda NanoClaw sendiri memosisikan diri terhadapnya. NanoClaw adalah nanocoai/nanoclaw: MIT, tidak diarsipkan, bukan fork, 30.818 bintang, 1.068 issue terbuka, terakhir didorong pada 19 September 2026 (GitHub API, tanggal yang sama). Alamat qwibitai/nanoclaw yang lebih lama mengembalikan 301 ke alamat tersebut, jadi itu adalah proyek yang sama dengan nama baru, bukan proyek kedua. Kedua proyek tidak berbagi jalur kode Telegram — NanoClaw memasang adapter-nya sendiri dengan menyalin source dari branch channels miliknya (skill add-telegram) — sehingga solusi OpenClaw tidak dapat diterapkan. Untuk perbedaan lengkapnya, lihat NanoClaw vs OpenClaw.
Baca tandanya sebelum menyentuh apa pun
Setiap baris di bawah ini adalah kegagalan berbeda yang dilaporkan secara terpisah, dengan pemeriksaan konfirmasi masing-masing. Kedelapannya dibaca pada 21 September 2026 dari issue tracker, skill yang dirilis, dan dokumentasi channel NanoClaw sendiri.
| Yang Anda amati | Penyebab paling mungkin | Pemeriksaan yang mengonfirmasinya |
|---|---|---|
| Tidak ada yang Anda kirim dijawab, tetapi balasan, pesan terjadwal, dan pengiriman outbound tetap berfungsi | Loop polling gagal dan mencoba lagi selamanya — issue #3728, terbuka | Baris Telegram polling request failed yang membawa nilai consecutiveFailures besar; log keberhasilan tidak mencatat apa pun, jadi log yang hening bukan bukti kesehatan |
Tidak ada yang terkirim; log utama menampilkan Message delivered dengan platformMsgId=undefined di samping No adapter for channel type | Dua instance host berjalan sekaligus — poller kedua menerima 409 dari Telegram, yang membatalkan setup sebelum adapter mendaftar (skill /debug, PR #2225) | Ketiadaan baris Channel adapter started untuk telegram, ditambah proses kedua di ps aux |
| Pesan langsung dan grup berfungsi; postingan channel tidak pernah tiba sama sekali | Filter update sisi server yang usang pada token bot — issue #2989, terbuka | Apakah token ini sebelumnya pernah dipoll oleh NanoClaw v1 atau library bot lain? Bot API milik Telegram menyatakan tentang allowed_updates: "Jika tidak ditentukan, pengaturan sebelumnya akan digunakan." |
| Bot menjawab pesan langsung tetapi mengabaikan teks grup biasa | Group Privacy aktif (skill add-telegram) | BotFather, /mybots, Bot Settings, Group Privacy — lalu tambahkan kembali bot ke grup setelahnya |
| Pesan berfungsi, tetapi pairing tidak pernah selesai | getMe saat boot gagal sekali dan nama pengguna bot null disimpan sepanjang masa hidup proses — issue #3162, terbuka | Satu peringatan Telegram getMe failed saat boot, beberapa menit sebelum Anda mencoba pairing; issue tersebut melaporkan bahwa restart akan menghapusnya |
| Setup dibatalkan dengan "Couldn't reach Telegram", atau startup terhenti sekitar satu setengah menit | IPv6 dikonfigurasi tanpa rute yang berfungsi — issue #2377, terbuka | curl -4 ke Bot API berhasil, sedangkan curl -6 tidak dapat terhubung |
| Sebagian besar balasan tiba, tetapi balasan yang berisi URL tertentu tidak pernah tiba | Pemformatan outbound, bukan penerimaan: issue #3569 melaporkan adapter yang dipin memotong pesan dengan jumlah marker yang tidak di-escape dan bernilai ganjil | Telegram menolak pengiriman; dua URL dengan satu garis bawah saling membatalkan, sehingga masalah tampak muncul secara tidak menentu |
| Bot kedua yang baru Anda tambahkan tidak pernah online | Variabel instance dibaca sekali saat mulai, dan token duplikat dilewati (dokumentasi channel) | Peringatan di logs/nanoclaw.error.log (skill add-telegram); Telegram mengizinkan satu poller per token, jadi setiap bot memerlukan token BotFather sendiri |
Diagnostik lini pertama resmi NanoClaw adalah dua file log ditambah ncl sessions list, ncl dropped-messages list dan ncl wirings list. Tidak ada versi yang dirilis yang menyediakan perintah liveness channel, jadi triase di bawah ini mengandalkan baris log.
# 1. Is inbound polling failing, and for how long?
# A rising consecutiveFailures count is the #3728 signature.
grep "Telegram polling request failed" logs/nanoclaw.error.log | tail -5
# 2. Did the Telegram adapter ever register this boot?
# Its ABSENCE is the duplicate-host signature, not an error line.
grep "Channel adapter started" logs/nanoclaw.log | tail -10
# 3. Is a second host holding the polling session?
ps aux | grep 'nanoclaw/dist/index.js' | grep -v grep
systemctl --user list-units 'nanoclaw*' --all # Linux systemd installsMengapa semuanya tampak sehat saat inbound mati
Ini bersifat struktural, dan bagian inilah yang paling banyak membuang waktu. README NanoClaw menjelaskan jalurnya sebagai aplikasi pesan ke router host ke database inbound, masuk ke container, keluar ke database outbound, lalu kembali melalui delivery. Delivery melakukan polling database outbound secara mandiri, dan sweep host setiap 60 detik secara independen membangunkan pesan yang sudah jatuh tempo dan berulang. Inbound adalah satu-satunya tahap yang bergantung pada poller Telegram — tepat itulah sebabnya pelapor issue #3728 melihat host tetap aktif, delivery outbound terus bekerja, dan tugas terjadwal terus berjalan selama sekitar empat hari dalam keheningan inbound total, dengan 11.178 kegagalan berturut-turut tercatat.
Hook kesehatan yang seharusnya mendeteksinya tidak berfungsi. Referensi interface adapter NanoClaw yang diterbitkan menyatakan bahwa isConnected() "saat ini tidak dipanggil oleh host di luar pengujian" dan bahwa "bridge selalu mengembalikan true". Trunk sejak itu berubah: perintah ncl status yang melaporkan flag connected per adapter masuk ke main pada 15 September 2026, setelah rilis v2.3.0, sehingga dokumentasinya akurat untuk setiap versi yang dirilis dan sudah usang untuk trunk. Perlakukan perintah tersebut sebagai internal yang belum dirilis, bukan sebagai saran — perintah itu terdaftar sebagai tersembunyi dan hanya untuk host serta tidak muncul dalam dokumentasi apa pun. Untuk Telegram, kedua jalur tetap bertemu: baik adapter 4.29.0 maupun 4.41.0 sama sekali tidak mengimplementasikan isConnected (kedua build dist di-grep untuk halaman ini), sehingga probe tetap kembali ke true dalam kedua kasus.
Dokumentasi juga memiliki celah yang sesuai. Halaman troubleshooting memiliki bagian berjudul "Webhook channel is silent" tanpa padanan untuk polling, dan panduan "Agent never replies" dimulai dengan "Did the router accept it?" bersama ncl dropped-messages list — langkah yang sudah mengasumsikan pesan mencapai host. Ketika poller mati, tidak ada baris pesan yang terbuang untuk ditemukan, karena router tidak pernah melihat pesan tersebut. Issue #2989 mencatat jalan buntu yang sama untuk penyebabnya sendiri: tidak ada baris log, tidak ada baris pesan terbuang, tidak ada yang dapat di-debug.
Tidak ada versi perbaikan, jadi buat rencana berdasarkan kondisi itu
Issue #3728 terbuka tanpa komentar, label, maupun milestone, dan stempel waktu pembaruannya masih sama dengan stempel waktu pembuatannya pada 6 September 2026. Rilis terbaru adalah v2.3.0 dari 24 Agustus 2026, dan satu-satunya commit pada branch channels sejak 1 September adalah perbaikan Mattermost. Hal yang sama berlaku untuk kasus filter usang: pull request yang akan menetapkan daftar update eksplisit telah terbuka terhadap channels sejak 22 Agustus 2026, dan source branch saat ini sama sekali tidak memuat kemunculan allowedUpdates. Kunci host satu-instance yang seharusnya mencegah kasus host duplikat ditutup tanpa digabungkan. Jadi pembingkaian yang jujur adalah mitigasi, bukan nomor versi.
Ada tiga hal yang perlu diketahui sebelum Anda menulis patch sendiri. Pertama, pengeditan lokal pada src/channels/telegram.ts tidak bertahan: skill add-telegram menyalin file tersebut dari branch channels dengan instruksi untuk menimpanya karena branch tersebut kanonis, dan skill update menyegarkan setiap channel yang terpasang — tepat itulah sebabnya pelapor #3728 kehilangan perbaikan tersebut setiap kali melakukan update. Kedua, watchdog milik pelapor juga merupakan peringatan, bukan sekadar resep: versi pertama yang hanya menggunakan penghitung menyebabkan gangguan lebih buruk selama tiga hari, karena poller akhirnya berhenti, bukan gagal, sehingga tidak ada kegagalan lanjutan yang dicatat dan penghitung tidak pernah mencapai ambang batasnya. Versi kedua menggunakan dua sinyal independen dan tidak pernah membiarkan poller berhenti. Tidak satu pun dari hal tersebut dirilis, didukung, atau diverifikasi secara independen. Ketiga, apa pun yang Anda bangun, uji pemulihan dalam kedua arah: keberhasilan outbound tidak membuktikan apa pun tentang inbound, jadi pemeriksaan yang penting adalah pesan baru yang dikirim dari chat yang sudah dipasangkan dan menghasilkan baris inbound baru.
Kegagalan channel Telegram bukan masalah model atau API
Perlu ditegaskan, karena pencarian berikutnya yang paling jelas akan mengarahkan orang ke jalan yang salah. Dokumentasi kredensial NanoClaw menyatakan bahwa token channel seperti TELEGRAM_BOT_TOKEN tetap berada di .env dan digunakan oleh proses host, bukan container, sedangkan kredensial model berada di vault dan diinjeksikan ke permintaan outbound saat berlangsung. Pesan inbound mencapai router dan database inbound sesi sebelum penyedia mana pun dipilih, karena penyedia ditentukan saat container dibuat (dokumentasi agent providers). Tidak ada base URL, key, gateway, atau pergantian penyedia yang dapat memperbaiki loop polling yang mati, filter update yang usang, benturan poller, Group Privacy, atau rute IPv6 yang rusak.
Persilangan yang sebenarnya berjalan ke arah sebaliknya. README NanoClaw mencantumkan Claude Code di antara persyaratannya secara khusus untuk /customize, /debug dan setiap skill /add-channel, sehingga perbaikan channel memerlukannya di host meskipun grup agent Anda berjalan di tempat lain. Persyaratan host adalah macOS atau Linux, Windows melalui WSL2, Node.js 22 atau yang lebih baru, pnpm 10 atau yang lebih baru, dan Docker — dan perhatikan bahwa nanoclaw.dev masih mengiklankan Node.js 20 atau yang lebih baru, sementara README dan changelog v2.3.0 menjadikan 22 sebagai batas minimum wajib. Ikuti changelog, yang menyebut peningkatan tersebut sebagai breaking.
Biaya sebenarnya NanoClaw dan channel Telegram-nya
| Item biaya | Biayanya | Sumbernya |
|---|---|---|
| NanoClaw sendiri | $0, berlisensi MIT, tanpa tier berbayar dan tanpa akun pengguna | nanoclaw.dev: "NanoClaw gratis dan bersumber terbuka di bawah lisensi MIT." |
| Akun portal komunitas | Gratis dan opsional; semua hal lain berfungsi tanpanya | README proyek |
| Token bot Telegram | $0 untuk dibuat di BotFather, dan tidak ada yang perlu dibeli untuk satu chat yang dipasangkan — tier Paid Broadcasts opsional Telegram hanya berlaku di atas 30 pesan per detik | Telegram Bot API; mode polling juga berarti tidak ada URL publik, webhook, atau port terbuka, menurut dokumentasi channel |
| Penggunaan model | Berapa pun biaya yang dikenakan penyedia terlampir; NanoClaw sendiri tidak mengenakan biaya untuk itu | FAQ nanoclaw.dev: "Penyedia agent Anda mungkin mengenakan biaya untuk penggunaan model." |
| Docker | Diperlukan di host; ketentuan langganan Docker sendiri berlaku di atas ambang penggunaan gratisnya | Tidak diperiksa untuk halaman ini — baca halaman harga Docker sebelum menyusun anggaran |
Tidak ada tier berbayar untuk membeli jalan keluar dari bot yang tidak responsif, dan itulah hal berguna yang ditunjukkan tabel tersebut. Pengeluaran baru dimulai setelah channel kembali berfungsi dan agent menjawab. Angka di bawah ini adalah perhitungan token ilustratif, bukan biaya tugas yang diukur dan bukan batas tagihan: asumsikan satu chat yang dipasangkan dengan 25 giliran per hari, 20.000 token input yang tidak di-cache dan 900 token output per giliran, selama 30 hari. Tarifnya adalah harga live katalog Kunavo per juta token.
| Model | Input / output per 1M | Perkiraan per bulan |
|---|---|---|
| Claude Haiku 4.5 | $0,70 / $3,50 | $12,86 |
| GPT-5.6 Terra | $0,70 / $4,20 | $13,34 |
| Claude Sonnet 4.6 | $2,10 / $10,50 | $38,59 |
| Claude Opus 5 | $3,50 / $17,50 | $64,31 |
Kalikan dengan lalu lintas Anda sendiri sebelum menganggapnya sebagai anggaran, dan perhatikan asumsi yang paling berpengaruh: tidak ada yang disajikan dari cache. Sesi agent yang berumur panjang mengirim ulang konteks, jadi perilaku cache lebih memengaruhi angka ini daripada selisih per token antara dua model yang berdekatan. Jumlah katalog Kunavo adalah batas minimum penagihan, bukan batas maksimum — ketika upstream melaporkan biayanya, tagihan adalah nilai yang lebih besar antara biaya katalog dan biaya upstream dikalikan markup yang berlaku. Top-up minimum adalah kredit prabayar sebesar $10, yaitu minimum pendanaan, bukan biaya tugas atau langganan; lihat detail penagihan.
| Rute untuk model agent | Unggul ketika | Hal yang tidak dilakukannya |
|---|---|---|
| API vendor langsung | Anda tetap menggunakan flagship satu vendor dan menginginkan ketentuan caching serta batch milik vendor tersebut | Vendor kedua berarti akun kedua dan saldo kedua |
| Gateway yang kompatibel dengan OpenAI atau Anthropic | Anda mengganti model per grup agent dan menginginkan satu key serta satu saldo | Penyedia native NanoClaw adalah Claude Agent SDK, jadi base URL khusus harus menggunakan format wire tersebut; endpoint berformat OpenAI diakses melalui skill penyedia OpenCode, yang merutekan model melalui konfigurasi OpenCode sendiri |
| Langganan | Penggunaan harian berat dengan tarif tetap lebih sesuai bagi Anda daripada token berdasarkan pemakaian | NanoClaw tidak menjual langganan sendiri; tarif tetap tersebut berasal dari penyedia |
| Model lokal | Pekerjaan kecil atau privat tanpa tagihan model terhosting | Skill Ollama milik NanoClaw sendiri dijelaskan menargetkan jalur konfigurasi yang lebih lama dan bukan pengganti drop-in yang didukung pada main saat ini |
Tidak satu pun dari empat pilihan tersebut menyentuh jalur Telegram. Untuk sisi penyedia secara lengkap — dua variabel lingkungan yang dibaca setup, apa yang sebenarnya dilihat container, dan posisi OpenCode serta Codex — lihat NanoClaw API costs and providers. Jika Anda menghubungkan runtime Claude default ke endpoint khusus, panduan integrasi Claude Code dan referensi base URL membahas konfigurasinya, dan Anda dapat membuat akun Kunavo saat siap mendanai key. Kunavo belum menguji NanoClaw saat runtime, dan panduan setup yang diterbitkan adalah referensi konfigurasi, bukan pengujian kompatibilitas.
Pertanyaan umum
Mengapa bot Telegram NanoClaw saya berhenti merespons?
Mulailah dengan menanyakan apakah pesan masih meninggalkan host. Jika balasan dan pesan terjadwal masih tiba tetapi tidak ada respons terhadap apa pun yang Anda kirim, polling inbound adalah tersangka: issue NanoClaw #3728 melaporkan bahwa loop polling adapter mencoba getUpdates selamanya dengan batas backoff 30 detik, tidak pernah menyerah, dan tidak mencatat apa pun saat polling berhasil, sehingga kegagalannya tidak terlihat. Jika tidak ada yang terkirim juga, dan log menampilkan entri "Message delivered" dengan platformMsgId=undefined di samping peringatan "No adapter for channel type", skill /debug milik NanoClaw menyebut dua instance layanan yang berjalan bersamaan sebagai penyebabnya. Kedua kondisi tersebut memiliki solusi yang berlawanan, jadi identifikasi polanya sebelum mengubah apa pun.
Apakah ada versi tetap untuk bug polling Telegram di NanoClaw?
Tidak, setidaknya hingga 21 September 2026. Issue #3728 masih terbuka tanpa komentar, label, maupun milestone, dan stempel waktunya yang diperbarui masih sama dengan tanggal dibuatnya, 6 September 2026. Rilis NanoClaw terbaru adalah v2.3.0 dari 24 Agustus 2026, jadi belum ada apa pun yang dirilis sejak laporan tersebut, dan satu-satunya commit pada branch channels sejak 1 September adalah perbaikan Mattermost. Siapa pun yang menyuruh Anda meningkatkan ke versi NanoClaw tertentu untuk masalah ini sedang menyebutkan versi yang tidak ada.
Apakah meningkatkan @chat-adapter/telegram akan memperbaikinya?
Bukan jalur kegagalan diam-diam. NanoClaw mengunci @chat-adapter/telegram tepat pada 4.29.0, yang dipublikasikan 18 Mei 2026, sedangkan dist-tag terbaru npm adalah 4.41.0 dari 18 September 2026. Kedua tarball diunduh dan dibandingkan untuk halaman ini: cabang kegagalan transport getUpdates secara substantif identik pada kedua build — penghitung consecutiveFailures yang sama, batas backoff 30 detik yang sama, baris peringatan yang sama, tanpa berhenti maupun eskalasi, dan polling yang berhasil tetap tidak mencatat apa pun. 4.41.0 memang menulis ulang bagian lain dari loop. Halaman ini menyatakan hal tersebut sebagai fakta tentang kode dan tidak menyarankan menaikkan pin: skill add-telegram NanoClaw menyatakan bahwa kebijakan supply chain menolak range, dua pull request peningkatan yang dibaca untuk halaman ini (#3460 dan #3570) masih terbuka dan belum digabungkan, dan tidak ada yang menguji perubahan lain akibat peningkatan tersebut.
Apakah mengganti penyedia API atau URL dasar saya akan memperbaiki masalah Telegram?
Tidak. Dokumentasi kredensial NanoClaw menyatakan bahwa token channel seperti TELEGRAM_BOT_TOKEN tetap berada di .env dan digunakan oleh proses host, bukan container, sedangkan kredensial model masuk ke vault dan diinjeksikan ke lalu lintas container. Pesan Telegram masuk mencapai router dan database inbound sesi sebelum penyedia pernah ditentukan, yang terjadi saat container dibuat. Jadi endpoint, key, atau gateway lain tidak dapat memperbaiki loop polling yang mati, filter update sisi server yang usang, benturan poller, Group Privacy, atau rute IPv6 yang rusak. Satu-satunya persilangan nyata justru sebaliknya: README NanoClaw mencantumkan Claude Code sebagai persyaratan untuk /debug dan setiap skill /add-channel, sehingga perbaikan channel memerlukannya di host meskipun agent Anda berjalan di tempat lain.
Bot menjawab pesan langsung tetapi mengabaikan grup. Mengapa?
Biasanya itu disebabkan oleh pengaturan Group Privacy Telegram, bukan cacat NanoClaw. Skill add-telegram NanoClaw menyatakan bahwa ketika Group Privacy aktif, bot hanya melihat perintah dan balasan yang ditujukan kepadanya, bukan teks biasa, dan Anda harus menonaktifkannya di BotFather melalui /mybots, bot Anda, Bot Settings, Group Privacy — lalu hapus dan tambahkan kembali bot ke grup agar perubahan berlaku. Kasus lain tampak serupa tetapi berbeda: NanoClaw issue #2989 melaporkan bahwa token bot yang sebelumnya dipoll dengan filter allowed_updates yang lebih sempit mempertahankan filter tersebut di sisi server selamanya, sehingga secara diam-diam menghapus postingan channel sementara pesan langsung dan grup tetap berfungsi.
Pairing tidak pernah selesai, tetapi bot tetap berfungsi. Apa yang salah?
NanoClaw issue #3162 menggambarkan kondisi tersebut secara tepat: jika panggilan getMe saat channel dimulai gagal sekali, nama pengguna bot disimpan sebagai null sepanjang masa hidup proses dan setiap kode pairing yang Anda kirim diperlakukan sebagai pesan biasa, tanpa percobaan yang tercatat dan installer menunggu selamanya. Satu-satunya jejak adalah satu baris peringatan saat boot, beberapa menit sebelum Anda mencoba melakukan pairing, dan issue tersebut menyatakan bahwa restart tanpa perubahan lain akan memperbaikinya. Adapter branch channels saat ini masih melakukan pencarian itu sekali, tanpa retry, dan menyimpan hasilnya. Perhatikan juga bahwa dokumentasi NanoClaw menjelaskan kode 6 digit sekali pakai dengan hingga 5 kode yang dibuat ulang per proses, sedangkan issue #3162 menyebut kode 4 digit; ikuti dokumentasi.
Diperiksa pada 21 September 2026: catatan repositori dan daftar rilis nanocoai/nanoclaw, status terbuka/tertutup issue #2377, #2989, #3162, #3569, dan #3728 serta pull request #2225, #2697, #3449, #3460, dan #3570, source adapter Telegram pada branch channels, baik build adapter 4.29.0 yang dipin maupun 4.41.0 saat ini dari npm, dokumentasi channel, kredensial, troubleshooting, dan adapter-interface NanoClaw, skill add-telegram dan debug-nya, serta halaman Bot API Telegram. Tidak ada apa pun di halaman ini yang dijalankan terhadap instalasi NanoClaw yang sedang berjalan. Tarif token Kunavo berasal dari katalog live, dan angka dolar adalah perhitungan token ilustratif.