A dev.to post uses Sniffnet to watch the hidden network traffic of AI agents like Cline

A developer who keeps the Cline coding agent open in VS Code nearly all day has published a hands-on account of what happens when you stop reading agent logs and start watching packets instead. According to the post on dev.to, the motivation was a simple gap in visibility: token costs appear on every provider's dashboard, but there is no equivalent view of how much real network traffic an agent produces while it waits, polls, or ships context to a model API.

The author's argument is deliberately modest. The traffic is not assumed to be suspicious; the point is that almost nobody looks at it, and that blind spot becomes expensive later, when you need to diagnose odd latency, work out why an agent seems slow, or identify which processes are talking to which endpoints.

What Sniffnet does

Sniffnet is an open-source network analyzer written in Rust that renders real-time traffic in a graphical interface, sparing you from reading raw tcpdump output. As the post summarizes from the project's repository, it runs on Linux, macOS and Windows, builds on pcap — so it needs elevated permissions to capture on a real interface — and, on some systems, can attribute each connection to the process that opened it. That last capability is what lets you separate Cline from a browser with fifteen tabs open.

It is deliberately passive: not an intrusion detection system, not a firewall, and it blocks nothing. Equally important is what it does not promise. It will not decrypt TLS, will not show the contents of the HTTPS requests that model APIs make, and will not correlate traffic with token spend or model latency. It measures bytes and open connections, not meaning. Installation is a single cargo install sniffnet, plus a setcap command on Linux to grant capture privileges without running as root.

How a single capture gets misread

The post spends most of its energy on interpretation, and identifies two standard mistakes. The first is treating a five-minute traffic spike as a verdict. Without context you cannot tell whether the agent was uploading the contents of a large file, downloading a model, or merely holding a keep-alive connection open. A number stripped of that context tells you almost nothing.

The second mistake is assuming the traffic graph distinguishes useful work from plumbing. TCP/IP has no concept of "useful" traffic, so splitting genuine LLM call payload from connection overhead, retries, or polling by an unrelated extension requires filtering by process, port and destination IP. Sniffnet allows this, the author notes, but it demands active work rather than coming solved out of the box.

The counterexample given is familiar: someone sees their editor generating constant traffic while they are not even typing, and concludes the AI agent is misbehaving. It could just as easily be extension telemetry, a connection heartbeat, or the editor syncing settings to the cloud — nothing to do with the agent at all.

Where the tool fits, and where it does not

According to the post, Sniffnet is the right instrument for seeing which processes generate traffic on your machine in real time, for diagnosing dropped or retrying connections, and for mapping the overall traffic pattern of a development setup. It is only a partial fit for measuring how much HTTPS traffic an LLM API receives, since you see bytes and destinations but not content — for call-level detail, the source of truth is the tool's own log, such as Cline's activity panel in VS Code. It is the wrong instrument entirely for deciding whether an agent consumes too much in production, which needs aggregated metrics over time, or for intrusion detection with automatic alerts, territory the post assigns to Suricata or Zeek.

Idle versus active

The author's recommended first step is a comparison rather than a number: record which processes hold active connections while the agent is idle, then repeat the observation during a large refactor task. That idle-versus-active delta is more informative than any isolated figure, and for anyone already running Cline in autopilot mode with defined limits, the network view is a complement to those limits, not a replacement.

What a single session cannot prove

The post is unusually candid about its own limits. One capture is a data point, not a trend. The process-to-connection mapping can break in containerized environments or over a VPN. Network bytes and LLM tokens are different magnitudes — a request that is small in bytes can carry a long, expensive prompt. And application logs remain the authoritative record of which call corresponds to which agent action. Notably, the author declines to publish any headline traffic figure at all; the goal is to open a layer that normally goes unexamined, not to settle it.

Why it matters

AI coding agents are quietly becoming part of the default development environment, yet their observable surface is mostly a billing dashboard. The network layer is a blind spot exactly where troubleshooting happens: unexplained latency, agents that appear to stall, unknown endpoints. A free, passive tool like Sniffnet lowers the cost of looking. Just as valuable is the post's discipline — raw traffic data invites wrong conclusions, and the gap between bytes and meaning can only be closed with repeated, filtered measurement. For teams standardizing on agentic workflows, it is a useful template both for how to observe and how not to interpret.