openabcode: the classifier that never writes the code

The routing model and the writing model are two different models

The mechanism is a classifier sitting in front of your model choices, and the setup steps go out of their way to keep the two apart. `/route-model` selects the authenticated model that classifies tasks, and the documentation states plainly that this does not change the active execution model. `/model` is where you pick one specific model per family, with examples given as `gpt-6-astra` for OpenAI, `gemini-3.8-flash` for Google and `claude-fable-5` for Anthropic. The routing guarantee is that Route always executes tasks with the exact model you picked for the chosen family. So the classifier is a cheap model making a three-way decision, and a different, named model does the work. The default policy is the routing table itself: Google ecosystem work goes to Gemini, code review and testing go to ChatGPT, everything else goes to Claude.

Routing degrades to whatever families you managed to configure

Route works as long as at least two model families are configured, and with a family missing, routing degrades to the available ones. That single sentence describes the whole failure mode: no error, no warning about a missing provider, just a smaller decision space that still looks like it is routing. The visibility offered is a footer showing the configured execution models, so the degraded state is visible if you look at the footer and invisible if you do not. Two audit trails do exist. Every completed routing decision is stored in the session JSONL, and manually overriding a routed model is recorded as veto feedback. Veto feedback is the interesting one, because it means the system accumulates a record of every case where a human disagreed with its own classifier, which is the raw material for judging whether the routing table above is any good.

Route rules are replaced wholesale, never merged

Route rules, heuristic keywords, file extension mappings, project markers and the default provider are all editable in `~/.openabcode/agent/settings.json` for global scope or `.openabcode/settings.json` at project level. The rule that matters is short: when a field is set, it fully replaces the corresponding built-in default, and each field is optional and independent so you configure only what you want to override. Replace rather than merge means overriding one keyword list silently discards every built-in keyword that was not in your list, which is the behaviour you want if the defaults are wrong and a trap if you expected to add. The keyword lists are the coarse layer, keyed by family:

{
    "keywords": {
      "openai": ["algorithm", "unit test", "benchmark", "data analysis", "pipeline"],
      "google": ["android", "flutter", "dart", "firebase", "gcp"],
      "anthropic": ["refactor", "debug", "architecture", "migration"]
    }
}

Above them sit the natural-language rules per family, which are the strings the classifier reads, and beside them the file extension mappings that route on what a task touches.

It runs as whoever launched it, with no permission layer

This is the line to read twice before installing anything: openabcode does not include a built-in permission system for restricting filesystem, process, network or credential access. By default it runs with the permissions of the user and process that launched it. For an agent whose entire purpose is reading files, editing code and running commands, that is a large surface granted implicitly, and it is granted before you have configured a single provider. The project's answer is to point at `packages/coding-agent/docs/containerization.md` and offer three patterns. Gondolin keeps `openabcode` and provider auth on the host while routing built-in tools and `!` commands into a local Linux micro-VM. Plain Docker runs the whole process in a local container. OpenShell runs the whole process in a policy-controlled sandbox. The first is the interesting one, since it keeps credentials on the host and still puts tool execution somewhere else.

The recommended install pipes a remote script into a shell

The first quick start option is a pipe to `sh`:

curl -fsSL https://openabcode.com/install.sh | sh

It sits oddly next to the project's own supply-chain section, which pins direct dependencies to exact versions, treats npm dependency changes as reviewed code changes, and adds a scheduled audit workflow. A reviewer weighing this has to hold both facts at once: the project takes its transitive dependencies seriously and offers piping an unreviewed remote script as the first thing to run. The package manager alternatives are the better-audited path and there are three:

npm install -g @openabcode/coding-agent --ignore-scripts
bun install -g @openabcode/coding-agent
brew install matrixmapai/tap/openabcode

Note what differs between them. The npm line carries `--ignore-scripts` and the documentation applies the same flag to local release installs and to `openabcode update --self`. The bun line does not, and the brew line installs a formula from a tap rather than a package, so none of the npm-level controls reach it.

The supply-chain rigour only reaches the npm path

