SiliconScope: a sudoless Apple Silicon monitor that reads the Neural Engine and Media Engine

The gap SiliconScope targets: accelerators that Activity Monitor does not name

Activity Monitor reports CPU, GPU and memory. It does not report the Neural Engine, the Media Engine, or memory bandwidth against the chip's ceiling. That omission matters most to one specific group: people running local models on a Mac. When LM Studio or Ollama generates tokens, the question is not whether the machine is busy, it is which accelerator is busy and whether the bottleneck is compute or bandwidth. The README's own dashboard screenshot makes the case in one frame: an M1 Max under an LM Studio load, the workload classifier reading ANE (CoreML), GPU at 97 percent and 39 W, memory bandwidth at 223 GB/s against a stated 400 GB/s ceiling, and the CPU card outlined red because the P-cluster is thermally throttled at 2272 of 3228 MHz. Those are four different subsystems in one view. SiliconScope is for the person who wants that view, not for someone who just needs a CPU percentage in the menu bar. The secondary audience is anyone with more than one machine under a desk, which is what the 4.0 Fleet feature addresses.

How the sudoless constraint shapes what SiliconScope can read

The defining design choice is in the tagline: sudoless. No privileged helper, no root prompt. That constrains the data sources. Temperature readings come from SMC keys curated per chip generation, M1 through M5, with a HID fallback where those keys do not resolve. The README states the fallback exists but does not say what the HID path reports or how it differs in granularity from the curated keys, which is the first thing I would want to confirm on a given machine. The per-unit breakdown (E-Core, P-Core, GPU, Memory sensors) appears in the Sensors dropdown, and the material implies that breakdown is what the curated keys buy you. Metrics are recorded continuously, which is what makes the Replay scrubber possible: the README describes scrubbing back through a session like a DVR. That is a real architectural commitment, since it means the app is persisting a time series rather than sampling for display only. The remote path is separate: a small agent runs on the other machine and joins the dashboard over what the README calls an encrypted, paired connection, with TLS and token authentication and certificate pinning on first connect. Remote Macs get the full treatment including ANE; a Linux/NVIDIA box gets a GPU-centric view with utilization, VRAM, power against the card's limit, temperature, VRAM-holding processes, and loaded Ollama models.

Install paths: a signed app for this Mac, a shell script for the fleet

The local app is a macOS 14+ Apple Silicon application, so installation is the ordinary route of downloading a release from the repository. The remote agent is where commands appear. The README gives one line for every platform, described as systemd on Linux and a LaunchAgent on macOS:

curl -fsSL https://raw.githubusercontent.com/kennss/SiliconScope/main/scripts/install-agent.sh | sh

The README notes that the Mac agent needs no sudo, so the install completes unattended over ssh. That is the practical payoff of the sudoless design: you can push it to a headless Mac mini without an interactive session. Two things about this are worth stating plainly. First, piping a remote script into sh is a trust decision, and the README does not document what the script writes or where beyond the systemd unit and LaunchAgent it mentions. Second, LAN discovery uses mDNS, so machines on the local network appear without IP configuration; anything off-LAN has to be reached another way, and the material does not describe that path. Pairing is where the security model lives: the viewer pins the agent's certificate on first connection, so a re-keyed or spoofed agent is refused rather than silently trusted. Certificate pinning plus routine key rotation is a known friction point, and the README does not describe a re-pairing flow.

The benchmark feature is narrower than it first looks

SiliconScope includes an on-demand benchmark labelled Measure tok/s. According to the README, it runs one short generation and reports the model's decode speed and energy efficiency as tokens/sec and tokens/Wh, stored per model. One short generation is a small sample. Decode rate on a Mac varies with prompt length, context size, thermal state and what else is running, and a single run captures none of that variance. The feature is best read as a quick sanity check on a model you just loaded, not as a comparative benchmark methodology. The Fleet view uses the same idea differently: each tile shows the decode rate its runtime measured and how long ago, and a rate dims once it stops describing the present. That staleness indicator is the more useful design, because it tells you when a number has stopped meaning anything. The README also invites users to post measured tok/s in Discussions for a crowd-sourced per-chip table. Self-reported numbers from unknown configurations are not a controlled dataset, and I would treat that table as anecdote rather than reference.

