OpenABCode routes coding tasks across Gemini, ChatGPT and Claude

The problem OpenABCode targets: one agent, three model families

Most terminal coding agents bind a session to one model. You pick a frontier model, pay its rate for every edit, and accept that it is mediocre at some tasks and strong at others. OpenABCode takes the opposite position. The README describes it as an LLM-routing coding agent that dynamically routes development tasks to the best-suited models, with three stated destinations: Google ecosystem work goes to Gemini, code review and testing go to ChatGPT, and all other development tasks go to Claude. The intended user is someone who already pays for more than one provider and wants the agent to decide which one answers. That is a narrower audience than it first appears. If you hold a single API key, the routing layer has nothing to choose between, and the README is explicit that routing degrades to the available families when one is missing. The project is published as a monorepo on npm under @openabcode/coding-agent, written in TypeScript, with a website at openabcode.com.

How the classifier and the execution model stay separate

The design detail worth understanding is that classification and execution are two different model choices. The README's setup flow makes this explicit in step two: /route-model selects the authenticated model that classifies tasks, and the README states this does not change the active execution model. Step three is where you pick one concrete model per family, for example gpt-6-astra for OpenAI, gemini-3.8-flash for Google, claude-fable-5 for Anthropic. Route then executes with exactly the model you selected for whichever family the classifier chose. That split has a practical consequence: a cheap, fast model can do the classification while an expensive one does the work, and you can swap the classifier without disturbing execution. The architecture section lays out three layers. The user prompt enters @openabcode/coding-agent, which holds Route configuration and model selection. That hands off to @openabcode/ai, which makes the classifier and provider API requests. @openabcode/agent-core runs the agent loop, state and tool execution. The terminal UI is its own package, @openabcode/tui, which renders the model selectors, the Route footer and session views. Auditability is built into the loop: the README states every completed routing decision is stored in the session JSONL, and manually overriding a routed model is recorded as veto feedback. That veto record is the most interesting part of the design, because it turns disagreement with the router into data rather than a silent correction.

Installing OpenABCode and running the first routed task

The README offers a hosted installer and three package managers. The npm path passes --ignore-scripts, which matches the project's stated supply-chain posture that local release installs, documented npm installs and openabcode update --self all use that flag where supported.

npm install -g @openabcode/coding-agent --ignore-scripts

Alternatives listed in the README are bun install -g @openabcode/coding-agent and brew install matrixmapai/tap/openabcode. After install, start the agent with no arguments.

openabcode

Route is off until you configure it. The README gives four steps, run as slash commands inside the session. First run /login and configure the providers you want to use. Then run /route-model and select the authenticated model that classifies tasks; the README stresses this does not change the active execution model. Then run /model and pick one specific model per family, for example gpt-6-astra, gemini-3.8-flash and claude-fable-5. Finally run /route and select on. When Route is on, the README says the footer shows the configured execution models, so the footer is your confirmation that setup took. Routing works as long as at least two model families are configured; with one family missing it degrades to the available ones rather than failing.

Overriding the router rules in settings.json

The built-in routing table is not fixed. Route rules, heuristic keywords, file extension mappings, project markers and the default provider can all be customized in ~/.openabcode/agent/settings.json for the global scope, or .openabcode/settings.json at project level. The README states that when a field is set, it fully replaces the corresponding built-in default. That replace-not-merge behaviour is the single most important thing to internalize before you edit the file, because adding one keyword to the openai list without repeating the rest silently drops the defaults you did not retype. The README also notes each field is optional and independent, so you can override fileExtensions and leave keywords alone.

{
  "router": {
    "rules": {
      "openai": "Test and automation — algorithms, code review, testing, data analysis, scripting",
      "google": "Google ecosystem — Android, Flutter, Firebase, Google Cloud",
      "anthropic": "General development — all code writing, editing, debugging, architecture, UI"
    },
    "keywords": {
      "openai": ["algorithm", "unit test", "benchmark", "data analysis", "pipeline"],
      "google": ["android", "flutter", "dart", "firebase", "gcp"],
      "anthropic": ["refactor", "debug", "architecture", "migration"]
    },
    "fileExtensions": {
      ".dart": "google",
      ".rs": "anthropic",
      ".ts": "anthropic",
      ".sh": "openai"
    },
    "projectMarkers": {
      "pubspec.yaml": "google",
      "cargo.toml": "anthropic",
      "package.json": "anthropic",
      "main.tf": "openai"
    },
    "defaultProvider": "anthropic"
  }
}

