Claudexor: a local control plane for the coding agents you already pay for

The gap Claudexor fills between vendor CLIs

Each vendor CLI is a closed loop. Codex CLI knows nothing about your Claude Code session, Claude Code cannot see the Cursor subscription you also pay for, and none of them share a thread. If you hold several subscriptions, you are the router: you remember which account has quota left, you retype context into the next tool, and you have no record of what a run cost.

Claudexor's answer is a local-first control plane that runs those harnesses behind one typed interface. The README describes it as "a chat of turns where read-only questions resume the vendor's own native session, write turns land as inspectable patches, races pit harnesses against each other with cross-family review, and every claim (cost, quota, web evidence, auth route) is a typed fact you can audit, never a vibe." That last clause is the design thesis: the tool would rather report an unknown cost than print $0.

The audience is narrow and specific. It is for engineers who already hold Claude, Codex, Antigravity or Cursor subscriptions and want them pooled, not for someone looking for a free way into a model. It is macOS-first for the desktop app, with the CLI and daemon also running on Linux.

How the control plane, daemon and artifacts fit together

The repository is a pnpm monorepo with apps/, packages/, plugins/, benchmarks/ and release/ directories, and a turbo.json build graph. The README separates the surfaces: a CLI, a daemon called claudexord, a control API, and a desktop app that bundles its own daemon runtime and starts it on launch.

Two mechanisms carry most of the weight. The first is credential profiles: named Antigravity, Claude, Codex and Cursor subscription bindings that sit side by side, each with Claudexor-scoped state and platform-declared credential custody. Live subscription-quota tracking then feeds an opt-in policy that rotates a spent account out of the way on typed vendor limits. The README is explicit that this covers only the harnesses with a vendor usage source, which it lists as Antigravity, Claude and Codex, and that Cursor has none yet.

The second is the thread model. Read-only questions resume the vendor's native session, so a question does not fork a parallel conversation. Write turns land as inspectable patches rather than silent edits. Races run several harnesses against the same task with independent reviewers and arbitration, which is why the project describes cross-family review rather than self-review. Artifacts on disk are the source of truth, and the README states there is no telemetry.

Installing Claudexor from npm and running a first turn

The prerequisites are Node.js >= 20.19, pnpm via corepack, Git for isolated workspaces and candidate envelopes, and at least one logged-in vendor CLI (codex, claude, cursor-agent, opencode or agy) or a provider API key. The README is blunt about one point: log in through Claudexor, not the bare vendor CLI.

The global install brings in two binaries, claudexor and claudexord:

npm install -g claudexor
claudexor doctor

The doctor command is the first thing to run, because Git and the vendor harnesses are separate capabilities that get checked before a run starts. If you prefer to build from source, the README points to the Quickstart section instead.

On macOS the app is the shorter path. It ships as a signed and notarized DMG, so it installs without Gatekeeper warnings: download Claudexor-<version>.dmg from Releases, drag Claudexor.app into Applications, and open it. The app starts its bundled engine, then onboarding checks the external Git and harness route needed by the work you select. Installing the CLI is only necessary for terminal use.

The monorepo itself builds with turbo and pnpm, and the scripts in package.json show the expected sequence:

pnpm install
pnpm build
pnpm typecheck
pnpm test

The release verification script chains build, typecheck, the test tsconfig, vitest, schema generation and a docs truth check, which tells you the maintainers treat generated schemas and documentation as build outputs rather than prose.

Where Claudexor gets in your way

The quota rotation feature has a hard boundary that the README states rather than hides: it works for harnesses with a vendor usage source, and Cursor has none yet. If Cursor is your main subscription, the headline rotation feature does not apply to it, and you are back to watching usage yourself.

The credential model is also deliberately restrictive. Profiles carry Claudexor-scoped state and platform-declared credential custody, and the README tells you to log in through Claudexor rather than the vendor CLI. That is a real migration cost if you already have working logins, and it means an extra layer sits between you and the vendor's own auth flow. Anyone who wants the vendor CLI to remain the only thing touching credentials should not adopt this.

The stability posture is another constraint. The README says retired verbs and mode ids hard-error with the new spelling instead of silently aliasing. That is good for catching stale scripts and bad for anyone upgrading casually across a major version. If your team pins an older release and does not read changelogs, expect breakage rather than a deprecation warning.

Finally, the embedded model operation is not a general-purpose gateway. The README describes a single model request through a managed Codex subscription where the caller supplies its own system prompt and tools and executes those tools itself, and explicitly says this is not a public OpenAI-compatible server or a second agent loop. Teams looking for a drop-in OpenAI-compatible endpoint will not find one here.

Claudexor and CLIProxyAPI take different routes to the same subscriptions

The README credits Praxis Relay and CLIProxyAPI as prior work exploring subscription-backed model transports, and states that neither runs as an embedded relay or owns credentials in this integration. The comparison is worth taking literally, because the two designs diverge on where the boundary sits.

CLIProxyAPI's approach is a relay: it exposes an OpenAI-compatible surface backed by subscription credentials, so existing clients keep working against a familiar API shape. Claudexor does the opposite. It does not present itself as a public OpenAI-compatible server, and its embedding path is described as a typed engine operation where the caller owns the system prompt and the tool execution. The unit of work is a chat of turns with artifacts on disk, not a proxied HTTP request.

That difference decides the fit. If you have tools already written against an OpenAI-compatible endpoint and you want them pointed at a subscription, a relay is the shorter path. If you want races between harnesses, a shared thread, quota rotation across named accounts and inspectable patches, Claudexor is built around those, and the relay model does not provide them. The README also notes that model catalogs and context limits are account-specific, and that subscription access does not guarantee zero incremental charges, which applies to any tool in this space.

Licence, packaging and what upgrades actually cost

Claudexor is MIT licensed. The monorepo package.json declares "license": "MIT" and the repository is private at the workspace root, which is normal for a monorepo whose published artifact is the claudexor package on npm. MIT means you can read, modify and redistribute the code, and it also means there is no warranty. Nothing here is legal advice; if you plan to redistribute a modified build, read the LICENSE file in the repository yourself.

Upgrade cost is shaped by the release process visible in the repository. The project uses changesets for versioning, with scripts named changeset and version-packages, and a release:verify:node script that chains build, typecheck, the test tsconfig, vitest, schema generation, a git diff check on packages/schema/generated, schema validation, a docs truth check, a concept gate and staged and retired key checks. Generated JSON schemas are committed and validated, so a schema change is a reviewable diff rather than a runtime surprise.

The flip side is the hard-error policy for retired verbs and mode ids. Combined with the fact that the workspace version in package.json (3.12.0) runs ahead of the latest published release listed in the README (v3.10.2), you should read the changelog between the version you run and the version you install. The repository keeps a CHANGELOG.md and a CLAUDEXOR_BIBLE.md at the root, and both are worth a look before a jump across minor versions.

Editorial conclusion

Adopt Claudexor if you already pay for more than one coding-agent subscription and want their sessions, quotas and review passes in one auditable place. Skip it if you run a single harness on one account, or if you expect Cursor quota tracking: the README states Cursor has no vendor usage source yet. Before trusting it, run claudexor doctor and open the app's Workspace Git check, because Git and the vendor CLIs are separate capabilities checked before a run starts, and log in through Claudexor rather than the bare vendor CLI.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. razzant/claudexor on GitHub
4. README
5. Releases