The Ops Room is where you ask GSO-1 questions about your own machine and let it act on the answers. It runs on a model you host, inside a directory it cannot write outside of, and it asks before it changes anything.
The rest of GSO-1 is a dashboard: it shows you the situation and gives you buttons. The Ops Room is the part you can ask. "Which repos have uncommitted changes?" is a question the dashboard answers by making you look. The Ops Room answers it by looking for you, across every project root, and telling you which ones and how many files.
It is not a general-purpose chatbot bolted onto a dashboard. It has a specific, small set of tools, all of them about the machine it runs on, and no ability to do anything outside them. That narrowness is the point: an agent that can only do ten things can be trusted with those ten things.
Every project across your roots, with its detected kind and whether it is running.
Branch, dirty file count, ahead/behind and last commit for one repository.
The same across every repo at once. This is the one that answers "what have I left unfinished".
What is running, on which ports, and for how long.
Snapshot the current working tree into a versioned release.
Health-check a release before anything depends on it.
Point var/current at a verified release.
Go back to the previous one when a promotion turns out badly.
Which release is live, which are on disk, what changed.
Look something up. Disabled entirely unless TAVILY_API_KEY is set.
Plus reading and writing files, which is where the sandbox below matters.
An agent that can start processes and edit files on your machine is a real capability, so the limits are structural rather than a promise in a prompt.
OPSROOM_SANDBOX_ROOT.OPSROOM_READ_ROOTS.var/, and the
launcher. The supervisor is what rolls back a bad self-edit, so the agent must never be
able to touch it.Every check resolves symlinks and .. before deciding, so
sandbox/../../etc/passwd and a symlink pointing outside both fail closed rather
than open.
Anything that writes a file or runs a command stops and asks. The request goes to the same
Allow / Deny gate GSO-1 already uses for Claude Code sessions, so there is one approval
mechanism on the machine rather than two, and it can reach you on Telegram when you are not
at the desk. Read-only tools run without asking, because stopping you to approve a
git status would train you to approve everything.
GSO-1 starts processes and runs commands as you, and the Ops Room is that capability with a language model driving. The defaults are conservative and the sandbox is enforced in code, but this is a tool that does things to your machine. Read the security policy before you open it up to anything beyond loopback.
The Ops Room talks to an OpenAI-compatible endpoint. In practice that means
llama.cpp's llama-server running on your own hardware, so no
part of a session leaves the machine and there is no per-token cost to think about.
Any tool-capable GGUF will do. Tool use is the requirement that actually matters: a model that cannot call tools reliably will hold a nice conversation and do nothing.
# --jinja is not optional: it is what makes tool calling work
llama-server \
--model ~/models/your-model.gguf \
--host 127.0.0.1 --port 8080 \
--ctx-size 65536 \
--jinja
Or start it from the dashboard: the Local LLM tab lists the models on disk, loads one, and shows tokens per second, context use and memory while it runs.
# defaults, override in .env if yours differ
OPSROOM_LLAMA_URL=http://127.0.0.1:8080/v1
OPSROOM_MODEL=glm-4.7-flash
OPSROOM_CTX=65536
OPSROOM_MAX_TOKENS=4096
| Variable | Default | What it controls |
|---|---|---|
OPSROOM_LLAMA_URL | http://127.0.0.1:8080/v1 | The OpenAI-compatible endpoint to talk to. |
OPSROOM_MODEL | glm-4.7-flash | Model id, as the server reports it. |
OPSROOM_CTX | 65536 | Context window. The tool schemas alone cost roughly 1,300 tokens, and a full dirty-repo sweep can return several thousand, so a small window runs out fast. |
OPSROOM_MAX_TOKENS | 4096 | Cap on a single reply. |
OPSROOM_SANDBOX_ROOT | the install directory | The one writable root. |
OPSROOM_READ_ROOTS | sandbox + your project folders | Comma-separated readable roots. |
TAVILY_API_KEY | unset | Enables web_search. Without it the tool disappears rather than failing. |
# from the dashboard: the Ops Room panel, or Cmd+J
# from a terminal:
./ops "which repos have uncommitted changes?"
./ops "is anything holding port 3000?"
./ops "build a release and verify it, but do not promote"
Local tool-use reliability varies enormously between models, far more than chat quality does. A model that writes beautifully may still call a tool with the wrong argument shape and then confidently summarise a result it never received. If the Ops Room is behaving oddly, the model is the first thing to change, not the prompt.
The Ops Room can change GSO-1 itself, which is a genuinely dangerous thing to let an agent do, because a bad edit can kill the process making it before anything notices.
So the running agent executes from the promoted release while it edits the working tree. Those are different directories on purpose. An in-progress edit cannot touch the code currently executing; new code only takes effect once a release is built, verified and promoted, and a promotion that fails its health check rolls back.
This is not hypothetical caution. A broken self-edit killed the agent mid-task during development, before verification could refuse it. The separation is what came out of that.