Atlarix vs opencode: Permissive by Default, or Ask First
opencode is the tool we benchmarked against, the one whose provider-catalogue approach we openly followed, and the closest thing Atlarix has to a peer in architecture. It is MIT-licensed, supports a very long list of providers, and is genuinely well built. The differences worth writing about are not capability but defaults — specifically, what each tool does before asking you. Claims below are quoted from opencode's documentation, verified 18 September 2026.
The permission defaults differ, and both are documented
opencode's permissions page states: "If you don't specify anything, OpenCode starts from permissive defaults:" followed by three points —
- Most permissions default to
allow. doom_loopandexternal_directorydefault toask.readisallow, but.envfiles are denied by default.
Atlarix starts from the other end: file writes go to an approval queue by default, and you grant standing permission as you go rather than revoking it after the fact.
Which default is right depends on you
Permissive defaults are not carelessness, they are a bet that interruption costs more than the occasional unwanted write, and for an experienced user working in a scratch repository that bet is usually correct.
Ask-first is the opposite bet, and it has a real cost we should name: more clicks, and a rhythm where you are reviewing rather than watching. We made it because the failure we kept seeing was not malice but confident wrongness — an agent doing the wrong thing decisively — and a diff you approve is the cheapest place to catch that.
Review runs in your runner
opencode's GitHub integration auto-reviews by default: "For pull_request events, if no prompt is provided, OpenCode defaults to reviewing the pull request." And it is explicit about where that happens — the docs list "Secure: OpenCode runs inside your GitHub's runners" as a property, and elsewhere say it "will execute tasks within your GitHub Actions runner."
That is a genuine security argument: your code never goes to an opencode server because there isn't one in the path. It also means you supply the model key and pay the Actions minutes.
The same problem solved two ways
opencode's answer is to run in infrastructure you already trust. Atlarix's is to run a hosted reviewer that cannot execute anything — three read-only tools, no clone, no checkout, no container, no runner — so there is nothing to compromise even though it is hosted.
Both are coherent. opencode's costs you setup and runner minutes and gives you complete control; ours costs you trusting a hosted service and gives you an install-and-forget reviewer on one balance. Neither is the obviously correct answer.
Browser work
opencode's organisation publishes a browser-control extension, and its own repository is candid about status: it installs unpacked through Developer mode, and Chrome Web Store distribution is described as not yet available, with the first store release planned as an unlisted beta.
Atlarix's extension is published on the Chrome Web Store and installs normally. That is a distribution difference rather than a capability judgement — an unpacked extension does the job, it just asks more of whoever installs it.
Benchmarks, with the caveat we always attach
We ran Terminal-Bench 2.0 against both harnesses on the same model and identical settings. Atlarix resolved 42 of 88 scored tasks, opencode 39 — and we have said at length that a three-task gap at single attempt proves nothing, especially with roughly a quarter of trials on each side ending in timeouts.
The full accounting, including an arithmetic error we found on our own benchmark page while writing it up, is in benchmarking a coding agent honestly.
opencode is MIT-licensed, runs review in your own infrastructure, and starts permissive. Atlarix is proprietary, runs a reviewer that cannot execute code, and starts by asking. If you want to own the whole pipeline, opencode is built for that. If you want the approval queue and the sandbox to be someone else's problem, that is what we sell.