Claudexor: a local control plane over the coding agent CLIs you already pay for

The gap Claudexor fills between your subscription and your terminal

Most engineers running coding agents end up with the same problem set: several paid subscriptions, each with its own quota window, its own login state, and its own session that forgets everything the moment you switch tools. Claudexor positions itself as a local-first control plane for exactly that situation. The README describes it as running Codex CLI, Claude Code, Cursor CLI, OpenCode, Antigravity CLI and raw API adapters behind one typed interface, where a chat is a sequence of turns. Read-only questions resume the vendor's own native session; write turns land as inspectable patches. The audience is narrow and identifiable: people who already pay for more than one of these tools and want them coordinated rather than used one at a time. It is not aimed at someone who has never installed a vendor CLI, and it is not a hosted service. Everything runs on the machine, files are the source of truth, and the README states there is no telemetry.

Turns, patches, races: the mechanism behind the typed interface

The architecture visible in the README is a turn-based chat abstraction sitting on top of vendor sessions. Two turn types behave differently. Read-only questions are routed back into the vendor's own native session, which means the vendor keeps its own context rather than Claudexor reconstructing it. Write turns are not applied silently; they come back as patches you can inspect, which is the reason the artifact layout and delivery sections exist. On top of that sits the race mode: harnesses are pitted against each other, and the result is reviewed across model families with arbitration. That cross-family review is the part a single vendor cannot offer, because a vendor will not run its own competitor as an independent reviewer. The README also mentions deterministic gates and protected paths, and an accounting rule worth quoting in its own words: unknown cost is never treated as zero. That single design decision tells you more about the project's posture than any feature list. A tool that refuses to report $0 for an unmeasured cost is designed for people who audit spend, not for people who want a rough dashboard.

Credential profiles and the quota rotation policy

Since version 2.1 the project has credential profiles: named Antigravity, Claude, Codex and Cursor subscription bindings that sit side by side, each with Claudexor-scoped state and what the README calls platform-declared credential custody. The practical consequence is that multiple accounts for the same vendor coexist without overwriting each other's login. Live subscription-quota tracking then feeds an opt-in policy that rotates a spent account out of the way when a typed vendor limit is hit. Two constraints matter here. First, the rotation policy is opt-in, so the default behaviour is not automatic switching. Second, coverage is uneven by design: the README states that the harnesses with a vendor usage source are Antigravity, Claude and Codex, and that Cursor has none yet. If your workflow is Cursor-only, the headline quota feature does not apply to you. The rotation also triggers on typed vendor limits, meaning the vendor has to report the limit in a form Claudexor can read; an untyped failure is a different case.

Getting it running: npm, doctor, and the login rule people miss

The install path is short. The README gives these commands:

npm install -g claudexor claudexor doctor

That installs the claudexor and claudexord bins. Prerequisites are Node.js >= 20.19, pnpm via corepack enable pnpm, Git for isolated workspaces and candidate envelopes, and at least one logged-in vendor CLI (codex, claude, cursor-agent, opencode, or agy for Antigravity) or a provider API key such as OPENAI_API_KEY or ANTHROPIC_API_KEY as a fallback. On macOS the desktop app is a signed and notarized DMG that bundles its own daemon runtime and starts it on launch, so the CLI install is only needed for terminal use. The rule that catches people is stated plainly in the prerequisites: log in through Claudexor, not the bare vendor CLI. If you authenticate with claude or codex directly and then expect Claudexor to pick up that session, you are working against the documented setup. The doctor command is the intended first check, and it reports Git availability, which matters because the app's Workspace Git check decides whether your selected workspace shape is admitted.

Where Claudexor is the wrong tool

The most concrete limitation is already in the README: Cursor has no vendor usage source yet, so quota tracking and the rotation policy do not cover it. A second boundary is the embedding surface. Claudexor exposes a typed engine operation that lets a caller make a single model request through a managed Codex subscription, with the caller supplying its own system prompt and tools and executing those tools itself. The README is explicit that this is not a public OpenAI-compatible server and not a second agent loop. If what you want is a drop-in API endpoint that mimics OpenAI's shape, this is not it, and the documentation points to a transport, retention and unsupported-parameter contract rather than an API compatibility promise. Third, the README warns that subscription access does not guarantee zero incremental charges and does not enable provider-paid credits, and that model catalogs and context limits are account-specific. Anyone assuming a flat subscription makes per-call cost disappear is reading it wrong. Finally, the hard-error policy on retired verbs and mode ids means an upgrade can break existing scripts instead of silently aliasing them. That is a deliberate choice, and it is the opposite of a smooth upgrade path.

How this differs from a proxy or relay approach

The README names Praxis Relay and CLIProxyAPI as prior work exploring subscription-backed model transports, and credits them as design influences. The stated difference is architectural: neither runs as an embedded relay here, and neither owns credentials in this integration. That is the real fork in the road. A relay-style tool concentrates on moving requests to a subscription-backed transport, which is useful when the goal is to point existing OpenAI-shaped clients at a different account. Claudexor instead owns the session, the turn history, the patch artifacts, the credential profiles and the quota state, and treats the vendor CLIs as harnesses it drives. The trade-off follows directly: a relay is easier to slot under an existing client, while Claudexor asks you to move your workflow into its chat and workspace model to get the rotation, gates and cross-family review. If you do not want that workflow, the relay approach is the lighter answer. The README also notes that Claudexor runs as the exact-pinned delegated execution layer inside Ouroboros, a separate self-developing agent that owns its own tasks, memory, review and final integration. That is a concrete example of the control plane being embedded rather than used interactively.

Maintenance cadence, stability contract and licence

Release cadence is visible from the tags: v3.10.0, v3.10.1 and v3.10.2 landed on consecutive days in September 2026. That is a fast patch rhythm, and it cuts both ways. Fixes arrive quickly, but a project shipping point releases daily is one where you should read release notes before upgrading rather than assuming compatibility. The README addresses this with a Stability at 2.0 section that separates what is a stable contract from what remains experimental, and it states that retired verbs and mode ids hard-error with the new spelling instead of silently aliasing. Treat that section as required reading before any upgrade, because it is the document that tells you which parts of your usage are safe. The licence is MIT, which is permissive and places few obligations on how you use or redistribute the code; this is a description of the licence identifier in the repository, not legal advice, and anyone embedding Claudexor in a commercial product should read the LICENSE file and the credential-custody claims themselves. The uninstall section documents where your data lives, which is the relevant reading if you care about the local-first claim. On cost: the project is local-first with no telemetry, so the running cost is your existing subscriptions plus whatever the vendor charges beyond them, which the README explicitly declines to promise is zero.

Editorial conclusion

Adopt Claudexor if you already hold more than one Claude, Codex or Antigravity subscription and want the quota rotation, shared thread context and cross-model review that the vendor CLIs do not ship, and if you are willing to log in through Claudexor rather than the bare vendor CLI. Do not adopt it if Cursor is your only harness: the README states Cursor has no vendor usage source, so live quota tracking and automatic rotation do not apply there. Before committing, run claudexor doctor and read the Stability at 2.0 section, because retired verbs and mode ids hard-error rather than aliasing, and that is the first thing an existing script will hit.

Official sources

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