How to bridge to Codex after hitting the Claude Code weekly limit

I kept hitting my weekly limit about three days in while building and running eight products solo in Claude Code. I posted a help thread about it and got a lot of good suggestions in replies, DMs, and texts from friends. Here's what I actually built and why.

This follows my earlier post on what it costs to build and run eight products. That one was about dollars. This one is about the other scarce budget: weekly model capacity.

The obvious fix wasn't the fix

The obvious answer to running out of Claude is to use another model. That sounds simple until you notice Claude Code is no longer just the model writing your code.

The harness

A model is the intelligence. A harness is the system around it that lets that intelligence do useful work. Claude Code is itself an agent harness: it gives the model access to files and tools, lets it take actions, and coordinates the work.

In my case the harness is more than the app. It includes my global and project instruction files, persistent project memory, reusable skills and checklists, MCP connections, git and testing rules, /save, /compact, and /wrap, and the conventions that decide how work gets planned, implemented, reviewed, and handed to the next session.

So when I say I didn't want to leave Claude, I mean I didn't want to leave the operating system I'd built around Claude Code. The desktop app is the cockpit. The harness is the cockpit plus the instruments, procedures, maps, checklists, and flight log. That distinction is the whole reason this wasn't as simple as opening another coding app.

I'm not an engineer. I work in the Claude Code desktop app and I'm finally fluent in it. Switching to a different terminal tool every Thursday would buy me tokens and cost me the thing that actually makes eight products manageable: one workflow, one memory system, one source of truth. Do that across a portfolio and you risk eight products slowly drifting into eight different setups.

So I didn't want to replace Claude Code. I wanted to give it another worker.

Solution

I installed OpenAI's Codex plugin for Claude Code and connected it to my ChatGPT account. The mental model: Claude Code stays the operating system, Codex becomes an implementation worker inside it.

Claude still owns the judgment: product and architecture decisions, ambiguous requirements, high-risk work, canonical memory, final review, and the session wrap. Codex takes the clear stuff: well-specified implementation, tests, routine bug fixes, mechanical refactors, established UI patterns, first-pass verification.

I still describe work normally. I don't want to pick a model, choose an effort level, or remember special commands every time I ask for a change. I added routing rules to my harness so Claude decides whether to handle the task itself or delegate it to Codex. One source of truth, two pools of coding capacity.

Keeping one source of truth

My whole concern was avoiding fragmentation in the system I'd already built. My global Claude doctrine is large, grown from rules, lessons, and failure modes collected across the portfolio. Making Codex read all of it before every task would burn an enormous amount of context.

So Codex reads a compact projection instead: a core file with the rules it needs most often, git and working-tree safety, migration and production-data rules, Supabase and RLS guardrails, secret handling, testing expectations, copy and claims boundaries, scope discipline, and when to stop and ask. The full doctrine stays authoritative and wins any conflict; the core file points back to stable rule IDs when more context is needed. Codex also reads the product's own CLAUDE.md, memory index, and applicable shared skills. Claude stays the owner of canonical doctrine and memory. Codex gets what it needs without becoming a second operating system.

Sharing skills without copying them

Skills are shared by symlink, not copied, so there's still exactly one canonical copy-lint, ship-check, security-pass, and the rest:

mkdir -p ~/.agents
ln -s ~/.claude/skills ~/.agents/skills

Some Claude-specific skills may need compatibility tweaks over time, but there's no second skills folder quietly drifting out of sync. No separate Codex doctrine. No second memory system. That was the whole point.

Three modes

Claude can't reliably read my exact weekly allowance, so /wrap asks me where I am, and the harness applies the answer to the next session.

• Normal. Plenty of Claude left. Codex still handles routine implementation by default, so Claude is preserved for judgment rather than burned through just because the week reset.
• Conserve. Usage getting high. Codex handles nearly all exploration, implementation, testing, and first-pass review. Claude stays thin.
• Overflow. At or near the limit. Codex handles all nontrivial implementation. Claude does only dispatch, risk-based review, canonical memory, and wrap.

Delegating through the plugin still uses some Claude capacity, because Claude has to initiate and supervise the task. When usage is exhausted and paid supervision matters most, the harness can favor direct Codex execution instead: less seamless, but cheaper and more observable. That call belongs to the harness, not me.

Matching the model to the work

Same principle on both sides: pick the least expensive model likely to succeed on the first try. For Claude, that's roughly Sonnet for routine supervision, framing, review, and wrap; Opus for consequential architecture, billing, RLS, migrations, security, and hard debugging; Fable for the longest, multi-stage, cross-repository work. Codex follows the same shape, a smaller model for bounded mechanical work up to the strongest for difficult or consequential implementation. Model names change and differ by account, so my harness checks what's actually available rather than assuming. I shouldn't have to make that call by hand every time, so I don't.

Does it actually work?

I tested it on NoticeOfChange.com. The first task was small: add tests around disposable-email detection. Codex changed one file, matched the repo's test style, passed the unit suite and typecheck, needed zero corrections.

