[Feature Request] Native macOS menu-bar observability for inference workloads

Problem

The native macOS menu-bar popover currently exposes CPU, GPU, memory, load average, uptime, and ProcessInfo.thermalState. For long-running, GPU-intensive inference workloads, this still leaves an important observability gap: Nominal is a categorical thermal-pressure state, not a temperature reading.

As a result, users who want to notice sustained heat, fan activity, cache pressure, or unusual I/O while oMLX is serving models must run a second system-monitoring app such as AirStats or iStat Menus alongside oMLX.

The goal is not to turn oMLX into a general-purpose system monitor. The goal is to make the native app a useful operational surface for the machine resources most relevant to local inference.

Proposed feature

Add three independently opt-in metric groups to Settings → Appearance → Menu Bar Items and the existing System Stats popover.

1. Thermals and fans

• Keep the existing thermal-pressure state (Nominal, Fair, Serious, Critical).
• Add sensor-derived CPU and GPU temperature values in °C where available.
• Show fan speed in RPM and handle fanless or zero-RPM Macs correctly.
• Document the aggregation used for multiple sensors (for example, mean or maximum); do not present an aggregate as a single authoritative die temperature.
• Display unavailable or unsupported readings as —, never as zero.

macOS does not provide a documented public API for these readings. A read-only AppleSMC implementation through IOKit appears technically possible and could use the MIT-licensed AirStats implementation as a reference, subject to maintainer approval and preservation of the required license notice.

2. oMLX runtime-cache telemetry

Reuse the existing runtime_cache data returned by /admin/api/stats; do not scan ~/.omlx/cache from the UI.

Useful values include:

• hot-cache and SSD-cache usage versus configured limits;
• entry/file counts;
• hits, misses, loads, saves, evictions, errors, and SSD write drops/fallbacks.

A compact CACHE/SSD occupancy bar would fit the existing combined status-item design, while detailed counters and short bounded history can live in the popover.

3. Host network I/O

• Show RX/TX rates for active non-loopback interfaces.
• Label the metric clearly as system-wide, not oMLX-only and not MCP-specific.
• Treat per-MCP tool metrics as a separate future feature. Depending on the transport, network traffic may occur in an MCP child process or in the client and therefore cannot be attributed reliably by oMLX.

If MCP observability is added later, call count, latency, and error rate would be more reliable than inferred byte counts.

Suggested UI behavior

• Extend the existing SystemStatKind, stats snapshot, panel stack, and Appearance toggles rather than introducing a separate monitor window.
• Keep every new metric group off by default.
• Use an occupancy bar for cache metrics.
• Use a compact numeric/text representation for temperature and network metrics, or make them popover-only if the combined status item would become too wide.
• Keep the existing thermal-pressure label visible because it conveys a different signal than raw temperature.

Sampling and performance constraints

The monitoring feature should remain negligible compared with the workload it observes:

• sample only while the popover is open or the corresponding menu-bar item is enabled;
• use the configured interval for inexpensive CPU/GPU/network counters;
• sample SMC thermals at a slower interval (for example, 2–3 seconds);
• poll runtime-cache stats at a slower interval (for example, 5 seconds) and avoid extra /admin/api/stats requests when disabled;
• retain only a short, bounded in-memory history and do not add a persistent telemetry database.

This is especially important in light of the previous menu-bar polling overhead discussed in #2069.

Non-goals for the first iteration

• fan control;
• automatic throttling or workload cancellation;
• per-process or per-MCP network attribution;
• persistent monitoring/history;
• replacing dedicated system-monitoring applications.

Suggested implementation sequence

To keep reviews focused, this could be split into separate pull requests after the design is accepted:

1. Runtime-cache telemetry, using data already exposed by the server.
2. Host network RX/TX using public interface counters.
3. Optional/experimental read-only SMC temperature and fan telemetry, if maintainers accept the undocumented API and maintenance cost.

Relationship to existing work

#1604 proposes a broader resource-monitoring tab in the web admin dashboard. This request is complementary rather than a duplicate: it targets the native macOS menu-bar surface, includes temperature/fan details, and is designed for quick observation during local inference.

Questions for maintainers

1. Is read-only AppleSMC access acceptable in the native app despite the protocol being undocumented?
2. Should temperature/fan telemetry initially be marked experimental and remain off by default?
3. Is the staged PR sequence above preferable to a single implementation?
4. Should temperature and network rates appear in the combined status item, or only inside the popover?

Environment / motivation

• oMLX Desktop App 0.6.4 (2529)
• Apple silicon Mac
• Use case: long-running, multi-billion-parameter inference workloads where thermal state, fan response, cache pressure, and I/O are useful intervention signals