Sniffnet: How Much Traffic Are My AI Agents Generating Behind My Back

I have Cline open in VS Code almost all day. In the background, it fires off calls to model APIs, makes requests I never triggered by hand, and — I assume — keeps connections alive while it's "thinking." I never looked at this from the network layer. I check app logs, I check the agent's output, but I never opened a sniffer to see the actual packets leaving my machine while I've got three or four AI tools running at the same time.

That's the concrete friction here: I use AI agents every day and I have zero idea how much "silent" traffic they generate. Not how much the tokens cost me — that I see on each provider's dashboard — but how much actual network traffic crosses my interface while Cline is "thinking" or while some extension is polling.

My thesis is simple, and it's not some grandiose revelation: we don't know how much background traffic our AI agents generate until we look at it with a dedicated tool, and sometimes it's surprising. Not because the traffic is suspicious — it's because we simply never look, period. And that ignorance has a cost later when you want to diagnose weird latency, understand why the agent "takes forever," or just know which processes are talking to which endpoints.

Sniffnet as a Network Traffic Monitoring Tool

Sniffnet is an open source tool written in Rust that analyzes network traffic in real time and shows it with a graphical interface, so you don't have to read raw tcpdump output. According to its repo, it lets you pick a network interface, filter by application, protocol, or IP address, and view live incoming and outgoing traffic graphs.

What the repo says, and what matters to me for this experiment:

• It's cross-platform (Linux, macOS, Windows).
• It uses pcap under the hood, so it needs elevated permissions to capture packets on the real interface.
• It identifies the process or app tied to each connection on some systems, which is exactly what I need to separate "this is Cline" from "this is the browser with fifteen tabs open."
• It's not an IDS or a firewall. It doesn't block anything, doesn't alert on anomalies with its own logic. It's passive observability.

What the repo does NOT say, and what's worth knowing before installing it: it doesn't promise to decrypt TLS traffic, it doesn't show you the content of the HTTPS requests LLM APIs make, and it doesn't correlate traffic with token cost or model latency. Sniffnet sees bytes and connections. It doesn't see semantics.

# installation via cargo (needs Rust installed)
cargo install sniffnet

# on Linux, grant capture permissions without running as root
sudo setcap cap_net_raw,cap_net_admin=eip $(which sniffnet)

# run it
sniffnet

That spins up the graphical interface, asks you to pick the active network interface (wifi or ethernet), and starts graphing real-time traffic.

Where People Get These Numbers Wrong

The common recipe is: you install a monitoring tool, you see a traffic spike, you assume "something's wrong" or "the agent's eating way more than expected," and you draw a conclusion without context.

The hidden cost of that recipe is twofold. First, a traffic spike in a five-minute capture session doesn't tell you if that's normal, if it's an isolated case, or if it depends on what the agent was doing at that exact moment — was it uploading context from a large file? Downloading a model? Just keeping a keep-alive alive? Without that context, the number is noise wearing a data costume.

Second, and more important: TCP/IP doesn't distinguish "useful traffic" from "protocol traffic." You see bytes going back and forth, but separating how much is actual LLM call payload versus connection overhead, retries, or polling from some extension that has nothing to do with AI requires looking at finer granularity — filtering by process, by port, by destination IP — something Sniffnet allows but demands active work from whoever's looking. It doesn't come pre-solved.

The classic counterexample: someone runs Sniffnet, sees their editor with AI extensions generating constant traffic even when they're not typing code, and concludes "the agent is doing something weird in the background." It could be extension telemetry, a connection heartbeat, or just the editor syncing config to the cloud — nothing related to the AI agent itself. The tool hands you the raw data. The correct interpretation is something you have to earn.

Decision Matrix: When to Use Sniffnet for This

What I'd check first, before drawing any conclusion: which processes show up in the active connections list when the agent is idle (not processing anything) versus when you throw it a big refactor task. That comparison — idle vs. active — tells you more than staring at one isolated number.

