DEV Community

Cover image for Switch from Claude Code to Codex in the middle of a feature
Mykola Maksymenko
Mykola Maksymenko

Posted on Originally published at Medium AI-assisted

Switch from Claude Code to Codex in the middle of a feature

You are halfway through a feature when you start thinking about switching models. Perhaps your usage allowance is nearly gone. Perhaps the current model has tried the same approach three times, and you want another one to take a look. You already have another coding client installed. Opening it is easy. Explaining where the work stands is the part you would rather skip.

I work on my own projects in the evenings and on weekends, outside my main job. I use different models depending on how they are working for me and the limits I have left, so a model change can happen while a feature is still taking shape. I want the next session to pick up the work without making me reconstruct every decision between the two windows.

That is one reason I built ACC, an open-source coordination layer for independent AI coding sessions. I told the story of why in an earlier article. Each session stays in its own client, with its own model, conversation and permissions. ACC gives them a shared local place for questions, decisions and handoffs.

To switch models, leave a stopping point the next session can find, and do it while the current model can still respond. If a hard limit has already blocked it, ACC can still show what was saved earlier; it cannot make that model write a new handoff.

Leave the next session something useful

Take an account-registration feature. One session has implemented the endpoint. The screen is unfinished, and you have already agreed how duplicate email addresses should be handled. The next session can read the code, but you also want it to know which work remains and which checks have actually run.

Before switching, ask the current session:

Save a partial handoff in ACC for the registration feature. Include what is
implemented, our decisions and rejected approaches, what remains, and what
you actually verified. I will continue it in another session.
Enter fullscreen mode Exit fullscreen mode

A useful record looks something like this:

Completed: registration endpoint and validation tests.
Decision: duplicate email returns 409; the screen must explain that response.
Remaining: signup screen, endpoint integration, and complete-flow tests.
Verified: endpoint tests pass. The browser flow has not been checked.
Enter fullscreen mode Exit fullscreen mode

This is an illustrative example, not a transcript. Its value is the distinction between finished code, agreed behavior and unfinished work. The new model does not have to guess whether “registration is implemented” means the endpoint exists or the whole user flow works.

The handoff goes into ACC's local history, where a later session can discover it. Finishing the handoff closes the sender's ACC session; it does not close the coding client itself.

Continue in the client you choose

Open Codex normally in the same project and give it a bounded continuation request:

Continue the registration feature from its ACC handoff. Inspect the current
files and the recorded decisions. Finish the signup screen and integration
tests. Ask me about missing or conflicting requirements. Do not publish or
merge anything.
Enter fullscreen mode Exit fullscreen mode

The new session has its own conversation and permissions. It finds the saved handoff, checks it against the files and continues within the scope you gave it. It does not need to have been online when the previous session stopped: a session opened after the handoff was recorded can find it through history.

That check against the files matters. You may have edited something yourself, or another session may have changed a shared component. A handoff explains a stopping point. The current project tells the new model what it is working with now.

The first useful result is concrete: the new session names the agreed behavior, says what it is taking over and begins the next unfinished step. If it still needs a product decision, it should ask. You remain the person who decides what the feature should do.

Add it to the tools you already use

ACC requires macOS or Linux, Node.js 24 or newer, and supported coding clients on the same machine. Install it once:

npm install -g agents-can-communicate
acc install
Enter fullscreen mode Exit fullscreen mode

Follow the installer's activation instructions, review any hook or plugin trust your client asks for, then restart the clients from your project directory. The getting-started guide covers the client-specific steps. If a session cannot see its peers or use ACC, run acc doctor from the project.

You still open Claude Code and Codex yourself and use their normal interfaces. ACC needs no separate account, model API key or hosted service. Your clients keep using their existing provider access, and switching doesn't change either provider's limits. Both Anthropic's guidance for Claude Code on Pro and Max plans and OpenAI's pricing documentation describe the included usage and the ways to continue after reaching it.

A saved handoff does not need live delivery between sessions. The replacement session reads it when you ask it to continue. That makes this a good first ACC workflow to try before adding exchanges between sessions that run at the same time.

A Markdown handoff file can carry an occasional transition too. ACC becomes more useful when switching is part of an ongoing workflow: the same sessions also ask each other questions, record decisions and exchange review findings, and those records help the next participant understand what happened. Everything stays in local app data, and ACC never collects or shares raw session transcripts.

The easiest way to try this is to do it on one feature you are already building. Install ACC, ask the current session to leave a handoff, and continue one unfinished part in another supported client while both are still available. Then use the same habit when a limit approaches or you want a different model's approach.

What did the next model still need you to explain? That is the feedback I would most like to hear as I keep improving this open-source project. You can share it in the project's Discussions.

Top comments (0)