TMOG Brings Dave Plummer’s Task Manager to Mac and Linux—and Can Track Local AI Load

TMOG Brings Dave Plummer’s Task Manager to Mac and Linux—and Can Track Local AI Load

Updated September 22, 2026

Dave Plummer, the engineer known for creating the original Windows Task Manager, has released TMOG, a cross-platform system monitor for Windows, macOS, and Linux. Its current website describes a native application for each platform, backed by a shared measurement core. The tool surfaces live processes, CPU, memory, disk, network, and energy use, with paid features for recording and replaying system telemetry.

That makes TMOG relevant to people experimenting with local AI models and agent workflows. A model running on a computer can make fans spin up, consume memory, generate disk activity, or communicate with cloud services. A process monitor can help identify which application is using those resources. It cannot tell whether the model’s answer is correct, whether an agent completed a task well, or how much a cloud API charged.

The product is currently in beta, according to its website. It offers a free version and a paid Pro tier. Because the product page is the vendor’s own description, its capability claims should be treated as product specifications rather than independent test results.

What TMOG is designed to show

The product page describes 12 areas, including system summary, performance, processes, system information, startup applications, users, services, power and frequency, network connections, installed applications, disk space, and benchmarks. Its process view is intended to help users connect symptoms such as heat, lag, fan noise, or battery drain to the software and subsystem responsible.

This can be useful when a computer feels slow but the cause is unclear. A browser with dozens of tabs, a background update, a video editor, a local model, or a sync client can compete for the same resources. Seeing which process is consuming CPU or memory helps narrow the investigation before a user starts closing programs at random.

TMOG also says it distinguishes a measured zero from unavailable data and leaves gaps when sampling stops. That is a meaningful principle for monitoring software: missing data should not be drawn as if it were a real measurement. Users should still test how the application represents unavailable sensors on their own hardware and confirm which metrics are supported by their operating system.

Why this matters for local AI

Running a model locally can create resource pressure that is difficult to diagnose from an AI interface alone. The visible chat window may respond slowly because the model process is using memory, a second application is consuming CPU, storage is close to full, or the machine is throttling under heat. A system monitor adds another layer of evidence.

For an AI agent that runs multiple tools, process information can also clarify where work is happening. A local browser, Python runtime, vector database, model server, or media processor may each consume resources. Identifying the active process helps a developer find bottlenecks and distinguish local computation from network calls.

There are important limits. Process monitors do not show the semantic quality of a model, the reasoning behind an answer, or whether a browser agent actually completed the user’s task. They also do not calculate cloud API charges, which are determined by provider-side usage and billing rules. Network activity may show that data is being transferred, but not necessarily what the request cost or what was sent.

A developer evaluating local inference should pair resource telemetry with application-level logs. Record model name and version, input size, completion time, memory use, and output quality. If cloud services are involved, separately check the provider’s usage dashboard and invoice. These sources answer different questions and should not be combined into one vague performance score.

Cross-platform design and beta status

TMOG’s site describes a native implementation on each operating system: Swift and AppKit on macOS, C++ and Win32 on Windows, and C++ with Qt 6 on Linux, built around a shared C++20 measurement core. The goal is a consistent monitoring concept across platforms while preserving native interfaces and system-specific measurements.

That approach could appeal to users who move between computers or support teams with different operating systems. But “cross-platform” does not guarantee identical metrics. Operating systems expose different hardware data and permission models. A sensor may be available on one system but unavailable on another, and energy reporting can depend on the machine’s hardware.

Since TMOG is in beta, users should expect changes. Before using it to diagnose a production machine, check the supported OS versions, release notes, and known limitations. If monitoring is part of an incident investigation, preserve independent system logs too; a beta utility should not be the only source of evidence.

A simple workflow for diagnosing a local model

A measured test can make local AI troubleshooting more useful:

1. Record a baseline with no model or agent running.
2. Start one workload at a time and note CPU, memory, disk, network, and energy changes.
3. Repeat the same prompt or task with the same model and settings.
4. Record response time and whether the task succeeded separately from resource usage.
5. Compare one configuration change at a time, such as context length or quantization.
6. Save a telemetry trace if the tool supports it, and label it with the model and task.
7. Verify cloud costs in the provider dashboard rather than estimating them from system activity.

This avoids a common mistake: changing several settings at once, seeing a faster response, and not knowing which change mattered. A repeatable test can show whether the bottleneck is memory, CPU, disk, network, or the model’s own latency.

