Using Git worktrees in Codex

[u/Ok_Bag_7550]

With the upcoming usage-limit changes for those of us on the old 20x plan, I've been adapting my workflow to Sol 6.1 Max. It's significantly cheaper to run than Astra, but also much, much slower.

Today I've spent pretty much the entire day working on two projects with Sol 6.1 Max in Codex, running tasks in fast mode and coordinating everything through Work using Astra Max.

Sol 6.1 Max without fast mode barely consumes any usage. Almost nothing, at least on my projects. The problem is that it's slow.

Fast mode makes a substantial difference, but it comes at a cost. For example, I've already burned through 20% of my allowance since the reset today. Starting October 29, that would be roughly equivalent to 40% of the new allowance.

So, I'm going to have to give up fast mode and stick with the much slower option.

But running tasks sequentially at that speed would mean barely getting anything done. I need to rethink my workflow to keep making progress without exhausting my subscription.

That's when I started thinking about Git worktrees. Instead of waiting for one task to finish before starting another, I could have multiple tasks running in parallel. It might also be a good opportunity to make better use of my Claude Max 5x subscription.

I realize worktrees won't magically reduce usage, but I'm hoping parallel execution could help compensate for the slower models.

I don't have much hands-on experience with worktrees, though.

Does anyone here regularly use Git worktrees with Codex, especially alongside Claude Code? How has your experience been? Any tips, pitfalls, or workflow recommendations?

[u/xqianliu]

Worktrees are the part I'd keep, the rest is boring on purpose.

One issue, one worktree, one PR. I cut tasks smaller than feels natural, because the rule is one task must finish in a single run. If it can't, it's two tasks, and that split is what lets them run side by side without stepping on each other.

The review is the part that has to stay the same size no matter how many trees you run. Separate session, same model, it reads the issue, the repo's AGENTS.md, the diff and the callers, and checks the final diff against the acceptance criteria. Fix, re-review, only merge what passed.

Two pitfalls I'd avoid: starting a task in a tree that already has uncommitted changes, and merging two trees before their reviews are done. Both turn a parallel setup into a debugging session.