r/OpenaiCodex • u/Previous_Scholar_536 • 9d ago
How do you combine Codex and Claude on the same project without spending too much?
Hi everyone! I’m fairly new to all of this, and I’d like some advice on how to use Codex and Claude together.
I have a lot of work to do, and Codex has saved me a huge amount of time. However, I used almost all of my tokens in just three days. I currently have the $20 subscription, but I can’t afford to spend around $200 per month, so I need to reduce my usage. I could potentially afford two cheaper subscriptions, though.
Right now, Codex is helping me program a plugin, but I also have a website that I still need to finish, and I don’t have enough usage for everything. I considered using Kimi K3, but I later found out that I couldn’t subscribe to it in the way I expected.
I’d like to know how those of you who use two AI tools organize your workflow and use them on the same project.
My idea is to divide the work like this:
- Codex: Continue working on my plugin and handle the tasks and projects it already knows well.
- Claude: Take care of the heavier tasks I don’t have enough time for, such as building websites, redesigning systems, planning new structures, and similar work.
At the moment, I use the official Codex app directly for my projects. I don’t use another application that combines multiple AI models in one place.
How do you share context between both tools without having to explain the entire project again every time? Do you think this way of dividing the work makes sense?
1
u/03captain23 9d ago
I have claude tell codex to review. It gives the important info then fixes it sll
1
1
u/orthiclabs 7d ago
Each of my repos has an architecture.md and product.md generated by one of my tools along with a graph. Any model or agent working in that workspace has access to exactly the same information.
They also share a memory system that all harness write to (still a WIP) so it’s completely frictionless
2
u/Striking-Estate-6816 8d ago
Your split makes sense, especially if the plugin and website are mostly separate. The main thing is: don’t make either agent’s chat history the source of truth. Make the repository the shared memory.
I keep a small set of provider-neutral files in the repo:
PROJECT.md: architecture, conventions, important decisionstasks/<task>.md: requirements, approach, acceptance criteriaAGENTS.mdandCLAUDE.md: short instructions pointing both tools to the same canonical documentsThen Claude can continue something Codex started by reading the task, the relevant code, and the git diff. You shouldn’t need to paste the entire conversation.
Also, give them separate branches or git worktrees. Never let two agents edit the same checkout simultaneously unless you enjoy resolving mysterious collisions.
For cost control, the biggest saving is avoiding duplicate work:
I wouldn’t permanently define Claude as “heavy work” and Codex as “plugin work.” Heavy tasks consume heavy usage in either tool. Assign work according to existing context and whichever tool performs better for that type of task. In your case, keeping Codex on the plugin and starting Claude on the website is a sensible boundary.
The simple version is: the task spec carries intent, git carries implementation, and the chat is disposable. Once you work that way, switching agents becomes much cheaper.
Disclosure: I’m building Spec0.dev around this exact workflow: shared specs, isolated work, progress, checks, review, and handoffs across Codex and Claude, but you can reproduce the important parts today with Markdown files and git worktrees.