OpenMonoAgent: a .NET coding agent that ships its own llama.cpp server

The problem OpenMonoAgent is aimed at

Cloud coding agents bill per token and route your source through someone else's servers. OpenMonoAgent is built to remove both properties at once. The README states the agent runs entirely on your hardware, with no subscriptions, no data leaving your network and no per-token billing. The target user is an engineer who wants an agentic loop over a real repository but does not want a usage dashboard, an account or an API key in the loop.

The secondary audience is less obvious: people who want the agent reachable from somewhere other than the terminal it was launched in. The repository ships a mobile app on the App Store and Google Play, plus a VS Code and Cursor extension, which implies the intended deployment is a long-running local server that other clients connect to. That is a different shape from a CLI that only exists for the duration of one shell session.

What actually runs: a .NET CLI talking to a bundled llama.cpp server

The architecture described in the README is two processes plus a container boundary. A .NET 10 CLI provides the agent loop and the terminal UI. A llama.cpp inference server, shipped inside Docker, provides the model. The installer detects the hardware and picks a model tier for it.

The agent loop is bounded rather than open-ended. The README gives 25 iterations per turn as the default, with doom-loop detection that aborts when the same tool sequence repeats three times. Context is managed by two thresholds: a checkpoint at 65 percent fill and a compaction at 80 percent. Those numbers matter more than they look. A local model with a smaller usable context window will hit 65 percent sooner than a hosted model would, so the checkpoint frequency is effectively a function of the model you installed.

Tool calls pass through a fixed 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 README states nothing bypasses the pipeline, which is the design claim worth testing against the source if you plan to add your own tool.

Five sub-agents run as isolated sessions with locked tool sets and turn budgets: Explore (read-only, 15 turns), Plan (architecture, no writes, 10 turns), Coder (full file access, 30 turns), Verify (adversarial, with Roslyn, 20 turns) and general-purpose (25 turns). The separation is enforced by tool set, not by prompt instruction, which is the stronger of the two approaches.

Installing it and the commands you actually type

The documented install is a single shell command that pipes a remote script into bash:

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

The README says this auto-detects GPU, CPU or Apple Silicon and installs the model, the runtime and the Docker containers. After that, from any project directory:

openmono agent openmono agent --classic

The first is the default TUI mode, the second a scrolling terminal. Optional components are installed separately: openmono setup search adds web search and scraping, and vision is gated behind the environment variable OPENMONO_VISION_ENABLED=1. The full flag reference lives in docs/SETUP.md.

Two things are worth flagging before you run that curl. First, the script is fetched from the main branch rather than a tagged release, and the repository shows no releases retrieved, so there is no version pin to fall back to. Second, the README does not document an uninstall path or state where the model weights land on disk. If disk space or rollback matters to you, determine both before running it.

The sandbox is a mount, not a jail

The README is unusually direct about this. The project mounts your project directory as /workspace inside the container, and the agent reads and writes your real files. The stated blast radius is that mount, and nothing outside it is visible or reachable.

That framing is honest, but it should shape how you use the tool. Anything inside the mounted directory is fair game for a Coder sub-agent with full file access and a 30-turn budget. If your repository contains credentials, a .env file, deployment keys or a checked-in kubeconfig, the sandbox does not protect them, because they are inside the blast radius by definition. The container boundary protects the rest of your machine, not your project.

The practical consequence is that OpenMonoAgent is safer to point at a clean checkout or a fresh clone than at a working directory with local secrets in it. The README does not describe a path allowlist, a secret scanner or a confirmation prompt before writes, so the isolation you get is the mount plus whatever your version control lets you undo.

Model tiers and the throughput numbers the README publishes

The README associates each hardware tier with a model and a throughput figure. GPU: Qwen3.8-27B dense at roughly 60 tokens per second. CPU: Qwen3.6-35B-A3B, a mixture-of-experts model, at roughly 20 tokens per second. Apple Silicon: the same Qwen3.6-35B-A3B under Metal at roughly 45 to 48 tokens per second. A separate comparison line cites about 45 tokens per second on GPU and 20 on CPU.

Those two GPU figures do not agree with each other, and the README does not explain which configuration each one refers to. Treat both as indicative rather than measured, and note that the repository carries a beta badge. A 27B dense model at 60 tokens per second implies a fairly substantial GPU; the CPU tier at 20 tokens per second is usable but slow enough that a 25-iteration agent turn will feel long. The mixture-of-experts choice for CPU and Mac is the sensible one, since it activates a fraction of parameters per token.