The second was the real tell. Codex found a live conversion bug I hadn't flagged: a same-page pricing link used Next.js <Link> instead of the repo's native anchor pattern, so it jumped instead of smooth-scrolling. It fixed the component, removed the now-unused import, added a source-guard test, proved the guard by mutating it, passed the suite, and touched exactly the two files it should have. No corrective round-trip. That's the worker I was skeptical of finding and fixing a real bug on its own.

The pilots also taught me that Claude supervision has a cost. If Codex implements a task and Claude then repeats all the exploration, testing, and review from scratch, the savings disappear. The right workflow isn't "Codex does the work, then Claude does all of it again." It's "Codex does the work, then Claude reviews in proportion to the actual risk." The plugin wrapper also hides some Codex usage detail you'd see running Codex directly, which is another reason the setup may lean toward direct execution when Claude is exhausted.

Is this the best setup for everyone?

Probably not. Plenty of people happily run several agents directly, or move to a model-neutral environment. I'll likely spend more time on a few of those, including Factory.ai, where my friend Maddie works, and Open Brain, which my friend Brovda suggested. My friend Ritchie told me to learn to code... thanks buddy.

But I optimized for my actual constraints: I'm not an engineer, I'm comfortable in Claude Code desktop right now, I already have a substantial system there, I want one source of truth, I run eight products and don't want their workflows drifting apart, and I need to keep building after the weekly allowance runs out.

This was the smallest bridge from the system I already trust to a second pool of capable coding capacity. It'll change. But I can keep building now, and that was the problem I actually needed to solve.

The rules Codex gets

If you want to copy the shape, here's a simplified version of the core file Codex reads before a task. Yours will differ. The value is in having one compact projection that defers to your real doctrine.

# Codex Doctrine Core

Canonical authority: ~/.claude/CLAUDE.md

Read before editing:
1. This doctrine core
2. The repository CLAUDE.md
3. The repository memory index and relevant memory
4. Applicable shared skills

The full global doctrine wins in any conflict.

Do not commit, push, deploy, access production, install dependencies,
modify canonical memory, or edit outside the repository unless explicitly
authorized.

And the operating instruction the harness follows:

Before every nontrivial implementation task, choose the appropriate worker.

Delegate clear routine implementation to Codex by default.

Claude owns ambiguity, consequential decisions, high-risk review,
canonical memory, and session wrap-up.

Choose the least expensive reliable model, effort level, and dispatch
path for the task.

A few details sit behind that simplified example: Codex has its own sandbox and approval settings, so I didn't assume Claude Code's permissions would carry over; the compact doctrine points back to the canonical one rather than becoming its own rulebook; Claude stays the only system allowed to update canonical memory; and I started with contained, low-risk tasks and inspected every diff before trusting the workflow more broadly.

The internal system keeps getting more sophisticated. The experience I want keeps getting simpler: describe the work, let the harness route it, review the result, keep building.

Replicate this in about 20 minutes

Prerequisites: Claude Code on any paid plan, a ChatGPT account (Codex is included at every tier, including free, so start with what you have and only upgrade if Codex's own weekly allowance runs dry), and Node 18+. Note there's no shared quota or linked billing: Codex usage counts against Codex, Claude against Claude.

1. Install the Codex CLI, then add the plugin from inside Claude Code. The CLI is a shell command. The plugin commands are slash commands you type inside Claude Code, and the reload step is the one people skip and then wonder why setup fails.

npm install -g @openai/codex
codex login

Then, inside Claude Code:

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

2. Give Codex a bridge to your instructions, not a copy. Create ~/.codex/AGENTS.md telling Codex to read, in order: a compact doctrine-core file, the repo's own CLAUDE.md, then the repo's memory notes. If your global instructions file is large, never make Codex read it whole. Distill your ten or so non-negotiable rules (git safety, what needs approval, testing standards, copy rules) into one small file that states plainly the full file wins any conflict.

3. Let Codex read CLAUDE.md files natively, and lock the sandbox. Add to the top of ~/.codex/config.toml:

project_doc_fallback_filenames = ["CLAUDE.md"]
sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

TOML gotcha that bit me: top-level keys must go before the first [section] header, or they silently land inside it.

4. Share your skills once, with a symlink, so there's no second copy to drift:

mkdir -p ~/.agents && ln -s ~/.claude/skills ~/.agents/skills

5. Write the routing rules down. Mine live in one file Claude reads every session: the three modes (normal, conserve, overflow) that I declare rather than the system guessing, which model tier handles what, and how much verification each risk level earns. Codex never commits, pushes, deploys, installs packages, touches production, or edits my memory files. Claude reviews, wraps, and merges.

6. Prove it before trusting it. Three cheap tests: ask Codex to report the byte count and first line of each instruction file (proves access, not claims), bait it with copy that violates one of your hard rules and confirm it refuses, then give it one contained real task and read the whole diff yourself.

Two warnings from real use: don't enable the plugin's automatic review gate, since it can loop Claude and Codex against each other and drain both quotas, and run one delegated job at a time.