I use claude and codex together. I use claude to write specs and plan, it delegates to codex to write the code and then claude checks it. So Claude for reasoning, Codex for coding.
I am burning through weekly usage limits on Codex in a single DAY and I am paying £89 / month!!!
CODEX model gpt-5.6-terra
I’m also confused because I was not hitting Codex limits for a while and only suddenly started hitting them after a short time. I have had to cancel the Codex subscription because it’s not worth it.
Can anyone else recommend a setup
I use a similar setup, but I separate the roles even more clearly.
The biggest improvement for me was to stop using Codex as a planner or as the main reasoning layer. I use regular ChatGPT for planning, architecture, problem analysis, and review. Codex only comes in once the task is already well-defined and ready to implement.
and as few open architectural decisions as possible.
That reduced usage a lot.
The expensive pattern is when Codex first spends time understanding the problem, then designs the solution, implements it, fixes its own mistakes, and finally reviews itself. That burns through usage very quickly.
I find it much more efficient to treat Codex as the execution layer, while keeping planning and reasoning outside it.
If you are already using Claude for planning, you are actually quite close to this setup. I would just avoid delegating broad planning or exploratory work to Codex and use it mainly for implementation and tests.
It does not eliminate the limits completely, but it makes Codex usage much more predictable and much cheaper.
WORK mode is stupiest thing ever – I wasted three usage resets before realising, that it was chats in WORK mode eating all my Codex usage and not Codex itself…
If you are burning through the limit that quickly, the main thing I would look at is how much work you are sending through Codex rather than simply switching models. Usage can vary a lot with task complexity, context, reasoning, and tool use. (OpenAI Help Center)
Your Claude → Codex workflow also means Codex may repeatedly receive large specs/context. I would try keeping Claude for planning/review and sending Codex only the focused implementation tasks. GPT-5.6 Terra is also positioned as the lower-cost GPT-5.6 option. (OpenAI)
That setup could significantly reduce unnecessary Codex usage.
Claude (Opus 5, 1M context) is the lead. It does the exploration and design work with me, writes the spec and the plan, then writes a task contract that states exactly what gets built, what’s off limits, and how it’ll be verified. Codex (pointed at the repo with write access) is the executor. It picks up that contract and writes the actual code, test first, one acceptance criterion at a time, then commits and leaves a handoff note. Claude never writes repo code itself, no matter how small the change, because the whole point is that the thing being reviewed wasn’t written by the reviewer. When Codex finishes, Claude reads the diff rather than the summary, checks it against the contract, runs a code review and a security review over it, runs the checks Codex couldn’t (anything needing Postgres, Redis, Stripe or a live service), and reports back to me.
I authored and maintain Codexometer … which was originally built to provide people a fun retro dashboard for consumption (but has grown in scope very significantly and can now manage sessions for example) - I’d be very happy to consider improving the data it exposes if available - I’m slightly wary of maintaining a bespoke set that isn’t available from the codex api instantaneously without having to maintain local history … I’ll take a look though!
This is actually almost the same role separation we use, just with a different stack — ours is currently OpenAI-only. The one thing that immediately stood out to me was:“one acceptance criterion at a time, then commits” I suspect that may be where a lot of your Codex usage is going.What works better for us is giving Codex one small but coherent implementation package containing several related acceptance criteria, instead of starting a separate execution cycle for each one. With very fine-grained execution, Codex may repeatedly pay the same overhead: re-orienting itself in the repo, loading context again, inspecting files, running tests, and re-validating the current state.
That could explain why, with an almost identical role separation, your Codex limit disappears so quickly while ours does not. Without seeing exactly how your workflow runs in practice, that is only a hypothesis — but it is the first place I would look.