Privacy and permissions

System monitors can reveal sensitive details about a computer: running applications, active users, network connections, and work patterns. Before installing any monitor, check what data remains local, whether crash reports are sent, and whether optional telemetry can be disabled. For a workplace device, follow the organization’s software and monitoring policies.

TMOG’s product page says it is designed as a native application without an embedded browser shell and includes a self-monitoring option. That tells users something about its architecture, but it is not a substitute for reviewing the privacy policy, code-signing information, update process, or permissions requested during installation.

A useful safety practice is to install software only from the vendor’s official download page, verify the publisher and version, and use a standard account for ordinary work. If the tool asks for elevated permissions, understand why they are needed and whether the same diagnostic can be performed without them.

How it compares with built-in tools

macOS Activity Monitor, Windows Task Manager, and Linux utilities such as top or htop already show many resource metrics. For routine checks, the built-in utility may be enough. TMOG’s proposition is a common cross-platform interface, a more detailed process hierarchy, energy-oriented diagnostics, and telemetry replay features.

The Pro-only Flight Recorder feature is described as recording, saving, scrubbing, and replaying telemetry panels across operating systems. That could help when a slowdown happens intermittently and disappears before a user opens the monitor. Before relying on it, check the trace format, retention behavior, and whether recorded data could contain information about sensitive processes or network activity.

The main comparison is not whether TMOG has more panels. It is whether its presentation helps the user reach a diagnosis faster than the tools already installed. People who support several operating systems may value a consistent interface. Users who only need to close a frozen application may prefer the default task manager.

What it cannot do

TMOG is not an AI safety monitor, a malware detector, or a substitute for application logs. High CPU usage does not prove that an application is behaving badly; low usage does not prove that it is secure. Network connections shown in a process list may require additional tools to interpret.

Likewise, system telemetry cannot determine whether an AI model is biased, hallucinating, or following an instruction correctly. Those evaluations need task-specific tests and human review. Monitoring helps explain the machine’s workload, not the model’s judgment.

For businesses running agents, the most useful setup pairs system monitoring with audit logs that record the user request, tools called, files accessed, and actions completed. Resource data can explain slowness or unexpected load; application logs can explain behavior. Keeping those records separate but correlated makes troubleshooting more accurate.

Who should try it

TMOG may be useful for developers, power users, and IT staff who want a detailed process view across Windows, macOS, and Linux. People running local models can use it as one part of a performance investigation. Users who only need a quick view of CPU and memory may not need another application.

The decision should account for its beta status, supported hardware, licensing, privacy terms, and Pro features. Start with a non-critical device, run a few repeatable measurements, and compare the findings with the operating system’s built-in monitor. If it provides a clearer diagnosis, it may earn a place in the toolkit.

The broader AI connection is simple: as more inference and agent work moves onto personal computers, knowing what software consumes the machine’s resources becomes more useful. A monitor like TMOG can help answer “what is making this computer work hard?” It cannot answer “is this AI doing the right thing?” Both questions matter, and they require different evidence.

Sources and further reading

• TMOG official product and technical overview
• Apple: Activity Monitor User Guide
• Microsoft: Task Manager
• Linux top manual
• NIST AI Risk Management Framework
• NVIDIA: GPU monitoring and system management tools

Reading a trace without confusing correlation for cause

A process that rises at the same time as a slowdown may be related, but correlation alone does not prove it caused the problem. Background indexing, an operating-system update, or a model download can coincide with an AI task. Repeat the same workload under similar conditions and change only one variable at a time. Compare the trace with application logs and system temperature or power behavior where available.

For local model workloads, include idle periods before and after inference. This makes it easier to distinguish the cost of loading a model from the cost of generating a response. If the application keeps a model resident in memory, note that separately from active token generation. Those behaviors have different implications for laptop battery life and for running multiple agents at once.

Limits of measuring AI performance

A faster run is not always a better run. Changing quantization, model size, context length, or sampling settings may reduce resource use while also changing output quality. System telemetry can show the resource side of the trade-off; a task benchmark or human review must assess whether the output still meets the requirement.

Cloud and local workflows should be measured separately. A cloud agent may consume little CPU on the user’s device while doing substantial work on a provider’s servers. Conversely, a local model may use significant GPU or memory but avoid sending prompts off-device. A good comparison includes latency, quality, privacy, and total cost rather than using one process metric as a proxy for all four.