System monitor · macOS
Every monitor tells you Firefox is at 14 GB, or a terminal is at 40%. Neither is something you can act on. Skopos looks inside the app and names the actual piece of work, down to the tmux pane or the background job. It does the same for CPU, memory, disk, paging, wake-ups and network.
macOS first. Windows, Linux, iOS and Android close behind.
Attribution
macOS groups a tmux server with the terminal that launched it, even
after the session detaches and the process is handed to launchd. So a
stray claude still roots under iTerm, while its own row
names the pane, the command and the working directory it's running in.
Browsers get the same treatment, split by what each child process is for: content, GPU, networking. The answer stops being a number you can't use and becomes a place you can go.
Where Activity Monitor shows iTerm at 40%, Skopos shows iTerm ▸ tmux ▸ web:1.1 ▸ claude ▸ ~/git/web-app.
Beyond CPU and memory
Disk I/O, page-ins and idle wake-ups arrive in the same system call as the memory footprint, so attributing them costs nothing extra. That covers the two things a CPU-and-memory monitor can't explain at all: a machine that feels slow because something is saturating the disk, and a laptop going flat because something wakes the processor hundreds of times a second while using almost no CPU.
Per-workload load, plus real clock speed against nominal: the difference between busy and throttled.
Footprint per workload, compression, and whether swap is growing or holding steady.
Bytes per second read and written, charged to the pane or process actually moving them.
Memory pressure made visible before it turns into a machine that has stopped responding.
The battery killer nothing else surfaces: high wake-ups on near-zero CPU, named.
Per-process throughput via nettop, opt-in because measuring it honestly has a cost.
Per-process graphics utilisation where the machine will report it, whole-device where it won't.
Package and sensor temperatures with fan RPM, so "hot and loud" becomes a reading.
Capacity against design, cycle count and what the charger actually negotiated.
Wear, spare blocks, power cycles and unsafe shutdowns: the drive's own account of itself.
A reading that can't be taken is reported as the reason it's missing
(needs helper, not available, measuring…),
never as a zero. A gap you can see is worth more than a false number.
Quiet by default
Every rule has to hold across several samples and several seconds of wall clock before Skopos says a word. The menu-bar icon changes only when something is wrong.
And when it does, it hands you the evidence and one concrete step: the pane to open, the cable to swap.
A 250 swap-outs/second burst never fired. Sustained 20,945/s did.
When you want the detail
Utilisation rings, a live per-core strip, the user-versus-system split, rolling CPU and temperature, across Processor, Memory, Graphics, Sensors, Storage, Network and Battery. Live, the last hour, or the last twenty-four. It's a separate window, so none of it costs anything until you ask for it.
Storage
A treemap of everything on disk, coloured by kind (code, images, video, archives, databases), so the thing eating your last few gigabytes is a rectangle you can point at and zoom into. The colours here are read straight from the app's own source, so the map and this page can't drift apart.
Terminal & agents
One engine, three front ends. The skopos CLI prints the same
attribution the panel shows; the Model Context Protocol server hands it to
Claude and other agents, so a person and an agent asking the same question
can't be told different things.
$ skopos top Firefox 11% 6.7 GB disk 1.3 MB/s net down 28.2 KB/s Firefox ▸ content ×16 5.5% 5.2 GB iTerm 1.8% 8.2 GB net up 14.0 KB/s tmux ▸ web:1.1 ▸ claude ▸ ~/git/web-app 0.8% 719 MB net up 14.0 KB/s … 46 idle
$ claude mcp add skopos -- \ /Applications/Skopos.app/Contents/Helpers/skopos mcp # four read-only tools list_workloads get_findings get_system_state get_capabilities
Read-only, on purpose. An agent that can read your process table is a
diagnostic tool. One that can SIGSTOP your build because it
decided that would help is a different product, so nothing that changes the
machine is reachable from a tool.
The whole point
These aren't numbers chosen because they sound good and justified afterwards. They're measured on real hardware against a budget that lives inside the test suite, where it has already caught an O(n²) sort, a status item costing nine times what it drew, and two memory leaks. This page is built the same way: hand-written, no framework, no webfonts. The markup, styles and script arrive in about 15 KB gzipped, less than half the weight of the one screenshot beside it, for the same reason the app idles under half a percent of a core.
See the method and the raw numbers → · What it sends, and how to check →
Skopos arrives first on macOS as a universal app for Intel and Apple Silicon, with no password and no account. The engine underneath is portable Rust, rebuilt and checked against Linux on every run of the test suite, so Windows, Linux, iOS and Android reuse it rather than start over.
This is a preview of what's coming; there's nothing to download yet. When it ships it installs without a password or an account, and the privacy note already spells out exactly what it sends: nothing.