Sniffnet: cuánto tráfico generan mis agentes IA sin que me avisen

Tengo Cline abierto en VS Code casi todo el día. De fondo, corre llamadas a APIs de modelos, hace requests que yo no disparo a mano y — asumo — mantiene conexiones vivas mientras "piensa". Nunca lo miré desde la capa de red. Miro logs de la app, miro el output del agente, pero nunca abrí un sniffer para ver los paquetes reales que salen de mi máquina cuando tengo tres o cuatro herramientas de IA corriendo al mismo tiempo.

Esa es la fricción concreta: uso agentes IA todos los días y no tengo la menor idea de cuánto tráfico "silencioso" generan. No cuánto me cobran los tokens — eso lo veo en el dashboard de cada proveedor — sino cuánto tráfico de red real cruza mi interfaz mientras Cline está "pensando" o mientras alguna extensión hace polling.

Mi tesis es simple y no es una revelación grandilocuente: no sabemos cuánto tráfico de fondo generan nuestros agentes IA hasta que los miramos con una herramienta dedicada, y a veces sorprende. No porque el tráfico sea sospechoso — es porque nunca lo miramos, punto. Y esa ignorancia tiene un costo cuando después querés diagnosticar latencia rara, entender por qué el agente "tarda" o simplemente saber qué procesos están hablando con qué endpoints.

Sniffnet como herramienta de monitoreo de tráfico de red

Sniffnet es una herramienta open source escrita en Rust que analiza el tráfico de red en tiempo real y lo muestra con una interfaz gráfica, sin que tengas que leer output crudo de tcpdump. Según su repositorio, permite elegir una interfaz de red, filtrar por aplicación, protocolo o dirección IP, y ver gráficos de tráfico entrante y saliente en vivo.

Lo que el repo dice, y que me importa para este experimento:

• Es multiplataforma (Linux, macOS, Windows).
• Usa pcap por debajo, así que necesita permisos elevados para capturar paquetes en la interfaz real.
• Identifica el proceso o la app asociada a cada conexión en algunos sistemas, lo cual es justo lo que necesito para separar "esto es Cline" de "esto es el navegador con quince pestañas abiertas".
• No es un IDS ni un firewall. No bloquea nada, no alerta de anomalías con lógica propia. Es observabilidad pasiva.

Lo que el repo NO dice, y que conviene tener claro antes de instalarlo: no promete desencriptar tráfico TLS, no te muestra el contenido de los requests HTTPS que hacen las APIs de LLM, y no correlaciona tráfico con costo de tokens ni con latencia del modelo. Sniffnet ve bytes y conexiones. No ve semántica.

# instalacion via cargo (necesita Rust instalado)
cargo install sniffnet

# en Linux, dar permisos de captura sin correr como root
sudo setcap cap_net_raw,cap_net_admin=eip $(which sniffnet)

# correrlo
sniffnet

Con eso levanta la interfaz gráfica, te pide que elijas la interfaz de red activa (wifi o ethernet) y arranca a graficar tráfico en tiempo real.

Dónde se equivoca la gente al leer estos números

La receta común es: instalás una herramienta de monitoreo, ves un pico de tráfico, asumís que "algo está mal" o que "el agente consume mucho más de lo esperado", y sacás una conclusión sin contexto.

El costo oculto de esa receta es doble. Primero, un pico de tráfico en una sesión de captura de cinco minutos no te dice si eso es normal, si es un caso aislado, o si depende de qué estaba haciendo el agente en ese momento exacto — ¿estaba subiendo contexto de un archivo grande? ¿Descargando un modelo? ¿Simplemente manteniendo un keep-alive? Sin ese contexto, el número es ruido con forma de dato.

Segundo, y más importante: TCP/IP no distingue "tráfico útil" de "tráfico de protocolo". Ves bytes yendo y viniendo, pero separar cuánto es payload real de la llamada al LLM versus overhead de conexión, reintentos o polling de alguna extensión que no tiene nada que ver con IA requiere mirar con más granularidad — filtrar por proceso, por puerto, por IP de destino — algo que Sniffnet permite pero que exige trabajo activo de quien mira, no viene resuelto de fábrica.

El contraejemplo clásico: alguien corre Sniffnet, ve que su editor con extensiones de IA genera tráfico constante incluso sin estar escribiendo código, y concluye "el agente está haciendo algo raro en segundo plano". Puede ser telemetría de la extensión, un heartbeat de conexión, o simplemente el editor sincronizando configuración en la nube — nada relacionado con el agente de IA en sí. La herramienta te da el bruto. La interpretación correcta te la tenés que ganar.

Matriz de decisión: cuándo usar Sniffnet para esto

Lo que miraría primero, antes de sacar cualquier conclusión: qué procesos aparecen en la lista de conexiones activas cuando el agente está inactivo (sin estar procesando nada) versus cuando le tirás una tarea de refactor grande. Esa comparación — inactivo vs. activo — es más informativa que mirar un número aislado.

Si ya usás Cline en modo autopilot con límites definidos, este tipo de observación de red es un complemento razonable: no reemplaza los límites de autonomía que le pongas al agente, pero te da visibilidad de un ángulo que normalmente no se mira — la capa de red, no la capa de comportamiento del agente.