The model selection is documented in docs/MODELS.md, including a reasoning-mode section. Since the installer picks the model for you based on detected hardware, the decision you are really making is whether your machine lands in the tier you expected. If it does not, the README does not describe an override flag for the model choice.

Where OpenMonoAgent is the wrong tool

The beta status is the first constraint. There are no retrieved releases, so upgrades track the main branch. If you need a pinned version with a changelog, this project does not currently offer one.

The second constraint is hardware. The entire value proposition depends on running a 27B or 35B-parameter model locally. On a machine without a discrete GPU or Apple Silicon, the CPU path at roughly 20 tokens per second turns a multi-step agent turn into a waiting exercise, and the checkpoint and compaction thresholds will trigger more often against a smaller context window. Running the CLI without the bundled inference server is not a configuration the README describes.

The third constraint is model capability. A locally hosted Qwen model is not the same tool as a frontier hosted model on hard reasoning tasks, and no amount of pipeline engineering changes that. For mechanical edits, refactors with clear boundaries and repository exploration, the gap is small. For ambiguous architectural work across a large unfamiliar codebase, it is not. The five sub-agent split, and especially the adversarial Verify agent with Roslyn, reads as an attempt to compensate by structuring the work rather than by scaling the model. Whether that compensation is sufficient is the thing to test on your own repository, not something the README can settle.

OpenCode and the difference in approach

The README's own comparison table places OpenMonoAgent against Claude Code and OpenCode across cost, privacy, inference, sandboxing, code intelligence, extensibility, MCP, UI and hardware. The comparison is rendered as an SVG, so the row-by-row detail is in docs/ARCHITECTURE.md rather than in the text.

The structural difference with OpenCode is where inference happens. OpenCode is a client: you point it at a provider, which may be a hosted API or a local server you run yourself, and the agent logic stays on your machine while the model usually does not. OpenMonoAgent bundles the server. The installer brings llama.cpp inside Docker and selects a model, so there is no separate inference setup step and no provider configuration to maintain. That is a real convenience, and it is also the constraint: you get the model the installer chose for your hardware tier, not an arbitrary one.

Against Claude Code the difference is the inverse. Claude Code's model quality comes from a hosted frontier model, and the cost and data path follow from that. OpenMonoAgent trades that quality ceiling for a fixed cost of zero after setup and a data path that ends at your own network. The Roslyn integration for type hierarchy and blast-radius analysis is the part of OpenMonoAgent that a generic agent client would have to reconstruct through language server plumbing.

Licence, upgrades and what to check before adopting

The licence is genuinely ambiguous in the supplied material. The GitHub API reports NOASSERTION, which usually means the licence could not be identified automatically from the repository's licence file. The README badge says GNU AGPL-3.0. Those two signals disagree. AGPL-3.0 carries network-copyleft obligations that matter if you modify OpenMonoAgent and expose it as a service to other users, and the mobile app and extension suggest the project is designed to be reachable over a network. Read the actual licence file in the repository before you build anything on top of it. This is a description of the discrepancy, not legal advice.

Upgrade cost is tied to the same missing releases. With no tagged versions, updating means pulling main, and the README does not describe a migration path for the Docker containers, the model weights or any local configuration the agent writes. A model swap is a multi-gigabyte download, so a tier change is not cheap in bandwidth either.

What to verify first, in order: the licence file, the model tier your hardware actually selects, and whether the install script's disk footprint is acceptable. Then run it against a throwaway clone rather than a working directory, because the sandbox mount means your real files are the blast radius.

Editorial conclusion

OpenMonoAgent fits engineers who already have a capable GPU or Apple Silicon machine, are comfortable with Docker and want their prompts and source to stay on their own network. It is the wrong tool if you work on a locked-down corporate laptop, if you depend on a hosted model's reasoning quality for hard refactors, or if you need a stable interface rather than a beta. Before installing, read docs/ARCHITECTURE.md and docs/MODELS.md to confirm the model your hardware tier selects, and check the repository's licence file directly, because the GitHub API reports NOASSERTION while the README badge says AGPL-3.0. Also verify what the installer writes to disk, since the one-line curl script pulls a model, a runtime and Docker containers.

Official sources

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