If you're already running Cline in autopilot mode with defined limits, this kind of network observation is a reasonable complement: it doesn't replace the autonomy limits you set on the agent, but it gives you visibility from an angle that's usually ignored — the network layer, not the agent's behavior layer.

flowchart LR
  A[Cline running] --> B{Active task}
  B -->|yes| C[LLM API call]
  B -->|no| D[Possible keep-alive or polling]
  C --> E[Sniffnet: see bytes and destination]
  D --> E
  E --> F{Known context?}
  F -->|yes| G[Valid conclusion]
  F -->|no| H[Needs more capture sessions]

Limits: What This Evidence Doesn't Let You Conclude

I have to be honest about what Sniffnet, used in a single observation session, can and can't give you:

• You can't conclude how much traffic "is normal" without a series of repeated measurements across different use scenarios. A one-off capture is a data point, not a trend.
• You can't separate AI traffic from other tools' traffic just from the general graph. You need to filter by process or port, and that depends on the OS exposing that association correctly — in some containerized environments or with a VPN, the process-connection association gets lost.
• It doesn't measure token cost or model latency. Network bytes and LLM tokens are different magnitudes: a short request in bytes can represent a long, expensive prompt, and vice versa.
• It doesn't replace application logs. If you want to know exactly which call to which endpoint corresponds to which agent action, the source of truth is the tool's log (Cline, the LLM provider's CLI), not the network sniffer.
• A single capture session isn't a reproducible experiment in the strict sense. To draw a conclusion worth publishing you'd need to repeat the observation under comparable conditions, something this post doesn't do and doesn't claim to.

That said: the point of installing the tool isn't to get a final figure, it's to open up a layer we normally never look at. I already went down something similar when I compared pnpm and npm on install friction or when I questioned how cheap an agent like DeepSeek Reasonix actually is in practice: the habit of looking closely at things we use every day but never actually examined.

FAQ

Does Sniffnet need admin permissions? Yes, because it uses pcap to capture packets at the network interface level. On Linux you can grant specific permissions with setcap instead of running it as root directly, which is the recommended approach for security.

Can Sniffnet see the content of my conversations with an LLM? No. Traffic between Cline (or any client) and an LLM API goes encrypted via TLS. Sniffnet sees that there's a connection, which IP or domain it's going to, how many bytes get transferred — not the payload content.

Is it useful for measuring how much I spend on tokens? Not directly. Network bytes don't equal LLM tokens. For actual token cost you need to check the provider's dashboard or the usage logs of whatever tool you're using.

Is it better than Wireshark for this case? Depends on your goal. Wireshark has more protocol analysis depth and is the standard for advanced diagnostics. Sniffnet aims for a quicker, more visual read of the overall traffic picture by application, without Wireshark's learning curve.

Can I use Sniffnet on macOS or only on Linux? It's cross-platform: supports Linux, macOS, and Windows according to the project's GitHub documentation.

Does this replace real observability in a production system? No. It's a local inspection tool, meant for a dev machine. For network observability in production systems there are other layers — aggregated metrics, distributed tracing, infrastructure tools — that aren't the goal of this experiment.

My Take

Installing Sniffnet didn't give me a magic number of "this is what your AI agent spends on network." It gave me something smaller and more honest: the ability to look, whenever I want, at which process is talking to which destination on my machine while I've got four AI tools running at once. That's already more than I had before, which was zero visibility.

What I'd do differently if someone wants to draw a serious conclusion from this: not a five-minute capture, but repeated sessions — idle agent, agent with a small task, agent with a big refactor task — comparing the graphs against each other. That's where the data starts to mean something. A single snapshot of traffic is barely curiosity; a series of compared snapshots is where judgment actually starts.

If you work with local AI agents daily and never looked at the network layer, the logical next step isn't to draw conclusions from one run. It's to install the tool, watch it for a week, and only then decide if there's something worth digging into further.

Original source:

• Sniffnet GitHub: https://github.com/GyulyVGC/sniffnet</content>