The agent for the models
that do not have one

What it is

The same agent in three shapes: a terminal program, a desktop app, and a local web UI. All three run on your machine and talk to whichever model you point them at.

It is not only for code

The agent reads files, runs commands and edits things. That is as true of a folder of invoices as it is of a repository — and most of the work people actually have is the first kind. Nine departments ship with sample data, so each of these can be tried before it is set up.

Six more workflows ship as skills and work in any directory: reviewing a file of rows against its rules, reporting what changed over a week, triaging an inbox, comparing two drafts, turning a transcript into decisions and owners, and reading a set of records for what is worth checking.

Which models actually work

The question nobody else answers. Calling tools is what separates a model that can do this from one that can only talk about it, and the model card never says.

One fixed task: a six-row invoice file with three planted problems — an amount over the limit with no purchase order, a blank amount, and a date with a month of 13 — and a file stating the three rules. A pass means all three found, each quoted against the rule it breaks, with the row number.

This table is short because it only holds what has been run. Adding a row is the most useful contribution you can make, and it takes about five minutes. Negative results are worth as much as positive ones and are harder to come by — nobody posts about the model that did not work.

What it cannot do

Said here rather than discovered later.

• General open models reach for grep when they have a file tool. A model not trained towards agentic work will shell out even when given a structured way to read a file. That is a gap in the models, and no interface closes it. What this project can change is reach, not intelligence.
• The desktop builds are not signed with an Apple or Microsoft certificate. Your operating system will warn you, and it is right to — it cannot tell who built them. The download page says what to do.
• Scheduled tasks run only while OpenCLI is open. This is a local agent, not a server. Anything that must fire while the machine sleeps belongs in the operating system's scheduler.
• Token counts are estimated, never counted. The tokenizer belongs to the model, and this runs models it has never seen.
• A background run may write anything inside the directory it runs in. The sandbox's writable root is that directory. Runs outside a department's directory are held until you allow the place by name.

How it compares

Not a scorecard. These are different tools, and the row that matters is the first one.

One thing worth saying plainly: a small local model is not as good at this as a frontier one. The interface is the same; the reasoning is not. OpenCLI is built so that choice is yours to make per task, not made for you — and if the frontier model is the right answer today, point it there. It speaks the same API.

The CLI

One binary. macOS and Linux:

Then point it at a model. A local Ollama, for example, needs nothing but this in ~/.opencli/config.toml:

[model_providers.ollama]
name = "Ollama"
base_url = "http://localhost:11434/v1"
wire_api = "chat"

[[models]]
slug = "qwen3-coder"
model = "qwen3-coder:30b"
provider = "ollama"
context_window = 32768