Why CPU Sampling Isn't Enough: Failure Modes of Process-Level Activity Detection for Local AI Tools
Using CPU time deltas and a hysteresis state machine to detect local AI tool activity — with four honest failure modes.
The open-source project Forkit AI Footprints tackles activity monitoring for local LLM tools like Ollama and LM Studio with a privacy-first approach: sampling process trees every second and using cumulative CPU time deltas to detect real computation, with an asymmetric hysteresis state machine (2 positive samples to enter Working, 3 negative to return to Ready) to suppress false positives. It deliberately separates "runtime available," "model loaded," and "measured activity" into distinct states. The author honestly lists four failure modes — background agents, Electron helper noise, untracked spawned process trees, and the fundamental blind spot of GPU-intensive but CPU-idle workloads — and explicitly states that detected activity does not imply task completion, token usage, or productivity.
The Core Problem Nobody Talks About: Process Presence ≠ Actual Work
As local LLM tools like Ollama and LM Studio become more widespread, figuring out how to monitor their real activity without invading user privacy has become a genuinely tricky engineering challenge in the developer tooling space. Recently, a developer shared their open-source macOS observability experiment, Forkit AI Footprints, on Reddit. The focus wasn't so much on the product itself, but on a methodology for process-level activity detection that's worth studying.
The core pain point is straightforward: Process presence is not activity. An AI tool's process might linger in the system indefinitely, sitting idle for the vast majority of that time. Relying solely on whether a process is running to determine "whether AI is working" generates a flood of false positives. The author also drew a deliberate privacy boundary — no inspection of prompts, source code, or any application content — which constrains the problem entirely to system-level signals.
The Detection Mechanism: CPU Time Delta Sampling
Given the constraint of not peeking at content, the author chose a relatively conservative technical path: sampling supported process trees once per second and observing cumulative CPU time deltas. This is a classic "black box" observation approach — it doesn't care what the process is doing internally, only whether it's consuming computational resources.
Hysteresis in the State Machine: The Key to Reducing False Positives
To avoid rapid state flapping, the author introduced a state transition model with hysteresis — arguably the most noteworthy engineering detail in the entire design:
- Entering the "Working" state: requires two consecutive positive samples
- Returning to "Ready" state: requires three consecutive negative samples
This asymmetric threshold design is deliberate: it's easier to confirm "currently working" (2 hits) but more conservative about declaring "now idle" (3 hits), reducing false "task completed" signals caused by brief pauses. The author also excludes lock screen, sleep, and extended idle time windows from the effective observation window, preventing system state changes from polluting the measurements, while also filtering out Forkit's own process activity.
State Separation: Refusing to "Collapse" States for Better Measurement Accuracy
Another key design decision is layered handling of Ollama/LM Studio evidence. The author deliberately avoids collapsing these three distinct states into one:
- Runtime available
- Model loaded
- Measured AI tool activity
This distinction reflects a rigorous measurement philosophy — "model is loaded" and "model is actively inferencing" are completely different facts. Conflating them would seriously mislead users about the actual working state of their AI tools.
The "We Don't Interpret This" Boundary: A Philosophy of Restraint
The most admirable aspect of this project is the author's clear-eyed awareness of the limits of the measurements. They explicitly state that detected "activity" does not represent any of the following:
- Prompt ownership
- Task completion
- Token consumption
- GPU workload
- Energy consumption
- Productivity
This restrained disclaimer is, in effect, an implicit critique of many "AI usage monitoring" tools on the market. Many products tend to translate "CPU is busy" directly into "AI is working efficiently" or even "developer is being productive" — a classic case of over-interpretation. The author chose to report only what is measurable, leaving interpretation to the user. That scientific attitude is genuinely rare in developer tooling.
Four Failure Modes: Real Engineering Honesty
The author proactively documents the scenarios their current approach fails to handle and invites community input on improvements. This kind of candor is especially valuable in open-source projects:
1. Background Agents
An increasing number of AI coding tools use persistent background agent architectures. The activity patterns of these processes may be completely decoupled from foreground interactions, making CPU sampling an unreliable attribution method.
2. Electron Helper Process Noise
Electron-based applications spawn numerous helper processes whose CPU activity may stem from rendering, networking, and other tasks entirely unrelated to AI inference — creating false positives.
3. Spawned Process Trees
Tools may dynamically fork child processes to perform actual computation. If the detector fails to track the full process tree, it will miss real activity.
4. GPU-Intensive but CPU-Quiet Workloads — The Fundamental Blind Spot
This is the most critical detection gap: local LLM inference relies heavily on the GPU. When a model is running at full speed on the GPU, the CPU may be quite idle. A detector based on CPU time deltas will systematically underreport in this scenario — and this is precisely the most typical working mode for local AI inference.
Technical Takeaways and Open-Source Value
The project is open-sourced under the MIT license at github.com/arpitasarker01/forkit-ai-footprints, with a zero-install way to try it:
npx --yes forkit-ai-footprints@latest
Zooming out, this experiment touches on a real observability challenge of the local AI era: how do you build a trustworthy activity profile for distributed local inference workloads, while keeping privacy first? As models move to the edge, traditional cloud API metering approaches gradually become irrelevant, while process-level observation runs into its own set of technical bottlenecks — CPU/GPU attribution, process tree tracking, and more.
What the author demonstrates isn't just a detector — it's a development paradigm worth learning from: define your constraints clearly, design state machines with hysteresis, refuse to collapse state, and honestly enumerate your failure modes. For anyone building observability systems for developer tools, this "failure modes checklist" alone is a valuable reference. The next step likely requires incorporating GPU utilization, energy consumption signals, and other multi-dimensional evidence into the observation stack to build a more complete picture of local AI tool activity.
Related articles
Insufficient Source Material to Generate a Valid Article
The provided source material is a single unrelated tweet with no AI or tech relevance — insufficient to support a complete, valid technical article.
Insufficient Source Material to Generate a Valid AI/Tech Article
This source material is a tweet about the ages of Underworld members — unrelated to AI or tech, and insufficient to support a full article.
Insufficient Material: Unable to Generate a Valid AI/Tech Article
The provided material is a condolence tweet about a San Diego mosque attack — unrelated to AI/tech and too limited to generate a valid technical article.