See what your machine is doing with Ollama.

Install & run

On npm since August 2026. One command, nothing to clone, and no dependencies beyond Node itself:

npx @opensourcesai/cmdcenter serve      # dashboard at http://127.0.0.1:7717
npx @opensourcesai/cmdcenter            # one-shot human-readable report
npx @opensourcesai/cmdcenter --json     # the full report as JSON

Each release is published from public CI with npm provenance so the registry can prove each tarball was built from a public commit of the repository, and there is no other publish path. Prefer reading before running? Clone the repository and run the same commands as node src/cli.js …; npx runs that same source.

You need

Stopping it, and removing it. Press Ctrl+C in the terminal running the server. It installs no service and registers no startup entry. Since the chat surface landed (August 2026) it keeps one directory of its own data, your conversations and this machine’s measurement history, at %LOCALAPPDATA%\osai-cmdcenter on Windows, ~/Library/Application Support/osai-cmdcenter on macOS, or ~/.local/share/osai-cmdcenter on Linux. Delete that directory and the tool is gone, apart from npx’s ordinary package cache; individual conversations can also be deleted from the Chat view, behind a confirm. The tool does not transmit that directory or read it into a diagnostic capture.

What it looks like running

What it reports

What this adds to ollama ps

If you already use ollama ps, keep using it. It ships with Ollama, it costs nothing to run, and it answers its question well: what is loaded right now, and how much of it landed on the GPU. Command Center does not replace it.

What it can’t tell you is whether that split was avoidable. Command Center reads the same runtime numbers and sets them beside the three facts that explain them.

How much VRAM you have. Read from each source your platform exposes rather than one. Where two sources disagree (and on Windows they routinely do, because one common interface tops out at about 4 GB and will report that for a 12 GB card) both figures are shown and the disagreement is named, instead of being resolved to whichever number looked cleaner.

Whether your models fit it. A committed catalog snapshot is graded against your measured memory as comfortable, tight, runs-but-offloaded, or too large, with the quantization that fits and the ollama run command for it. A command appears only where the catalog carries a real registry-verified tag; the tool will not synthesize one, because a copy-pasteable command that 404s is worse than no command.

Residency, in context. A model sitting at 60% in VRAM is a fact ollama ps reports too. The useful version is that number next to the card it’s running on, the headroom left, and the quantization that would have fit whole.

Running it on a headless machine

Plenty of Ollama setups have no desktop at all (a spare tower in a cupboard, a home server, a rented Linux box) and you drive them from a laptop. That works, and the way it works is inflexible in one respect.

There is no flag to put the dashboard on your network. The bind address is the loopback literal 127.0.0.1, written into the source with a test that fails the build if it ever changes. --port moves the port; nothing moves the address. So the usual way a local dashboard ends up reachable from the rest of the house, a well-meaning --host 0.0.0.0, is not available to you, or to anyone who talks you into it.

The supported way in is an SSH tunnel, which keeps each guarantee above intact. Start the server on the machine Ollama runs on:

nohup npx @opensourcesai/cmdcenter@latest serve --port 7717 < /dev/null > /tmp/cmdcenter.log 2>&1 & disown

The < /dev/null matters, and it is the part people leave out. Without it the server keeps the SSH channel open and your terminal appears to hang, even with nohup and disown, which reads as a failure when the server has in fact started. Redirecting standard input closes the channel and gives you your prompt back. The log file is where any startup error will be.

Then, from your laptop, in a new terminal rather than inside the SSH session you just used:

ssh -N -L 7717:127.0.0.1:7717 your-server

Leave that running and open http://127.0.0.1:7717/ in your browser. There is no token to copy or paste: the server hands it to the page itself. The dashboard is still bound to loopback on the server, still requires the per-session token on every request, and still checks the Host and Origin headers. The tunnel changes where the loopback connection comes from, not what is guarding it.

Use the same port number on both sides. The Origin check is pinned to the port the server was started on, so forwarding local 7718 to remote 7717 leaves you with a dashboard that loads and reads fine but refuses its two actions. Matching the numbers avoids the whole question.

When it doesn’t work

Five things that have gone wrong in practice, and what each one means. None of them is what the error message suggests.

channel 3: open failed: connect failed: Connection refused, repeating. The tunnel is fine. That message is the tunnel reporting that it arrived and found nothing listening on 127.0.0.1:7717 at the far end, which nearly always means the server is not running. Check the log you redirected it to.

serve printed nothing, exited immediately, and the log is empty. The server never started, and the cause is the command rather than the machine. A bare npx @opensourcesai/cmdcenter runs whatever it first cached, and one published release, 0.2.0, shipped a binary that exited without starting anything or printing a message. It was fixed in 0.2.1, but a machine that ran the broken one once keeps launching it out of the npx cache, while npm view reports the current version and npm pack downloads it, so each check you think to run says the package is fine. The tunnel then answers with Connection refused and sends you back to SSH, which was never the problem. Clear the cache once, and pin the version so it cannot return:

rm -rf ~/.npm/_npx
npx @opensourcesai/cmdcenter@latest serve --port 7717

Permission denied when the tunnel tries to bind the local port on Windows. Not a permissions problem, whatever the wording says: something on your own machine already holds 127.0.0.1:7717. An earlier tunnel you never closed is the usual culprit. Close it rather than forwarding to a different local port; see the matching-ports note above.

A host-key prompt for a machine you are already logged into. The tunnel command was run inside the SSH session instead of on your laptop, so the server is being asked to SSH to itself. Open a second terminal locally and run it there.

“Ollama not detected” while Ollama is plainly running. The Ollama Windows app sets OLLAMA_HOST=0.0.0.0, and that one variable means two incompatible things: to the Ollama server it is the address to listen on, to a client it is the address to connect to. 0.0.0.0 is a sensible instruction to listen everywhere and a meaningless place to dial, so a client that takes it at face value fails instantly on a machine where Ollama is working perfectly. Command Center already handles this: a wildcard address falls back to loopback, keeping any non-default port you set. It is written up here because the same variable breaks other local AI tools the same way, and the symptom does not point at the cause.

What this is not

A measured chat surface, not a chat product. This page used to say “not a chat client”, and until August 2026 that was true. It now has a chat view, but the point is the instrument: each reply arrives with its measured figures and a verdict on whether the machine kept the fit engine’s promise. If you want a full-featured chat frontend, keep the one you have; this one exists to tell you what your machine did while it answered.

Not a fleet or enterprise tool. It reports on the one machine it runs on and does not compare your machine to anyone else’s.

Still no installer. It ships as plain source on npm, and npx runs it directly on Node. No OS installer, no code signing, no auto-update; releases are published only from public CI, with provenance the registry can verify.

Two actions, plus inference. Load and unload remain the entire action surface. The chat view also relays inference to the AI runtimes on your machine (Ollama, and optionally a local llama.cpp server), and that is the entire list: it talks only to AI runtimes on this machine, not to the internet, and nothing else in Ollama’s API is reachable through it.

Found a bug, or stuck?

Detection is the hard part of a tool like this, and machines differ in ways no test suite anticipates; each platform quirk it handles today was found on somebody’s real hardware. A number that looks wrong is worth reporting rather than working around.

Next steps