Cuando un bot de Telegram de NanoClaw deja de responder, el primer paso no es aplicar una solución: es decidir si los mensajes entrantes llegan al host, porque dos fallos de NanoClaw comunicados por separado producen esa queja con firmas opuestas. En uno, la entrada muere mientras la entrega saliente y las tareas programadas siguen funcionando, por lo que todas las superficies que comprueba un operador parecen estar sanas. En el otro, tampoco se envía nada y el registro marca como entregados mensajes que nunca se enviaron. La misma queja, causas distintas, y una solución para uno no hace nada por el otro.
Una aclaración antes de nada, porque los resultados de búsqueda de esta frase tratan mayoritariamente sobre otro producto. OpenClaw es un proyecto independiente y mucho más grande — 390.207 estrellas y una licencia NOASSERTION cuando se leyó su registro mediante la API del repositorio el 21 de septiembre de 2026 — y la propia página de inicio de NanoClaw se posiciona frente a él. NanoClaw es nanocoai/nanoclaw: MIT, no archivado, no es un fork, 30.818 estrellas, 1.068 incidencias abiertas y último push el 19 de septiembre de 2026 (API de GitHub, misma fecha). La dirección anterior qwibitai/nanoclaw devuelve una redirección 301 hacia este repositorio, por lo que se trata del mismo proyecto renombrado, no de un segundo proyecto. Los dos proyectos no comparten ninguna ruta de código de Telegram — NanoClaw instala su propio adaptador copiando el código fuente de su rama channels (habilidad add-telegram) —, así que una solución para OpenClaw no se aplica aquí. Para consultar la diferencia completa, véase NanoClaw frente a OpenClaw.
Lee la firma antes de tocar nada
Cada fila siguiente es un fallo distinto y comunicado por separado, con su propia comprobación confirmatoria. Los ocho se consultaron el 21 de septiembre de 2026 en el propio gestor de incidencias de NanoClaw, sus habilidades distribuidas y la documentación del canal.
| Lo que observas | Causa más probable | La comprobación que lo confirma |
|---|---|---|
| Nada de lo que envías recibe respuesta, pero las respuestas, los mensajes programados y la entrega saliente siguen funcionando | El bucle de sondeo falla y reintenta eternamente — incidencia #3728, abierta | Una línea Telegram polling request failed que contiene un valor consecutiveFailures grande; los registros de éxito no muestran nada, así que un registro silencioso no demuestra que esté sano |
Tampoco se envía nada; el registro principal muestra Message delivered con platformMsgId=undefined junto a No adapter for channel type | Dos instancias del host al mismo tiempo — el segundo sondeador recibe un 409 de Telegram, que aborta la configuración antes de que se registre el adaptador (habilidad /debug, PR #2225) | La ausencia de una línea Channel adapter started para telegram, además de un segundo proceso en ps aux |
| Los mensajes directos y los grupos funcionan; las publicaciones en canales nunca llegan | Un filtro obsoleto de actualizaciones en el servidor asociado al token del bot — incidencia #2989, abierta | ¿Este token fue sondeado anteriormente por NanoClaw v1 u otra biblioteca de bots? La propia API de bots de Telegram indica sobre allowed_updates: «Si no se especifica, se utilizará la configuración anterior». |
| El bot responde a los mensajes directos, pero ignora el texto normal de los grupos | La privacidad de grupo está activada (habilidad add-telegram) | BotFather, /mybots, Bot Settings, Group Privacy — y vuelve a añadir el bot al grupo después |
| La mensajería funciona, pero el emparejamiento nunca termina | getMe falló una vez durante el arranque y el nombre de usuario nulo del bot queda almacenado durante toda la vida del proceso — incidencia #3162, abierta | Una advertencia Telegram getMe failed durante el arranque, minutos antes de que intentaras emparejarlo; la incidencia indica que un reinicio lo soluciona |
| La configuración se aborta con «Couldn't reach Telegram», o el inicio se detiene durante aproximadamente un minuto y medio | IPv6 configurado sin una ruta funcional — incidencia #2377, abierta | curl -4 contra la API de bots funciona, mientras que curl -6 no puede conectarse |
| La mayoría de las respuestas llegan, pero las que contienen determinadas URL nunca lo hacen | El formato saliente, no la recepción: la incidencia #3569 informa de que el adaptador fijado trunca los mensajes con un número impar de marcadores sin escapar | Telegram rechaza el envío; dos URL con un solo guion bajo se cancelan entre sí, lo que hace que parezca intermitente |
| Un segundo bot que acabas de añadir nunca se conecta | Las variables de instancia se leen una sola vez al inicio y se omite un token duplicado (documentación del canal) | Una advertencia en logs/nanoclaw.error.log (habilidad add-telegram); Telegram permite un sondeador por token, por lo que cada bot necesita su propio token de BotFather |
Los diagnósticos oficiales de primera línea de NanoClaw son dos archivos de registro más ncl sessions list, ncl dropped-messages list y ncl wirings list. Ninguna versión publicada incluye un comando para comprobar la disponibilidad del canal, por lo que el diagnóstico siguiente se apoya en las líneas de registro.
# 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 installsPor qué todo parece saludable mientras la entrada está muerta
Esto es estructural y es la parte que más tiempo hace perder. El README de NanoClaw describe la ruta como aplicación de mensajería a enrutador del host, luego a una base de datos de entrada, dentro del contenedor, fuera a una base de datos de salida y de vuelta mediante la entrega. La entrega sondea la base de datos de salida por su cuenta, y un barrido del host cada 60 segundos despierta de forma independiente los mensajes cuya hora de envío ha llegado y los recurrentes. La entrada es la única etapa que depende del sondeador de Telegram — precisamente por eso quien informó de la incidencia #3728 vio que el host seguía activo, la entrega saliente continuaba funcionando y las tareas programadas seguían ejecutándose durante aproximadamente cuatro días de silencio total de entrada, con 11.178 fallos consecutivos registrados.
El indicador de estado que debería haberlo detectado no lo hace. La referencia publicada de la interfaz del adaptador de NanoClaw indica sobre isConnected() que «actualmente no lo llama el host fuera de las pruebas» y que «el puente siempre devuelve true». Desde entonces trunk ha avanzado: un comando ncl status que informa de un indicador de conexión por adaptador llegó a main el 15 de septiembre de 2026, después del lanzamiento de v2.3.0, lo que hace que la documentación sea correcta para toda versión publicada y obsoleta para trunk. Trata ese comando como una implementación interna no publicada, no como una recomendación: está registrado como oculto y solo para el host, y no aparece en ninguna documentación. En Telegram las dos rutas terminan coincidiendo: ni la versión 4.29.0 ni la 4.41.0 del adaptador implementan isConnected (se buscaron ambas compilaciones dist para esta página), por lo que la comprobación recurre a true en cualquier caso.
La documentación tiene un hueco equivalente. La página de solución de problemas incluye una sección titulada «El canal webhook está en silencio» y ninguna equivalente para el sondeo, y su guía «El agente nunca responde» comienza con «¿El enrutador lo aceptó?» mediante ncl dropped-messages list — un paso que ya presupone que el mensaje llegó al host. Cuando el sondeador está muerto no hay filas de mensajes descartados que encontrar, porque el enrutador nunca vio el mensaje. La incidencia #2989 registra el mismo callejón sin salida para su propia causa: ninguna línea de registro, ninguna fila de mensajes descartados y nada que depurar.
No existe una versión con la solución, así que planifica en torno a ello
La incidencia #3728 está abierta con cero comentarios, cero etiquetas y ningún hito, y su marca de actualización sigue siendo igual a la de creación, el 6 de septiembre de 2026. La versión más reciente es la v2.3.0 del 24 de agosto de 2026, y el único commit en la rama channels desde el 1 de septiembre es una corrección para Mattermost. Lo mismo ocurre con el caso del filtro obsoleto: la solicitud de cambios que fijaría una lista explícita de actualizaciones está abierta contra channels desde el 22 de agosto de 2026, y el código fuente de la rama actual no contiene ninguna aparición de allowedUpdates. El bloqueo del host de instancia única que habría evitado el caso de hosts duplicados se cerró sin fusionarse. Por tanto, el planteamiento honesto es mitigación, no un número de versión.
Conviene saber tres cosas antes de escribir tu propio parche. Primero, una edición local de src/channels/telegram.ts no persiste: la habilidad add-telegram copia ese archivo desde la rama channels con la instrucción de sobrescribirlo porque dicha rama es la canónica, y la habilidad de actualización renueva todos los canales instalados — precisamente por eso quien informó de la #3728 perdió esa corrección con cada actualización. Segundo, el watchdog de quien informó es tanto una advertencia como una receta: la primera versión, basada solo en un contador, causó una interrupción de tres días aún peor, porque el sondeador terminó detenido en vez de fallar, de modo que no se registraron más fallos y el contador nunca alcanzó su umbral. La segunda versión utilizó dos señales independientes y nunca dejó detenido el sondeador. Nada de eso se distribuye, está respaldado ni se ha verificado de forma independiente. Tercero, construyas lo que construyas, prueba la recuperación en ambas direcciones: el éxito saliente no demuestra nada sobre la entrada, así que la comprobación importante es enviar un mensaje nuevo desde el chat emparejado que produzca una nueva fila de entrada.
Un fallo del canal de Telegram no es un problema del modelo ni de la API
Conviene decirlo claramente, porque la siguiente búsqueda obvia lleva a la gente en la dirección equivocada. La documentación de credenciales de NanoClaw indica que los tokens de canales como TELEGRAM_BOT_TOKEN permanecen en .env y los utiliza el proceso del host, no los contenedores, mientras que las credenciales del modelo viven en el almacén seguro y se inyectan en las solicitudes salientes durante la ejecución. Los mensajes entrantes llegan al enrutador y a la base de datos de entrada de la sesión antes de elegir cualquier proveedor, ya que el proveedor se resuelve cuando se inicia el contenedor (documentación de proveedores de agentes). Ninguna URL base, clave, gateway o cambio de proveedor repara un bucle de sondeo muerto, un filtro de actualizaciones obsoleto, una colisión de sondeadores, la privacidad de grupo o una ruta IPv6 defectuosa.
El cruce real funciona en la otra dirección. El README de NanoClaw enumera Claude Code entre sus requisitos específicamente para /customize, /debug y cada habilidad /add-channel, por lo que reparar un canal lo necesita en el host aunque los grupos de agentes se ejecuten en otra cosa. Los requisitos del host son macOS o Linux, Windows mediante WSL2, Node.js 22 o posterior, pnpm 10 o posterior y Docker; ten en cuenta que nanoclaw.dev todavía anuncia Node.js 20 o posterior, mientras que el README y el registro de cambios de la v2.3.0 establecen 22 como mínimo obligatorio. Sigue el registro de cambios, que califica el aumento como incompatible.
Cuánto cuestan realmente NanoClaw y su canal de Telegram
| Partida | Cuánto cuesta | De dónde procede |
|---|---|---|
| El propio NanoClaw | $0, con licencia MIT, sin nivel de pago ni cuentas de usuario | nanoclaw.dev: «NanoClaw es gratuito y de código abierto bajo la licencia MIT». |
| La cuenta del portal comunitario | Gratuita y opcional; todo lo demás funciona sin ella | El README del proyecto |
| El token del bot de Telegram | $0 para crearlo en BotFather y nada que comprar para un chat emparejado — el nivel opcional Paid Broadcasts de Telegram solo se aplica por encima de 30 mensajes por segundo | API de bots de Telegram; el modo de sondeo también significa que no se necesita una URL pública, un webhook ni un puerto abierto, según la documentación del canal |
| Uso del modelo | Lo que cobre el proveedor conectado; NanoClaw no cobra nada por ello | Preguntas frecuentes de nanoclaw.dev: «El proveedor de tu agente puede cobrar por el uso del modelo». |
| Docker | Obligatorio en el host; se aplican las condiciones de suscripción propias de Docker por encima de sus umbrales de uso gratuito | No se ha comprobado para esta página; consulta la página de precios de Docker antes de presupuestarlo |
No existe un nivel de pago que puedas comprar para resolver un bot que no responde, y eso es lo útil que muestra esa tabla. El dinero solo empieza a contar cuando el canal vuelve a funcionar y el agente responde. Las cifras siguientes son aritmética ilustrativa de tokens, no costes de tareas medidos ni un límite máximo de facturación: supón un chat emparejado con 25 turnos al día, 20.000 tokens de entrada sin caché y 900 tokens de salida por turno, durante 30 días. Las tarifas son precios actuales del catálogo de Kunavo por millón de tokens.
| Modelo | Entrada/salida por 1M | Mes estimado |
|---|---|---|
| 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 |
Escálalo según tu propio tráfico antes de tratarlo como un presupuesto y observa el supuesto que más influye: nada se sirve desde la caché. Una sesión de agente de larga duración vuelve a enviar el contexto, por lo que el comportamiento de la caché mueve esta cifra más que la diferencia por token entre dos modelos vecinos. El importe del catálogo de Kunavo es un mínimo de facturación, no un límite: cuando el proveedor ascendente informa de su cargo, la factura es el mayor valor entre el coste del catálogo y el coste ascendente multiplicado por el margen aplicable. La recarga mínima es de $10 en crédito prepago, un mínimo de financiación y no una tarifa por tarea ni una suscripción; consulta los detalles de facturación.
| Ruta para el modelo del agente | Cuándo gana | Lo que no hace |
|---|---|---|
| API directa del proveedor | Quieres mantener el modelo insignia de un proveedor y sus propias condiciones de caché y procesamiento por lotes | Un segundo proveedor implica una segunda cuenta y un segundo saldo |
| Un gateway compatible con OpenAI o Anthropic | Cambias de modelo por grupo de agentes y quieres una sola clave y un solo saldo | El proveedor nativo de NanoClaw es el Claude Agent SDK, por lo que una URL base personalizada debe hablar ese formato de comunicación; se accede a un endpoint con formato OpenAI mediante la habilidad de proveedor de OpenCode, que enruta los modelos a través de la configuración propia de OpenCode |
| Una suscripción | El uso diario intensivo a tarifa plana te conviene más que los tokens medidos | NanoClaw no vende ninguna suscripción propia; la tarifa plana pertenece al proveedor |
| Un modelo local | Trabajo pequeño o privado sin una factura de modelo alojado | La propia habilidad de Ollama de NanoClaw se describe como dirigida a una ruta de configuración antigua y no como un cambio directo compatible con la rama main actual |
Ninguna de esas cuatro opciones afecta a la ruta de Telegram. Para consultar todos los detalles del lado del proveedor — las dos variables de entorno que lee la configuración, lo que realmente ve el contenedor y dónde encajan OpenCode y Codex — véase Costes y proveedores de la API de NanoClaw. Si estás conectando el entorno de Claude predeterminado a un endpoint personalizado, la guía de integración de Claude Code y la referencia de la URL base cubren la configuración, y puedes crear una cuenta de Kunavo cuando estés listo para financiar una clave. Kunavo no ha probado NanoClaw en tiempo de ejecución, y una guía de configuración publicada es una referencia de configuración, no una prueba de compatibilidad.
Preguntas frecuentes
¿Por qué mi bot de Telegram de NanoClaw dejó de responder?
Empieza preguntando si los mensajes siguen saliendo del host. Si las respuestas y los mensajes programados siguen llegando, pero no se responde a nada de lo que envías, el sospechoso es el sondeo entrante: el issue #3728 de NanoClaw informa que el bucle de sondeo del adaptador reintenta getUpdates indefinidamente con un límite de espera de 30 segundos, nunca abandona y no registra nada cuando un sondeo tiene éxito, por lo que el fallo es invisible. Si tampoco se envía nada y el registro muestra entradas "Message delivered" con platformMsgId=undefined junto a advertencias "No adapter for channel type", la skill /debug del propio NanoClaw identifica como causa la ejecución simultánea de dos instancias del servicio. Esos dos casos tienen soluciones opuestas, así que identifica la firma antes de cambiar nada.
¿Existe una versión fija del error de sondeo de Telegram de NanoClaw?
No, al 21 de septiembre de 2026. El issue #3728 sigue abierto con cero comentarios, cero etiquetas y ningún hito, y su marca de tiempo de actualización sigue siendo la fecha en que se presentó, el 6 de septiembre de 2026. La versión más reciente de NanoClaw es la v2.3.0 del 24 de agosto de 2026, por lo que no se ha publicado nada desde el informe, y el único commit en la rama channels desde el 1 de septiembre es una corrección de Mattermost. Quien te diga que actualices a una versión específica de NanoClaw para resolver esto está nombrando una versión que no existe.
¿Actualizar @chat-adapter/telegram lo soluciona?
No en el caso de muerte silenciosa. NanoClaw fija @chat-adapter/telegram exactamente en 4.29.0, publicada el 18 de mayo de 2026, mientras que la etiqueta dist más reciente de npm es 4.41.0 del 18 de septiembre de 2026. Para esta página se descargaron y compararon ambos tarballs: la rama de fallo de transporte de getUpdates es materialmente idéntica en ambas compilaciones; tienen el mismo contador consecutiveFailures, el mismo límite de espera de 30 segundos, la misma línea de advertencia, no abandonan ni escalan el fallo, y un sondeo correcto sigue sin registrar nada. La 4.41.0 sí reescribió otras partes del bucle. Esta página lo afirma como un hecho sobre el código y no recomienda aumentar la versión fijada: la skill add-telegram de NanoClaw indica que la política de cadena de suministro rechaza rangos, las dos solicitudes de aumento de versión consultadas para esta página (#3460 y #3570) están abiertas y sin fusionar, y nadie aquí probó qué más cambia al aumentar la versión.
¿Cambiar mi proveedor de API o la URL base solucionará un problema de Telegram?
No. La documentación de credenciales de NanoClaw indica que los tokens de canal como TELEGRAM_BOT_TOKEN permanecen en .env y los usa el proceso del host, no los contenedores, mientras que las credenciales del modelo van a la bóveda y se inyectan en el tráfico del contenedor. Un mensaje entrante de Telegram llega al router y a la base de datos entrante de la sesión antes de que se resuelva cualquier proveedor, lo que ocurre cuando se inicia el contenedor. Por tanto, otro endpoint, clave o gateway no puede reparar un bucle de sondeo detenido, un filtro de actualizaciones obsoleto del servidor, una colisión de sondeadores, Group Privacy o una ruta IPv6 defectuosa. La única conexión real funciona en sentido contrario: el README de NanoClaw enumera Claude Code como requisito para /debug y para cada skill /add-channel, por lo que la reparación del canal lo necesita en el host incluso en una instalación cuyo agente se ejecuta en otro lugar.
El bot responde a los mensajes directos, pero ignora el grupo. ¿Por qué?
Normalmente se trata de la configuración Group Privacy de Telegram, no de un defecto de NanoClaw. La skill add-telegram de NanoClaw indica que, con Group Privacy activado, el bot solo ve comandos dirigidos a él y sus respuestas, no el texto ordinario, y que debes desactivarlo en BotFather mediante /mybots, tu bot, Bot Settings, Group Privacy; después, elimina y vuelve a añadir el bot al grupo para que el cambio surta efecto. Hay otro caso que parece similar, pero no lo es: el issue #2989 de NanoClaw informa que un token de bot que antes se sondeó con un filtro allowed_updates más limitado conserva ese filtro en el servidor para siempre, lo que descarta silenciosamente las publicaciones de canales mientras los mensajes directos y los grupos siguen funcionando.
El emparejamiento nunca termina, pero el bot sigue funcionando. ¿Qué ocurre?
El issue #3162 de NanoClaw describe exactamente ese patrón: si la llamada getMe al iniciar el canal falla una vez, el nombre de usuario del bot se almacena en caché como null durante toda la vida del proceso y cada código de emparejamiento que envías se trata como un mensaje normal, sin registrar ningún intento, mientras el instalador espera indefinidamente. La única señal es una sola línea de advertencia al arrancar, minutos antes de que intentes emparejarlo, y el issue indica que un reinicio sin ningún otro cambio lo soluciona. El adaptador actual de la rama channels todavía realiza esa consulta una sola vez, sin reintento, y almacena el resultado en caché. Ten en cuenta también que la documentación de NanoClaw describe un código de 6 dígitos de un solo uso con hasta 5 códigos regenerados por ejecución, mientras que el issue #3162 lo llama código de 4 dígitos; sigue la documentación.
Comprobado el 21 de septiembre de 2026: el registro del repositorio nanocoai/nanoclaw y la lista de versiones, los estados abiertos/cerrados de las incidencias #2377, #2989, #3162, #3569 y #3728 y de las solicitudes de cambios #2225, #2697, #3449, #3460 y #3570, el código fuente del adaptador de Telegram de la rama channels, las compilaciones fijada 4.29.0 y actual 4.41.0 del adaptador procedentes de npm, la documentación de canales, credenciales, solución de problemas e interfaz del adaptador de NanoClaw, sus habilidades add-telegram y debug, y la página de la API de bots de Telegram. Nada de esta página se ejecutó contra una instalación activa de NanoClaw. Las tarifas de tokens de Kunavo proceden del catálogo actual y las cifras en dólares son aritmética ilustrativa de tokens.