SiliconScope: a sudoless Apple Silicon monitor that tracks the Neural Engine and memory bandwidth
Sudoless Apple Silicon system monitor (native SwiftUI GUI) with ANE / Media Engine / memory-bandwidth tracking
At a glance
- What is it?
- SiliconScope is a native SwiftUI dashboard and menu-bar suite for macOS 14+ on Apple Silicon that surfaces ANE, Media Engine and memory-bandwidth readings Activity Monitor does not show, and can fold remote Macs and Linux GPU boxes into the same view. The trade-off is that it is Apple Silicon only, the remote agent is installable from a curl pipe, and the README documents no rollback path for it.
- Who is it for?
- Adopt SiliconScope if you run local LLM or media workloads on an Apple Silicon Mac and want to see whether the Neural Engine, GPU or memory bandwidth is the constraint, or if you want one pane for a headless Mac and a Linux GPU box. Do not adopt it if you need Intel Mac support, a package-manager install, or a documented agent uninstall path, none of which the README provides.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What SiliconScope measures that Activity Monitor does not
The README frames the project around a gap: Activity Monitor and terminal monitors do not surface the Apple Silicon accelerators. SiliconScope's stated purpose is to let you see how on-device AI and media workloads drive the Neural Engine (ANE), the Media Engine and memory bandwidth. The dashboard screenshot in the README shows an M1 Max running LM Studio on a model called gemma-4-12b: the workload classifier reads ANE (CoreML), the GPU sits at 97 percent and 39 W, memory bandwidth reads 223 GB/s against the chip's 400 GB/s ceiling, and the CPU card is outlined red because the P-cluster is thermally throttled at 2272 of 3228 MHz. Those four readings in one view are the product's reason to exist. The audience is narrow and specific: people running llama.cpp, Ollama, LM Studio or MLX locally who need to know whether a slow generation is a GPU limit, a bandwidth limit or a thermal limit. It is not a general-purpose system monitor for a MacBook Air owner who wants to know why the fan spins, though the menu-bar suite covers CPU, GPU, memory, network, SSD, sensors and battery as well.
How the dashboard, menu bar and Replay work together
The app is a native SwiftUI dashboard plus a menu-bar suite, and the README describes both as sudoless, meaning no privileged helper is installed to read the metrics. Any card can be pinned to its own menu-bar item (CPU, GPU, Memory, Network, SSD, Sensors, Battery), and each item picks its own style: bars, history graph, two lines, a single value or an icon. A metric can appear twice, so CPU can be bars in one item and a graph in another. The Sensors dropdown uses curated SMC keys per chip generation, M1 through M5, with a HID fallback elsewhere, and the README notes it reports E-Core, P-Core, GPU and Memory temperatures. Replay, introduced in 3.0, records every metric so a session can be scrubbed backwards like a DVR. The benchmark feature is separate and on-demand: a "Measure tok/s" action runs one short generation and stores decode speed and energy efficiency, tokens per second and tokens per Wh, per model. Version 4.0 adds Fleet. Machines on the same LAN are discovered over mDNS with no IP configuration; a remote Mac renders in the same dashboard as the local one, including ANE, while a Linux/NVIDIA box gets a GPU-centric view with utilization, VRAM, power against the card's limit, temperature, VRAM-holding processes and any Ollama models loaded. The README states that cards a wire agent cannot fill are omitted rather than faked, and that a fanless Mac reports fanless instead of inventing a fan reading.
Installing SiliconScope on macOS and running a first benchmark
The README does not give a Homebrew command or a direct download URL for the app itself. It advertises a website at siliconscope.calidalab.ai and links GitHub releases, and the platform badge states macOS 14+ on Apple Silicon, so the app is obtained from the release page rather than from a package manager. Once it is running, the first concrete action the README describes is the on-demand benchmark, which runs one short generation and reports the model's decode speed and energy efficiency. The README gives no CLI for this, so it is a control in the GUI: the menu-bar GPU / Media / Neural dropdown shows GPU, GPU memory, ANE and Media as live meters plus a four-line 60-second trend, and the benchmark is described as an action labelled "Measure tok/s". The README does not document the command-line form of that action, so treat the label as the GUI control it is.
To add a remote machine, the README gives one installer URL for every platform, systemd on Linux and a LaunchAgent on macOS:
curl -fsSL https://raw.githubusercontent.com/kennss/SiliconScope/main/scripts/install-agent.sh | shThe README states the Mac agent needs no sudo, so the command finishes unattended over ssh. On the viewer side, LAN machines are discovered automatically over mDNS, so no IP configuration is needed. The README says every connection is TLS-encrypted and token-authenticated, and that the viewer pins the agent's certificate the first time it connects, so a re-keyed or spoofed agent is refused rather than silently trusted. The README does not document what the installer writes to disk beyond the LaunchAgent or systemd unit, and it documents no uninstall command.
Where SiliconScope stops being the right tool
Three constraints are visible in the README and worth stating plainly. First, the platform badge reads macOS 14+ and Apple Silicon, so an Intel Mac is out of scope, and the accelerator cards that justify the project (ANE, Media Engine, per-generation SMC keys) do not exist there. Second, the remote Fleet feature has an asymmetric install story: the agent ships as a shell script piped from raw.githubusercontent.com into sh, and while the README explains the transport security, it documents no uninstall path and no checksum for the script. An engineer who cannot pipe an unreviewed script into a shell on a production box should download the script, read it, and run it locally, or skip Fleet. Third, the remote Linux view is deliberately partial. The README says a Linux/NVIDIA box gets a GPU-centric view and does not pretend a 3090 has E-cores, which is honest, but it also means you cannot use SiliconScope to compare CPU or memory behaviour across a mixed fleet. On the Mac side, the README's own example shows the workload classifier reading ANE (CoreML) for an LM Studio generation; if your runtime does not expose that signal, the ANE card is likely to be less informative than the GPU and bandwidth cards.
SiliconScope versus iStat Menus and Activity Monitor
The README positions SiliconScope against iStat Menus by claiming it can stand in for it as a daily-driver monitor, and against Activity Monitor by claiming it surfaces accelerators that Activity Monitor does not. The difference in approach is scope rather than polish. iStat Menus is a long-established general system monitor for macOS; the README does not describe SiliconScope as replacing its sensor coverage or its history depth, only as covering the same menu-bar ground while adding ANE, Media Engine and memory-bandwidth readings. Activity Monitor is the system tool, and the README's argument against it is specific: it does not show the Neural Engine or memory bandwidth against the chip's ceiling. For someone debugging a local model's throughput, that is the whole argument. For someone who wants a general Mac health monitor with a long track record, the comparison is less favourable, because SiliconScope's distinguishing cards are the ones a general monitor has no reason to draw.
Maintenance, licence and the cost of keeping up
The repository is not archived and the last push was on 2026-09-10, which is recent enough that the project looks maintained by its release cadence: v4.2.0 on 2026-09-04, v4.1.3 on 2026-08-10 and v4.1.2 on 2026-08-09. That cadence is the main signal available here, and it suggests a project that ships fixes rather than one that has gone quiet. The upgrade cost is the interesting part. The README says Sensors uses curated SMC keys per chip generation, M1 through M5, with a HID fallback elsewhere, which means each new Apple Silicon generation is a maintenance event for the project, not something that works automatically. The same applies to the Fleet protocol, where the viewer pins the agent's certificate on first connect: a re-keyed agent is refused rather than silently trusted, which is the right default but also means a certificate change on the agent side is a reconnect-and-verify step for you. The licence is MIT, which permits commercial and closed-source use and requires only that the copyright notice and permission notice be included in copies or substantial portions. That is a permissive licence, not legal advice, and if you redistribute the app inside a product you should read the LICENSE file in the repository rather than this summary.
Editorial conclusion
Adopt SiliconScope if you run local LLM or media workloads on an Apple Silicon Mac and want to see whether the Neural Engine, GPU or memory bandwidth is the constraint, or if you want one pane for a headless Mac and a Linux GPU box. Do not adopt it if you need Intel Mac support, a package-manager install, or a documented agent uninstall path, none of which the README provides. Before installing, open the v4.2.0 release page and check the asset you download; before running the agent installer, read scripts/install-agent.sh in the repository and confirm the LaunchAgent or systemd unit it writes matches your machine.
Frequently asked questions
How do I install SiliconScope on macOS?
The README does not give a Homebrew or package-manager command; it points to the website at siliconscope.calidalab.ai and to GitHub releases, and the platform badge states macOS 14+ on Apple Silicon. Download the app from the release page rather than expecting a package manager.
Does SiliconScope need sudo to read the Neural Engine and sensors?
The README describes the project as a sudoless Apple Silicon system monitor and says the Mac agent needs no sudo. That is the claim the project makes for both the local app and the remote agent.
Can SiliconScope monitor a remote Mac or a Linux GPU box?
Yes, through the Fleet feature added in 4.0. A remote Mac renders in the same dashboard as the local one including ANE, while a Linux/NVIDIA box gets a GPU-centric view with utilization, VRAM, power, temperature, VRAM-holding processes and any Ollama models loaded.
What does SiliconScope measure that Activity Monitor does not?
The README states that Activity Monitor and terminal monitors do not surface the Apple Silicon accelerators, and that SiliconScope tracks ANE (Neural Engine), Media Engine and memory bandwidth. The README's example shows memory bandwidth against the chip's ceiling, such as 223 GB/s of a 400 GB/s limit on an M1 Max.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/kennss-siliconscope)