Where SiliconScope is the wrong tool

The sudoless constraint has a cost, and the README is honest about one instance of it. For a fanless remote Mac, the Sensors card reports fanless rather than inventing a fan reading, and the README's phrasing is that cards a wire agent cannot fill are omitted, not faked. That is the right call, but it means the remote view is not the local view: some cards simply will not be there. The same logic applies to any metric that requires privilege the app does not have. The platform floor is macOS 14 on Apple Silicon, so Intel Macs and older systems are out entirely, and the topics list confirms the Apple Silicon focus. The Linux side is explicitly GPU-centric: the README says it does not pretend a 3090 has E-cores, which is correct, but it also means a Linux box is not monitored as a general system, only as a GPU host. Finally, this is a GUI application with a menu-bar suite. If your workflow is a headless server with no GUI session and no interest in a dashboard, SiliconScope's local half does nothing for you, and the remote agent is only useful paired with a viewer running somewhere with a display. Anyone wanting a scriptable CLI for a build pipeline should look elsewhere.

How it compares to iStat Menus and terminal monitors

The README positions SiliconScope against two things: Activity Monitor and terminal monitors on one side, and iStat Menus on the other, saying it has grown into a daily-driver monitor that can stand in for iStat Menus. The difference in approach is the metric set, not the menu-bar ergonomics. iStat Menus is a general system monitor with a long history and broad hardware coverage; SiliconScope is narrower and deeper on Apple Silicon accelerators, which is why ANE, Media Engine and memory bandwidth appear as first-class cards rather than as absent readings. Against terminal monitors, the difference is the sudoless native GUI plus the Replay recording, which a typical terminal sampler does not keep. The honest framing is that SiliconScope is competing on a specific axis: if you never run on-device AI or media workloads, the accelerators it tracks are idle and the extra depth buys you little. If you do, the ANE and bandwidth readings are the reason to switch. The menu-bar suite covers CPU, GPU, Memory, Network, SSD, Sensors and Battery, each pinnable to its own item with its own style and reading selection, including the same metric appearing twice in different forms. That is comparable ground to iStat Menus; the accelerator cards are where the two part company.

Maintenance, licensing and what the release cadence implies

SiliconScope is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the whole of it; I am not giving legal advice, and anyone embedding the code in a product should read the LICENSE file rather than this paragraph. The maintenance picture from the supplied material: the repository is not archived, the last push is dated 2026-09-10, and the recent releases are v4.2.0 on 2026-09-04, v4.1.3 on 2026-08-10 and v4.1.2 on 2026-08-09. That is a steady cadence with patch releases arriving close together, which suggests active bug-fixing rather than a dormant project. The upgrade cost that matters here is not code, it is data coverage: the Sensors feature depends on curated SMC keys per chip generation spanning M1 to M5, so each new Apple Silicon generation is a maintenance obligation for the maintainer, and a machine whose keys are not yet curated falls back to HID. The Fleet protocol is the other moving part, since viewer and agent have to stay compatible across versions, and the README does not state a version-negotiation policy. The README is translated into German, Simplified Chinese, Traditional Chinese, Japanese and Korean, which is a real ongoing translation cost for a small project. None of this is a reason to avoid the tool. It is a reason to check the release notes before upgrading a fleet, because the agent and the viewer are two halves of one protocol.

Editorial conclusion

Adopt SiliconScope if you run local inference on a Mac (LM Studio, Ollama, MLX, llama.cpp) and want to see whether the ANE, GPU or Media Engine is actually carrying the workload, or if you want one dashboard over a headless Mac mini and a Linux GPU box without sudo. Do not adopt it if you are on Intel Macs or pre-macOS 14, or if you need a headless CLI that runs on a machine with no GUI session. Verify three things before relying on it: which SMC keys your chip generation resolves to and whether your temperature readings come from curated keys or the HID fallback, whether the agent installer's shell script is acceptable in your environment, and whether the Fleet agent's pinned-certificate model fits your key rotation practice.

Official sources

1. kennss/SiliconScope on GitHub
2. License: MIT
3. Project website
4. README
5. Releases