Per-app bandwidth
Which app is moving the bytes, right now.
A rate on its own tells you that something is happening. It does not tell you what. Pinned breaks the live figure down by process, so "why is my connection busy" has an answer rather than a suspicion.
The panel itself, rendered from the running app. It carries the live rates, the chart, your totals, the cap and its forecast, and the processes moving the bytes, in the language you read.
Fig. 2 / by process
Measured on the developer's Mac
- cloudflared 4.42 GB
- claude 163.1 MB
- node 54.6 MB
- mongod 52.2 MB
The usual way to attribute traffic to a process is to install a privileged helper. The commercial alternative ships a root LaunchDaemon: it loads when your Mac loads, and it stays resident whether or not you ever open the menu. That is a permanent piece of your system, running as root, in exchange for a list you glance at now and then.
Pinned does not do that. Per-app attribution runs inside the sandbox, in the app itself. No privileged helper, no root daemon, no admin password, and no permission prompt at any point.
The cost model follows from that. Pinned samples per app at a 3 second floor while the panel is open. Close the panel and the work stops unless an enabled app-rate alert needs it; that one watcher samples every 10 seconds. With no such alert, there is no background per-app sampler.
What it costs
Two limits worth stating plainly. A 3 second poll cannot see a transfer that starts and finishes between two samples, so a short burst can be missed entirely. And per-app figures are gathered at the socket level, which means they do not sum exactly to the interface total.