OpenMonoAgent.ai: a terminal coding agent that runs entirely on your own hardware

The problem OpenMonoAgent.ai targets: per-token billing and code leaving your network

The README frames the project against cloud coding agents: 'Your prompts, your code, and your context hit someone else's servers on every keystroke.' OpenMonoAgent.ai answers that with a local model server. The agent itself is a .NET 10 CLI; the model runs through llama.cpp inside Docker on the same machine. After the one-time setup, the README states, inference costs nothing.

The intended user is a developer who works in a terminal, has a machine with a discrete NVIDIA GPU, Apple Silicon, or enough CPU and RAM to run a 27B to 35B parameter model, and does not want an account, an API key, or a usage dashboard. The README is explicit that there is no account and no API key. That is the whole pitch: you own the model, the compute, and the data.

It is worth being precise about what this does not solve. Local inference removes the network round trip and the bill. It does not remove the cost of the hardware, the electricity, or the time you spend waiting for tokens. The README quotes roughly 45 tokens per second on GPU and about 20 on CPU, which is a workable but not fast loop for large edits.

How the agentic loop, the 12-step tool pipeline and the sub-agents fit together

The architecture described in the README has three layers. At the bottom is llama.cpp running in Docker, serving the model the installer picked for your hardware. In the middle is the .NET CLI, which owns the agentic loop. On top are the tools and sub-agents the loop can call.

The loop runs up to 25 iterations per turn. Two guardrails are documented: doom-loop detection aborts when the same tool sequence repeats three times, and context management checkpoints at 65 percent fill and compacts at 80 percent. That is a more concrete description than most agent READMEs give, and it addresses the two failure modes that make local agents frustrating: a model that repeats a failing command, and a context window that silently truncates mid-task.

Every tool call passes through what the README calls a 12-step pipeline: parse, schema validate, path sanity, plan-mode guard, capability check, cache, pre-hook, execute, post-hook, artifact store. Read-only tools can run in parallel. The claim that nothing bypasses the pipeline matters because it means a plan-mode session cannot write files even if the model asks it to; the guard is in the pipeline, not in the prompt.

Five specialist sub-agents run in isolated sessions with locked tool sets and turn budgets: Explore (read-only discovery, 15 turns), Plan (architecture, no writes, 10 turns), Coder (full file access, 30 turns), Verify (adversarial plus Roslyn, 20 turns), and general-purpose (everything, 25 turns). Locking the tool set per sub-agent is the design decision that keeps a read-only exploration from accidentally editing your tree.

Installing OpenMonoAgent.ai and running your first agent session

The README gives a single install command. It is a shell script fetched from the repository's main branch, and the README says it auto-detects GPU, CPU, or Apple Silicon and installs the model, the runtime, and the Docker containers.