The hardening is real and specific. `.npmrc` sets `save-exact=true` and `min-release-age=2`, the second to avoid same-day dependency releases during resolution. `package-lock.json` is named the dependency ground truth, and a pre-commit hook blocks accidental lockfile commits unless `OPENABCODE_ALLOW_LOCKFILE_CHANGE=1` is set. `npm run check` verifies pinned direct dependencies, native TypeScript import compatibility and the generated coding-agent shrinkwrap. The published CLI ships `packages/coding-agent/npm-shrinkwrap.json` so npm users get pinned transitive dependencies. Release smoke tests run `npm run release:local` to build, pack and create isolated npm and Bun installs outside the repository before a tag is cut. Shrinkwrap generation carries an explicit allowlist for dependency lifecycle scripts, so a new lifecycle-script dependency fails checks until someone reviews it. Every one of those mechanisms is an npm mechanism, and two of the three recommended installs do not use npm.

The package list, the architecture note and the build script disagree

Three different inventories of the same codebase appear in the visible documentation, and reconciling them takes a minute. The package table lists three: `@openabcode/coding-agent`, `@openabcode/tui` and `@openabcode/ai`. The architecture note names `@openabcode/agent-core` as the package holding the agent loop, state and tool execution, which is not in the table. The build script in `package.json` compiles a different sequence again, moving through `packages/tui`, then `packages/ai`, then `packages/agent`, then `packages/coding-agent`, then `packages/orchestrator`. So `agent-core` in the prose, `agent` in the build, and an `orchestrator` package that the table and the architecture note both omit. The workspace globs also pull in five example extension directories, `with-deps`, `custom-provider-anthropic`, `custom-provider-gitlab-duo`, `sandbox` and `gondolin`, which is where the containerization patterns from the permissions section are actually implemented. The two custom-provider examples also hint at a wider provider surface than the three families the routing table covers. Two more scripts, `profile:tui` and `profile:rpc`, exist for profiling Node under the terminal UI and RPC modes, which tells you the interactive renderer is heavy enough to need its own profiler target.

Development setup, and an AGPL repository with MIT-derived parts

Working from a clone takes five commands, and the first one already carries the security posture:

npm install --ignore-scripts  # Install all dependencies without running lifecycle scripts
npm run build        # Build all packages
npm run check        # Lint, format, and type check
./test.sh            # Run tests (skips LLM-dependent tests without API keys)
./openabcode-test.sh         # Run openabcode from sources (can be run from any directory)

`npm run check` is heavier than the label suggests, chaining biome with `--error-on-warnings`, the pinned-dependency check, the TypeScript import check, the shrinkwrap check, `tsgo --noEmit` and a browser smoke check. The tests skip LLM-dependent cases when no API keys are present, which is worth knowing before reading a green run as full coverage. Publishing runs through `version:patch` and `version:minor`, which bump every workspace, run a version sync script and regenerate the lockfile with `--ignore-scripts`. Note that `.openabcode/` sits at the repository root, the same directory name the project-level settings path uses, so the project ships its own configuration for itself. Contributor rules live in `AGENTS.md` and are explicitly written for agents as well as people, alongside a `SECURITY.md` and a `.husky/` directory holding the pre-commit hooks that enforce the lockfile rule. On licensing, the repository is AGPL-3.0, and the one qualification is that portions derived from Pi remain under the MIT License with attribution recorded in `NOTICE`. The last push to main was on 2026-09-29, and the newest release, v1.1.0, is dated 2026-09-16.

Editorial conclusion

Adopt openabcode if you want per-task model routing and already run agents inside a container or micro-VM, since the project ships no permission system of its own and hands that boundary to Gondolin, Docker or OpenShell. Do not adopt it expecting the supply-chain guarantees to follow you wherever you installed from: the exact-pinned direct dependencies, min-release-age, the generated shrinkwrap and the lifecycle-script allowlist all apply to the npm path, while the curl installer and the Homebrew tap bypass every one of them. Verify first which of the three install routes you took, then confirm that the package the architecture notes call `@openabcode/agent-core` matches the `agent` directory the build script compiles.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. matrixmapai/openabcode on GitHub
3. Project website
4. README
5. Releases