If you pay for both Claude and ChatGPT, you own two rate-limit windows and you are spending one of them. The tool is one command to install and it is directly below. The rest of this guide is how it decides — and why the extra capacity matters less than being able to have one vendor's model grade another vendor's work.
cross-model-orchestrate is three things in one package, and it helps to know which is which:
cmo — reads both subscriptions' remaining headroom and dispatches a single task to whichever model should run it;cmo serve — only if you run agents on more than one machine, so they can see each other's work.No dependencies, no build step, no API key — it drives the codex and claude tools you already have logged in.
Both of those have to exist first. cmo drives them; it does not replace them, and it has no models of its own. If either is missing or not logged in, the meter it reads cannot answer and work runs on one vendor — which is the situation this whole tool exists to get you out of.
npm install -g @anthropic-ai/claude-code npm install -g @openai/codex claude # log in, then quit codex # log in, send it one message, then quit
The message to Codex is not ceremony. It writes Codex's first session file, and that file is where cmo reads your Codex usage from. Until one exists the Codex meter reads no session rollouts found and routing has to guess.
# installs the `cmo` command — and only that npm install -g cross-model-orchestrate # wires the skill and the subagent into every agent tool on the machine cmo install # checks both CLIs, auth, model IDs, headroom, and the install itself cmo doctor
Or read it before you run it — reasonable for a tool that will drive agents on your machine unattended. It is a few hundred lines of dependency-free JavaScript:
git clone https://github.com/matthew-locastro/cross-model-orchestrate
cd cross-model-orchestrate
npm test # 121 offline tests: no network, no spawn, nothing spent
npm install -g . && cmo install
Both steps matter. The npm install puts a command on your path and nothing else. It is cmo install that symlinks the skill into every agent tool that reads skills — Claude Code, Codex, Kilo, OpenCode — and drops the codex-runner subagent into Claude Code, which is what makes /cross-model-orchestrate callable. Package installers that reach outside their own directory are bad manners, so it is a deliberate opt-in rather than something that happens to your home directory unannounced.
No root anywhere. Both steps write only inside your home directory, and nothing is installed per project. cmo doctor checks the five things that actually break — a tool missing, a tool not logged in, a model ID your plan does not offer, a skill that never installed, a dead usage endpoint — and says which.
One command, and it covers everything that can go stale — because four different things can, and the version you check is rarely the one that runs:
# prints the plan and stops. nothing runs without --yes
cmo update
cmo update --yes
That upgrades both vendor CLIs, cmo itself, and the installed skill when it is a copy rather than a symlink — a copy does not follow an upgrade, which is how you end up running a current CLI against last version's instructions with nothing saying so. Pass --clis-only to leave cmo alone.
It refuses while dispatches are running on the machine, because swapping the codex binary mid-run can change model IDs underneath agents that already resolved them. It only runs a command whose install method it actually detected — telling a Homebrew user to npm install leaves two copies and a PATH puzzle — and it reports the version before and after, so updated means something changed rather than that a command exited 0.
If you run cmo serve, it will remind you that a coordinator started days ago is still running the code it loaded then, and tell you how to check whether that actually matters before you bounce it.
One way, and the constraint is worth stating flatly: the orchestration only runs from Claude Code. Start a session in the directory the work belongs in, put the orchestrator on a frontier model, and describe what you want in plain English.
# the orchestrator does the least work and the most deciding claude --model opus --effort high # then, in the session: /cross-model-orchestrate build the thing, and fan it out
That is the entire interface. You do not write the workflow script and you do not choose models. The skill reads both meters, decides whether the request is a fan or a queue, writes the script, and dispatches each subagent — some to Codex, some to Claude, every review forced onto the vendor that did not produce the artifact. It has to be Claude Code driving because the fan-out needs two primitives nothing else exposes: a barrier for steps that need every result at once, and a cache keyed on each step's prompt so an interrupted run replays instead of paying twice.
The model to spend carefully on is the one doing the least typing. The orchestrator produces no artifacts; it decides the shape of the run. Across a few hundred subagents it is a low single-digit share of the tokens and all of the control flow — and a cheap one that puts a barrier where a pipeline belonged costs more in wasted wall-clock than the model ever saved, silently, at the start.
Opus at high effort is the floor; xhigh when the run branches a lot or runs overnight. Cheap tiers are for the subagents.
One machine's view covers one machine. If you run agents on several boxes against the same subscriptions, run the coordinator once and point them all at it:
# on whichever machine is always up export CMO_FLEET_TOKEN=$(head -c 32 /dev/urandom | base64 | tr -d '=+/') cmo serve --host 0.0.0.0 # on every box, including that one export CMO_FLEET_URL=http://<reachable-host>:7867 export CMO_FLEET_TOKEN=<the same token>
A box is a machine, not a directory or a session, and project names come from each dispatch's working directory — so new projects need no registration. Run one coordinator per account pair: machines on different accounts are not competing for the same windows, and sharing one would make them throttle each other for nothing.
Consumer AI subscriptions do not meter you per token. They meter you in rolling windows — a short one measured in hours, a long one measured in days — and each window refills on its own clock. When you see "you've hit your limit, try again at 5pm", that is a window, not a balance.
Two subscriptions means two of those windows, ticking independently, with nothing shared between them — and if you run an agent, you are almost certainly draining exactly one while the other sits at zero. The obvious move is to alternate and get roughly twice the runway. That is real, and on a long unattended run it is the difference between finishing and not. But it is the smaller of the two benefits.
The most reliable quality mechanism in multi-agent work is separating the thing that makes the work from the thing that judges it. An agent asked to grade its own output approves it — not from vanity, but because the context that produced the choices is being asked to find fault with them, having already decided they were right. On the image pipeline we documented, a grader that produced none of the candidates rejected 38 of 57. That rejection loop was the quality.
Independence in context is not the same as independence in judgment. Two agents can be strangers to each other and still share every blind spot they have.
A different vendor decorrelates a second axis. It does not make the grader right; it makes its errors different from the producer's, which is the property you want from a reviewer. That is a mechanism argument, not a measured one — nobody has published the controlled comparison. But it is why you ask a second doctor who trained somewhere else, and it costs nothing if you already pay for both.
Once two vendors are on the table, every subagent needs a decision made before it is spawned: which vendor, which model, how much reasoning effort. Made by feel, that decision does not survive past about five agents and is never reproducible. So it becomes a function.
Three properties of the task set the tier — how capable a model the work deserves:
| factor | weight | what it measures |
|---|---|---|
| complexity 1–5 | 45% | how much reasoning the task needs, independent of how big it is |
| length xs–xl | 30% | how much work and output it produces |
| role | 25% | what kind of work it is |
Role earns its own weight because two tasks of identical size and reasoning depth can still deserve different models. Renaming a symbol across forty files is long and trivial. Scoring three candidates against a rubric and rejecting all of them is short and consequential.
The weighted score lands in one of three tiers — fast, balanced, frontier — and each tier maps to a model on each vendor. That map has to be configuration, not a constant: different plans expose different model lists, and both vendors rename things on their own schedule. A hardcoded model ID is a tool that breaks on someone else's account.
Then the vendor, in strict precedence:
Then corrections for token efficiency, because the score alone will buy an expensive model to do cheap work. Skimming a quarter of a million tokens on a frontier model is the most common way a fan-out wastes a subscription — that is bulk reading, and it drops a tier. A grader never drops to the cheapest tier: a cheap grader is a generous grader, and a generous grader silently ships everything.
Two behaviours are worth provoking. Turn on reviewing codex output and push Claude past 95%: the review does not vanish, it degrades — back onto Codex, flagged as same-vendor and given a better model to compensate. Then push a provider into the 85–95% band while it is the only candidate: the model drops a tier to stretch what is left. Graders are exempt from that one.
All of that depends on knowing what is left, and a probe that itself costs usage would be self-defeating. Neither vendor charges you to ask, but they answer in completely different ways.
Codex writes it to disk. Every non-interactive run leaves a session log on your machine, and each turn in it carries the current rolling-window snapshot: percent used, window length, reset time. Reading it is a local file read — free, instant, no network — and it refreshes itself: every Codex subagent you dispatch updates the number for the next decision.
There is a version-specific trap in that file, and it is exactly the kind that produces a confidently wrong dashboard. The snapshot has two slots, conventionally read as "short window" and "long window". In the current CLI release the weekly figure arrives in the first slot with the second empty; older builds put the five-hour figure there. Code that decides which window it is looking at from slot position will label a weekly number as an hourly one — and be wrong in the reassuring direction. Each entry also states its own window length in minutes. Read that, not the position.
Claude answers over the network. It does not persist its rolling-window snapshot locally — what it keeps on disk is historical token counts, a different question. The live figure comes from an authenticated usage endpoint that runs no inference, returning utilization and reset times without generating a token.
That endpoint has one failure mode worth designing for, because it is silent. The credential it authenticates with is short-lived — hours, not days — and when it lapses the endpoint simply stops answering. The meter does not read zero or read wrong. It goes dark.
Repairing it is a small lesson in not guessing. The obvious candidates — asking the CLI for its auth status, running its health check, listing its agents — all read the stored credential without authenticating, so they leave an expired one expired. Only a real inference call refreshes it. The cheapest honest fix, then, is to spend the smallest turn that exists: the fastest model, an empty working directory so no project context loads, a one-line system prompt in place of the agent preamble. A few hundred tokens against a window measured in millions, spent only when the credential has already lapsed. Every one of those four candidates looked like it should work; the only way to know which did was to expire a token on purpose and try them.
Then the part that catches everyone. Both numbers lag. They describe consumption the vendor has already accounted for, and say nothing about the agents another run launched a minute ago — so two orchestrators both read 80%, both see room, and both sail through the limit. No amount of polling fixes that, because the information does not exist yet. The only fix is for each dispatch to declare what it is about to spend, before it spends it, somewhere the others can see. Effective headroom is then what the vendor reported plus what has been committed but not yet charged.
Here is the failure this defends against. A long run fans out; somewhere past the middle a window fills; agents start failing, nothing is watching, and the run keeps dispatching into a wall. In the morning you have half-finished work and no record of where it stopped.
Forty independent units, fixed cost each, two switches: whether the second subscription is in play, and whether anything checks the meter before dispatching.
The one-subscription blind run is the baseline, and the one most people are actually doing. But the switch that changes the character of the failure is the meter: a watched run that cannot finish stops on purpose and says which units are done and when the window reopens.
That only helps if stopping is cheap, which is a property of the run's structure. A workflow that caches each completed step replays the finished prefix in seconds, so hitting a limit is an interruption rather than a loss — the dynamic-workflow guide covers that, and the discipline that keeps parallel agents from colliding is what makes finished units safe to keep.
During the 253-agent image run, one subagent reached for a command that wanted a confirmation keystroke. It did not crash — it sat there holding its slot, waiting for a human who was asleep, for ninety-one minutes. Four rules come out of that and the runs around it, and every dispatch enforces them:
429 and 401 as content. An agent writing anything at all emits three-digit numbers, and a pattern for "5xx" matches every one of them from 500 to 599.Cross-model review only works if the dispatcher enforces it rather than the person writing the prompt remembering to. One flag on a review task — this came from vendor X — and the rest follows.
What happens when the other vendor is out of headroom is the interesting case, and the obvious answer is wrong twice over.
Refusing is tempting — a review by the wrong party sounds like no review. But look at where the quality came from: the grader that rejected 38 of 57 candidates was the same vendor as the generators. Not having made the thing is the larger half of independence, and refusing trades a good review for none.
The hazard is narrower than it looks. Not that a same-vendor verdict is weak — that an unlabelled one is indistinguishable from a cross-vendor one, so you get the reassurance without the second opinion. That is a labelling problem, not a licensing one.
So the fallback runs, marked. The verdict carries whether it was cross-vendor or same-vendor, the caller branches on it, and the run reports the split. Two mitigations ride along: the degraded grader gets a more capable model rather than a cheaper one, since it has to catch what it is predisposed to miss — the one place a constrained provider is spent up instead of down. And it is told about its handicap, instructed to work the rubric criterion by criterion and resolve anything arguable against the artifact rather than form an impression it is poorly placed to form.
A same-vendor verdict is provisional, not void. Label it, spend more model on it, and re-grade it when the other window reopens.
Two more rules earn their keep here, both inherited from ordinary judging rather than anything AI-specific.
Make the verdict structured. The judge returns a typed object — a score, an enum, a written correction — not prose. A script that branches on natural language will eventually read a differently-phrased refusal as an approval, at three in the morning, on the one run you did not watch. The same discipline that makes a spec checkable against acceptance criteria is what makes a verdict safe to branch on.
Give it rules that override the score. An aggregate out of 25 can be talked around; a hard reject cannot. In the image run one candidate scored best-in-slot on subject accuracy and was rejected outright for carrying a real trademark — encoding that as an automatic reject is what stopped the grader negotiating with itself.
Everything here assumes a machine still running in nine hours, which is the part people underestimate. A run that fans out across dozens of subagents, pauses on a usage limit and resumes when the window reopens is not something you babysit on a laptop — and a closing lid ends it.
TermRoam is a dedicated always-on server for exactly this: one persistent session per task that survives disconnection, an isolated checkout and branch per agent so concurrent work cannot collide, and logs you can reattach to from a phone. Start a run before dinner, close the laptop, reattach to a finished pipeline — or to the one step that stopped, which the cache lets you re-run alone.
Still deciding which coding agent to start with? The comparison of Claude Code and Codex is the better first read. This page is what you do once the answer is "both".