The defaults embedded in that example are opinionated in ways worth questioning. Mapping .rs to anthropic and .ts to anthropic while sending .sh to openai is a judgement about which family writes which language best, and it is the project's judgement, not a measured result. If your repository is mostly Rust, the default provider and the extension map will send nearly everything to one family, and the routing layer stops earning its keep. The project markers work the same way: pubspec.yaml pulls a task toward Google, main.tf toward OpenAI. These are heuristics over file extensions and marker files, and the README does not describe any evaluation of how often they agree with what a developer would have chosen.

No permission system, and what the containerization docs suggest instead

This is the limitation that should decide adoption for many teams. The README states plainly that OpenABCode does not include a built-in permission system for restricting filesystem, process, network or credential access, and that by default it runs with the permissions of the user and process that launched it. An agent that executes tools and shell commands with your full user rights, holding API keys for three providers, is a different risk profile from one that prompts before each write. The project's answer is external isolation. The containerization document referenced at packages/coding-agent/docs/containerization.md describes three patterns. The Gondolin extension 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 openabcode process in a local container for simple isolation. OpenShell runs the whole process in a policy-controlled sandbox. Choosing between them is a real decision: Gondolin preserves host-side credentials but only isolates the tools, while plain Docker isolates everything including the process but moves your credentials into the container. The README does not document rollback, and it does not describe what happens to a half-applied edit when a routed task fails mid-run, so treat failure recovery as unverified until you observe it.

How OpenABCode differs from single-model agents like Claude Code

The obvious comparison is a single-provider agent such as Claude Code, where one vendor's model handles planning, editing and review, and billing comes from one account. OpenABCode's difference is not cosmetic. It inserts a classification step before execution, keeps a separate model for that classification, and records both the decision and any manual override in the session JSONL. A single-model agent has no equivalent artifact, because there is no decision to record. The trade-off runs the other way too. With one model you learn its behaviour and can predict cost per task; with a router you inherit the classifier's mistakes, and the README documents no accuracy figure for it. A misrouted task is not merely slower, it is answered by a model you did not choose, and the only remedy the README describes is the manual override that gets logged as veto feedback. If your work is homogeneous, a single-model agent is simpler and its cost model is legible. If your work genuinely spans Android or Flutter alongside backend refactoring and a review-heavy test suite, the routing table is doing something a fixed model cannot. The honest position is that OpenABCode is worth its extra configuration only when the task mix is wide enough that no single family is the right default.

Licence, maintenance and what an upgrade actually costs

OpenABCode is licensed AGPL-3.0, and the README notes that portions derived from Pi remain under the MIT License, with attribution in the NOTICE file. AGPL-3.0 is a copyleft licence with a network clause, which matters if you modify the agent and expose it to users over a network. This is a description of the licence text, not legal advice; if you plan to embed or modify it in a product, have someone qualified read the terms. The repository is not archived and the last push was on 2026-09-16, the same day as the v1.1.0 release, so the project is being worked on now. Upgrade cost is unusually well documented for a project this young. The check pipeline runs biome, a pinned-dependency check, a TypeScript import check, a shrinkwrap check, an install-lock check for the coding-agent package, tsgo --noEmit and a browser smoke test. Direct external dependencies are pinned to exact versions, .npmrc sets save-exact=true and min-release-age=2, and the published CLI ships packages/coding-agent/npm-shrinkwrap.json to pin transitive dependencies. Pre-commit blocks accidental lockfile commits unless OPENABCODE_ALLOW_LOCKFILE_CHANGE=1 is set. The cost of that discipline lands on contributors rather than users: adding a dependency with a lifecycle script fails checks until it is reviewed and allowlisted. For an adopter, the practical effect is that a version bump is unlikely to pull an unreviewed transitive change, and openabcode update --self uses --ignore-scripts where supported.

Editorial conclusion

Adopt OpenABCode if your work genuinely splits across Google ecosystem code, review and testing, and general development, and you already hold credentials for more than one provider family, because the README states routing needs at least two configured families. Skip it if you want a single model with predictable billing, or if you need a built-in permission system: the README says there is none, and points to containerization patterns instead. Before committing, verify three things in your own checkout: that /route-model accepts a classifier you trust, that your settings.json overrides replace rather than extend the built-in defaults as the README claims, and that the session JSONL records a routing decision for every task you run. Everything else, including whether the classifier's judgement matches your intent, only shows up once you run real prompts through it.

Frequently asked questions

Official sources

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