Skip to content

SiliconPulse

See what your Mac is really doing, including whether your local AI model is using the GPU.

SiliconPulse
Published product capture. A real oMLX model on a CI virtual Mac, which reports no GPU use

What was missing

Running models locally raises questions Activity Monitor does not answer: is the model on the GPU, is memory being compressed or swapped, which runner has which model loaded, and is it generating right now. Many monitors fill the gaps with numbers macOS never reported.

What we built

A lightweight native macOS monitor for Apple Silicon that shows CPU, GPU, unified memory, and the local AI models running on the Mac, with the source behind every number.

  • Overview of CPU, GPU, unified memory, memory pressure, and thermal state, with 60 s, 5 min, and 30 min charts
  • Evidence-based detection of oMLX, Ollama, LM Studio, llama.cpp, MLX, and OpenAI-compatible runners, with the loaded model, context, and model memory
  • Searchable process table with an inspector, plus memory, compute, disk, and network screens
  • A menu bar readout such as model, GPU, and tokens per second, with a compact popover

How it works

Published product capture. A real oMLX model on a CI virtual Mac, which reports no GPU use
  1. Open the app. The Overview shows CPU, GPU, unified memory, pressure, and thermal state, with any detected local model.

    Published product capture. A real oMLX model on a CI virtual Mac, which reports no GPU use
  2. Open AI Models to see each detected runner, its loaded model, context, model memory, and inference activity, with the evidence behind each detection.

    Published product capture. Test-only mock runners, labelled mock
  3. Check Memory for used, compressed, and swapped memory, and an estimated headroom before loading another model.

    Published product capture. Unified memory on a CI virtual Mac
  4. Close the window and keep the menu bar item. Its popover shows the active model, GPU, and memory at a glance.

Decisions that make it work

The engineering choices behind SiliconPulse, in plain words.

  • Every number says where it came from

    Each value is marked exact, reported, calculated, estimated, or unavailable, and hovering shows its source. When macOS does not expose something, the app shows a dash and says why.

  • A process name is not proof

    A runner only counts as detected once its own local API, listening port, or launch arguments confirm it. The app only ever talks to 127.0.0.1.

  • System GPU is never credited to a model

    System, process, and model values are kept separate, so a busy GPU is not presented as the model's work unless the runner says so.

  • Light enough to leave running

    One sampling loop serves every screen, and it slows down when the window is closed. CI measures the app's own CPU and memory on every run.

Where AI fits
SiliconPulse monitors local AI runners rather than using a model itself. It reads what each runner reports through its own local API, and never sends anything off the Mac.
What a person decides
The person chooses the sampling rate, what the menu bar shows, and which runners and screens to watch. There are no accounts, telemetry, or cloud backend.

What it makes possible

Someone running models on a Mac can see whether the model is loaded, generating, and using the GPU, and how much memory headroom is left, with every number labelled as measured, reported, or estimated.

Have a workflow that needs its own tool?

SiliconPulse started as one problem worth solving properly. Tell us about yours. We’ll shape the first useful release.

The brief asks three things

  1. What should exist?
  2. Who will use it?
  3. What’s painful about how it works today?

Ask Vlyntro

Tell us what you’re trying to build or automate.

Hi! Tell me what you’re trying to build or automate. Rough is fine. I’ll ask a question or two and help you shape a sensible first release.

Enter to send · Shift+Enter for a new line0/5,000 characters

AI replies can be wrong. Please don’t share passwords or confidential details.