bash <(curl -fsSL https://raw.githubusercontent.com/StartupHakk/OpenMonoAgent.ai/refs/heads/main/get-openmono.sh)

Because the script is fetched from main rather than from a tagged release, what you install is whatever is on the branch at that moment. The repository has no releases listed, so there is no version pin to fall back on. If you need reproducibility, read get-openmono.sh before running it and record the commit you used.

Once installed, the README shows two ways to start the agent from any project directory. The first is the default TUI; the second is a classic scrolling terminal, which is easier to pipe or scroll back through.

openmono agent            # TUI mode (default)
openmono agent --classic  # classic scrolling terminal

Optional capabilities are installed separately. Web search and scraping are added with a setup subcommand, and vision is turned on with an environment variable:

openmono setup search

OPENMONO_VISION_ENABLED=1

The README points to docs/SETUP.md for the full command reference, including setup flags and GPU or CPU options. That file is where you should look before running the installer on a machine you care about, since the README itself does not enumerate the flags.

The Docker sandbox is the real security boundary, and the README says so

The README describes the sandbox plainly: the project mounts as /workspace, the agent reads and writes your real files, and 'that's the blast radius.' Nothing outside the mount is visible or reachable. This is the right way to state it. A sandbox that lets an agent edit your working tree is not a sandbox in the sense of protecting that tree; it is a boundary around everything else on the machine.

The practical consequence is that you should start the agent in the directory you are willing to let it modify, not in your home directory. If you launch it from a parent folder that contains unrelated repositories, credentials, or infrastructure configuration, the mount covers those too. The README does not describe a path allowlist or a read-only mount option, so the working directory is the control you have.

The README also does not document rollback, uninstall, or how to recover a file the agent overwrote. Checkpoints are described in the context of the conversation (65 percent fill, 80 percent compaction), not as filesystem snapshots. If you are working outside version control, you have no undo. Run the agent inside a git repository and commit before a long session.

Where OpenMonoAgent.ai is the wrong tool

The first limitation is hardware. The installer picks a model for you, and the README's own table lists Qwen3.8-27B on GPU and Qwen3.6-35B-A3B on CPU and Mac. A 27B or 35B model needs real memory. On a laptop with integrated graphics and 16 GB of RAM, the CPU path at roughly 20 tokens per second will feel slow for anything beyond small edits, and the README does not document a smaller-model fallback for constrained machines.

The second is project status. The README labels the build beta, and the repository has no releases, so there is no stable version to pin. The README does not document an upgrade path, a migration procedure between model versions, or a rollback to a previous installer state. If your team needs a tool with a changelog and a support contract, this is not that tool yet.

The third is the licence. The repository metadata reports NOASSERTION, while the README carries an AGPL-3.0 badge. Those two things disagree. AGPL-3.0 has real implications for anyone embedding the code in a network service, and you should read the LICENSE file directly rather than relying on either the badge or the metadata. Nothing here is legal advice; the point is that the two sources conflict and one of them is wrong.

Finally, the README makes performance claims (roughly 45 tokens per second on GPU, 20 on CPU, 45 to 48 on Mac with Metal) without describing the hardware they were measured on. Treat them as indicative, not as a specification for your machine.

How it differs from OpenCode and Claude Code

The README positions OpenMonoAgent.ai against Claude Code and OpenCode, and the difference is where inference runs. Claude Code is a cloud product: the model runs on Anthropic's infrastructure, you authenticate, and you pay per token or per seat. OpenCode is an open-source terminal agent that, in its common configuration, connects to a model provider over the network.

OpenMonoAgent.ai bundles the inference server. That is the substantive difference, and it changes the operational profile in two directions. On the plus side, there is no API key, no account, and no per-keystroke egress. On the minus side, you now own a Docker container running a model server, a multi-gigabyte model download, and the hardware that holds it. Upgrading the model is your job, not a provider's.

The README also claims deep code intelligence through Roslyn, including type hierarchy and blast-radius analysis. That is a .NET-specific advantage: Roslyn gives structural information about C# that a text-only tool has to approximate. If your codebase is not .NET, that advantage largely disappears, and the choice comes down to local inference versus a hosted model.

Maintenance, upgrade cost and the licence question

The last push to the default branch was on 2026-09-09, and the repository is not archived. That is recent. It does not tell you how the project handles breaking changes, because there are no releases and therefore no version boundaries to reason about.

Upgrading is the weak point. The install command pulls get-openmono.sh from main, so re-running it may fetch a different script than the one you ran before. Models are pulled by the installer, and the README does not describe how to pin a model version, how to keep two model versions side by side, or how to revert to an earlier one. If a new model performs worse on your hardware, the documented path back is not there.

The licence situation deserves a direct check. The README badge says GNU AGPL-3.0; the repository metadata says NOASSERTION. AGPL-3.0 requires that users interacting with a modified version over a network be offered the source. For a locally installed CLI that most people run for themselves, that obligation is unlikely to bite. For a company that wraps the agent in an internal service, it might. Read LICENSE and, if the answer matters, ask someone qualified.

Editorial conclusion

Adopt OpenMonoAgent.ai if you have a machine with enough VRAM or RAM to hold a 27B or 35B model and you want an agentic coding loop with no API keys and no per-token bill. Do not adopt it if you need a stable, documented tool for a team: the project labels itself beta, the repository has no releases, the README does not document rollback or uninstall, and the licence file is not resolved by the repository metadata. Before you commit, verify that docs/SETUP.md covers your hardware, confirm the sandbox mount matches the directory you actually work in, and read LICENSE directly rather than trusting the AGPL-3.0 badge.

Frequently asked questions

Official sources

1. Issues
2. README
3. StartupHakk/OpenMonoAgent.ai on GitHub