SysScope — a project by Ahsan Mahmood
Read-only Bash CLI that audits your Mac or Linux machine and grades which local Ollama models it can actually run.
Will this model actually run on this laptop?
The usual answer is a number of gigabytes, and the answer that matters is a different one. A model fits when the weights, the context you intend to use and everything already resident leave enough headroom for the machine to avoid swapping. Two laptops holding the same amount of memory can give opposite answers.
So the question is really about the machine.
SysScope reads the machine first and grades models against what it found there. Apple Silicon core layout, GPU cores, Metal version, NVIDIA VRAM, memory, disk, battery and thermal state, turned into an inference memory budget rather than a specification sheet.
Fifteen popular Ollama models then get a verdict each: fits, tight, or too big.
Tight is the one worth having. Fits and too-big are usually obvious from a model's own page, while the middle case is where something loads, behaves during a short test and then degrades at the end of a long context, which is a slow way to find a limit.
Beside that sits a health scorecard for disk, memory, AI capability and battery, each with a one-line reason rather than a bare score.
The implementation choice is the part I would defend.
It is pure Bash with no dependencies, and it runs on the bash 3.2 that ships with macOS rather than demanding a newer shell. That constraint costs real convenience. It also means the tool runs on a machine somebody has just handed you, before anything has been installed on it, which is precisely the moment this question gets asked.
It is read-only.
There are no network calls, and nothing on the system is modified. That is stated at the top because a script which inspects your hardware is a script people are right to be wary of, and the only convincing answer is a codebase short enough to read first.
Output arrives three ways: a colourised terminal report, a Markdown report meant for sharing, and JSON for anything that has to parse it. Three run modes cover full, quick and AI-only. It works as an interactive menu or unattended behind a flag.
Sharing the report is the risk.
A hardware dump carries serial numbers, UUIDs and a hostname that is very often somebody's actual name. The share mode redacts those before the report leaves the machine, which is the difference between a file you can post in a thread and one you should not.
What it cost is portability, and that cost is ongoing.
Every hardware probe is a different command on a different platform, so shell code reading system_profiler on one machine and nvidia-smi on another accumulates special cases faster than it accumulates features.
It ships two ways. One is npm, run instantly through npx; the other is a single-file bundle you fetch and pipe to a shell, which is how a tool reaches a machine with no Node.js on it yet.
It runs on a Mac or a Linux machine. There is no iOS release behind any of my work, because there is no Apple Developer account here. A phone is not what this is for in any case.
npx sysscope, on npm, with the source at github.com/aoneahsan/sysscope.
Read it before running it. That is the standing advice for anything distributed this way, and being small enough to make that practical was a design goal rather than an accident.
What it does, and what that costs to build
- Grades 15 Ollama models against a computed inference memory budget with a fits / tight / too-big verdict
- Detects real hardware: Apple Silicon P/E cores, GPU cores, Metal version, NVIDIA VRAM, RAM, disk, battery, thermals
- Health scorecard rating disk, memory, AI, and battery with one-line reasons
- Three run modes: full, quick, and ai-only
- Multiple outputs: terminal report, shareable Markdown, and machine-readable JSON
- Privacy --share mode redacts serials, UUIDs, and hostname
- Dual distribution via npx and a curl | bash single-file bundle
- Interactive menu or fully scriptable unattended operation with --yes
Built with
- Bash
- POSIX shell
- Node.js
- npm
- system_profiler
- sysctl
- nvidia-smi
- ANSI terminal output
- GitHub-Flavored Markdown
- JSON
Worth knowing
- cli
- bash
- local-ai
- ollama
- system-audit
- apple-silicon
- developer-tools
- npx
Who built SysScope?
Ahsan Mahmood wrote it in Bash, deliberately. It is on npm and runs through npx sysscope, with the source at github.com/aoneahsan/sysscope. A dependency-free shell script is an unfashionable choice and it is the right one for a tool whose entire job is to run on a machine before anything has been installed on it. Shipping it through npx means the machine you are diagnosing needs nothing installed first, which is the whole point of a tool you reach for when a machine is already misbehaving.
What does it check before grading a model?
The machine, in more detail than a specification sheet gives you: Apple Silicon core layout, GPU cores and Metal version, NVIDIA VRAM, memory, disk, battery and thermal state. Those readings are turned into an inference memory budget, and that budget is what a model gets graded against. It is the difference between comparing a model's size to your total memory and comparing it to the memory genuinely available for inference on this machine, in this state, with whatever else is already resident.
Does SysScope run on iPhone?
No. It is a terminal tool for a Mac or a Linux machine, and it does not run on a phone at all. There is no iOS release behind any of my work either, because there is no Apple Developer account here and nothing I build has shipped to the App Store. It does know a good deal about Apple hardware, since core layout and Metal version are among the things it reads, and that is a desktop question rather than a mobile one.
Is it safe to run on a work machine?
It is read-only and makes no network calls, so it inspects the system and changes nothing on it. That claim is worth checking rather than believing, and it is checkable: a single Bash file with no dependencies is short enough to read before you run it. The share mode also redacts serial numbers, UUIDs and the hostname before a report leaves your machine, because a hardware report is exactly the kind of file that carries somebody's name out into a public thread by accident.
What does a tight verdict mean?
It means the model will load and you should expect trouble at the edges. Fits and too-big are usually obvious from a model's own page; tight is the case where something runs happily through a short test and then degrades at the end of a long context or under thermal pressure, which is a slow and confusing way to learn a limit. The verdict comes from the computed inference budget rather than from a rule of thumb, and the scorecard beside it gives a one-line reason for disk, memory, AI capability and battery.
https://aoneahsan.com/projects/com.aoneahsan.sysscope