flowchart LR
  A[Cline corriendo] --> B{Tarea activa}
  B -->|si| C[Llamada API LLM]
  B -->|no| D[Posible keep-alive o polling]
  C --> E[Sniffnet: ver bytes y destino]
  D --> E
  E --> F{Contexto conocido?}
  F -->|si| G[Conclusion valida]
  F -->|no| H[Necesita mas sesiones de captura]

Límites: lo que esta evidencia no permite concluir

Acá tengo que ser honesto con lo que Sniffnet, usado en una sesión de observación, puede y no puede darte:

• No podés concluir cuánto tráfico "es normal" sin una serie de mediciones repetidas en distintos escenarios de uso. Una captura puntual es un dato, no una tendencia.
• No podés separar tráfico de IA de tráfico de otras herramientas solo con el gráfico general. Necesitás filtrar por proceso o puerto, y eso depende de que el sistema operativo expose esa asociación correctamente — en algunos entornos containerizados o con VPN, la asociación proceso-conexión se pierde.
• No mide costo en tokens ni latencia del modelo. Bytes de red y tokens de LLM son magnitudes distintas: un request corto en bytes puede representar un prompt largo y caro, y viceversa.
• No reemplaza logs de la aplicación. Si querés saber exactamente qué llamada a qué endpoint corresponde a qué acción del agente, la fuente de verdad es el log de la herramienta (Cline, la CLI del proveedor de LLM), no el sniffer de red.
• Una sola sesión de captura no es un experimento reproducible en el sentido estricto. Para sacar una conclusión que valga la pena publicar necesitarías repetir la observación en condiciones comparables, algo que este post no hace ni pretende sustituir.

Dicho eso: el punto de instalar la herramienta no es sacar una cifra final, es abrir una capa que normalmente no miramos. Ya avancé algo parecido cuando comparé pnpm y npm en fricción de instalación o cuando cuestioné qué tan barato es en la práctica un agente como DeepSeek Reasonix: la costumbre de mirar cosas que uso todos los días sin haberlas mirado nunca de cerca.

Preguntas frecuentes

¿Sniffnet necesita permisos de administrador? Sí, porque usa pcap para capturar paquetes a nivel de interfaz de red. En Linux podés dar permisos específicos con setcap en vez de correrlo como root directamente, que es lo recomendable por seguridad.

¿Sniffnet puede ver el contenido de mis conversaciones con un LLM? No. El tráfico entre Cline (o cualquier cliente) y una API de LLM va cifrado con TLS. Sniffnet ve que hay una conexión, a qué IP o dominio va, cuántos bytes se transfieren — no el contenido del payload.

¿Sirve para medir cuánto gasto en tokens? No directamente. Bytes de red no equivalen a tokens de LLM. Para costo real de tokens hay que mirar el dashboard del proveedor o los logs de uso de la herramienta que estés usando.

¿Es mejor que Wireshark para este caso? Depende del objetivo. Wireshark tiene más profundidad de análisis de protocolo y es el estándar para diagnóstico avanzado. Sniffnet apunta a una lectura más rápida y visual del panorama general de tráfico por aplicación, sin la curva de aprendizaje de Wireshark.

¿Puedo usar Sniffnet en macOS o solo en Linux? Es multiplataforma: soporta Linux, macOS y Windows según la documentación del proyecto en GitHub.

¿Esto reemplaza tener observabilidad real en un sistema de producción? No. Es una herramienta de inspección local, pensada para una máquina de desarrollo. Para observabilidad de red en sistemas productivos existen otras capas — métricas agregadas, tracing distribuido, herramientas de infraestructura — que no son el objetivo de este experimento.

Mi postura

Instalar Sniffnet no me dio una cifra mágica de "esto es lo que gasta tu agente IA en red". Me dio algo más chico y más honesto: la posibilidad de mirar, cuando quiera, qué proceso está hablando con qué destino en mi máquina mientras tengo cuatro herramientas de IA corriendo a la vez. Eso ya es más de lo que tenía antes, que era cero visibilidad.

Lo que haría distinto si alguien quiere sacar una conclusión seria de esto: no una captura de cinco minutos, sino sesiones repetidas — agente inactivo, agente con tarea chica, agente con tarea de refactor grande — comparando los gráficos entre sí. Ahí el dato empieza a significar algo. Una sola foto de tráfico es apenas curiosidad; una serie de fotos comparadas es donde arranca el criterio.

Si laburás con agentes IA local a diario y nunca miraste la capa de red, el próximo paso lógico no es sacar conclusiones de una corrida. Es instalar la herramienta, mirar una semana, y recién ahí decidir si hay algo que valga la pena investigar más a fondo.

Fuente original:

• Sniffnet GitHub: https://github.com/GyulyVGC/sniffnet</content> <parameter name="excerpt">Instalé Sniffnet para mirar qué tráfico de red generan Cline y las llamadas a APIs de LLM corriendo en segundo plano. Esto es lo que muestra la herramienta y lo que no podés concluir con una sola sesión de observación.