When Claude Runs Out of Fuel, Hand the Work to Codex: How AI-to-AI Handoffs Kept My Development Moving

Lately, Claude has been running out of fuel more often.

The reason is clear.

I started using Fable.

The previous Opus model was already highly capable, but Fable makes me want to give it increasingly difficult design and implementation work. I often ask it to handle design, reviews, and research together.

The problem is that Fable consumes far more tokens, so I burn through my usage allowance much faster.

Anyone who uses Claude Code through a subscription will know that you can check your remaining allowance with a command, much like glancing at a fuel gauge.

I did not pay much attention to it before. These days, however, it is not unusual to find that I have entered the danger zone without noticing.

The real problem is when Claude runs out of fuel.

“Another 30 minutes and this feature would be finished.”

That is exactly when I seem to hit the usage limit.

A person can take a coffee break and get back to work. Claude cannot. I have to wait several hours for the allowance to reset.

That was too inefficient to repeat every time, so I changed my approach.

When Claude stops, I simply hand the work over to Codex.

The Problem Was Context, Not Capability

Not long ago, this approach would not have been very practical.

Even if I handed the task to Codex midway through, explaining everything that had happened before the handoff was a major job in itself.

But the latest generation of Codex, at the GPT-5.6 level, has become remarkably capable.

For the development work I normally do, it can continue at a level comparable to Opus 4.8 as long as I provide the right context.

In other words, capability was not the problem.

The only real question was how to transfer what the previous AI had been thinking.

Generate a Handoff Document Automatically at Commit Time

The system I use is surprisingly simple.

On the Claude side, I have added a skill that automatically generates a Markdown handoff document whenever I commit.

It records information such as:

• How far the work progressed
• Important context Claude was holding
• The reasoning behind design decisions
• Tasks that still remain
• Points Codex needs to know

It is less a document for a human reader than a handoff note for the next AI that will work on the project.

Codex Only Needs to Read It at Startup

On the Codex side, I put an instruction like this in AGENTS.md:

When you start, always read "******" first.

Use this file to understand the previous work state and context,
then wait for the user's next instruction.

That is enough for Codex to load the handoff document when it starts and begin from the position of:

“This is where the previous session stopped, and this is what I should do next.”

I no longer have to explain everything from scratch each time.

There Are Tradeoffs

Of course, the system has drawbacks.

The first is speed.

Generating the handoff document with every commit adds a small delay. It is only about ten seconds, however, so it does not bother me much.

The second issue is more important.

This system runs when I commit.

If Claude runs out of fuel before I commit, the handoff document will not include the latest work.

That is why I keep an eye on the fuel gauge. When I think, “This is getting dangerous,” I either make a commit or manually generate only the handoff document.

The third drawback is that switching models may also mean a small drop in reasoning quality.

For my usual development work, GPT-5.6 can continue without a noticeable loss of capability. But when I hand over a difficult design or implementation task that Fable was working on, the depth of reasoning or precision of judgment may decline slightly.

For that reason, I often leave Fable’s most recent task where it is and wait for the usage limit to reset instead of forcing an immediate handoff to another AI.

That does not mean I sit idle.

While I wait, I use Codex to work on a different feature, investigate another issue, or handle separate fixes.

The goal is not to force two AIs to run the same relay. By shifting work to other tasks when necessary, I can keep development as a whole moving.

The Fastest Way to Build It Is to Ask Claude

You may be wondering how to create this system.

For this kind of setup, it is faster to ask Claude itself than to search the web and build everything manually.

For example, you can ask:

I want a system that synchronizes and hands off work information to Codex
in case Claude stops unexpectedly. Create a skill that outputs a Markdown
handoff document whenever I commit.

Then follow up with:

Also create an instruction prompt for setting up this handoff system on
the Codex side. I want to paste it into the Codex console.

Claude can then propose a setup tailored to your project structure.

The Era of AI-to-AI Handoffs

Handoff documents used to be written for people.

When responsibility passed to someone else, you left notes saying, “Be careful with this part.”

Things are now a little different.

The next reader of the handoff document may be an AI.

When Claude runs out of fuel, hand the work to Codex.

Continue in Codex, then return to Claude once its allowance resets.

That kind of relay now works in ordinary development.

Only a few years ago, the idea of one AI writing a handoff document for another would have sounded like science fiction.

We are moving from an era in which developers use AI to one in which they coordinate multiple AIs.

Within a single AI platform, agents can already make this possible. Between different AI systems, the process is still rough around the edges.

Even so, I suspect that a year from now I will reread this post and wonder:

“Why was I doing this in such a primitive way?”