Signals and the activity model
Activity levels 0-3 correlated from foreground, CPU, connections and bandwidth; and how per-app bandwidth works and its limits.
What each app reports
For every tracked application the agent reports whether it is running, its version and owner, and usage signals: an activity level, how long it was actively used, how many network connections it held, and how much bandwidth it moved. These are correlated from four independent observations: the foreground window, CPU, open TCP connections, and per-connection bandwidth.
The activity-level matrix
The activity level grades how an app is being used, not merely that it is open. It is the single most important signal for usage economics — "installed" is cheap to know; "focused for two hours a day" is what tells you a seat is worth its cost.
| Level | Label | Condition | Servers reach it? |
|---|---|---|---|
| 3 | Focused | Owns the foreground window (Windows) | No (no foreground) |
| 2 | Background-active | Summed CPU above ~1% | Yes |
| 1 | Network-active | At least one established TCP connection, or bandwidth moving in the current interval | Yes |
| 0 | Idle / not running | None of the above | Yes |
On servers there is no foreground window, so the Machine Agent tops out at level 2.
Bandwidth: how, and its limits
Per-application bandwidth is collected on both platforms as of v0.3.0. On Windows the agent uses the operating system's extended TCP statistics (ESTATS): it enables per-connection byte counters on each established IPv4 and IPv6 connection owned by a tracked process and accumulates the change since the last reading — this is why elevation matters. On Linux the kernel's per-socket tcp_info counters are read via ss (iproute2) and mapped to the tracked processes; this works fine as the root systemd service.
| Environment | Behavior |
|---|---|
| Windows, elevated | Full per-app rx/tx bandwidth (IPv4 + IPv6) |
| Windows, not elevated | One warning, then bandwidth reports 0 (everything else works) |
| Linux (root service) | Full per-app rx/tx bandwidth via kernel tcp_info; degrades to 0 with one log line if ss is unavailable |
Accuracy semantics, on both platforms: the figures are TCP only — UDP flows (including QUIC / HTTP-3, which browsers and conferencing tools use heavily) have no per-socket byte accounting, so treat bandwidth as a lower bound of real network use. Loopback-to-loopback traffic is excluded (local IPC is not network bandwidth), and the first sample after a restart is a baseline that reports zero rather than mis-attributing a long-lived connection's lifetime bytes to one tick.
Note: Bandwidth separates "a cloud-sync client sitting idle" from "a cloud-sync client actually moving gigabytes". Two apps at CPU-idle can have very different real footprints; bandwidth distinguishes them, and it is a strong signal for both cost (egress-priced services) and data-exfiltration risk.