Workflow
Switch agents, not apps.
A coding agent can run out of allowance in the middle of a task. Your repository has not run out of anything. Keep the work where it is, open the other agent, and carry on in the same terminal.
It usually happens after the useful part has begun. The agent has read the repository, found the failing path and changed two files. Then the terminal stops with a sentence that has nothing to do with the code: you have reached a usage or spend limit.
One real Claude Code message is blunt: You've hit your individual spend limit · run /usage-credits to ask your admin for a higher limit. Codex has its own limit notices and account-specific options. The wording differs; the interruption is the same. A vendor boundary has appeared in the middle of your working tree.
First: which limit did you hit?
People call all of these a “token limit,” but that phrase collapses three different problems. A conversation can fill its context, a plan can exhaust an allowance, or an account can reach a credit or spend cap. The next action depends on which one the product actually reports.
Context or length
One conversation has reached the amount of material the model can actively carry.
What to do: Compact or summarize if supported, or start a fresh session with a focused handoff.
Usage allowance
Your plan has used its allowance for the product's current time window.
What to do: Check the displayed reset and the upgrade or credit choices offered to your account.
Spend or credit cap
Paid continuation has reached a personal, workspace or organization budget boundary.
What to do: Add funds, change the cap, ask an administrator, wait—or move the task to another agent.
Read the notice in front of you. Check the vendor's usage page for the reset, credit or administrator options available to that account. Limits and remedies vary by plan and can change; a blog post should not pretend otherwise. But paying, waiting or asking an administrator are not the only ways to keep the engineering task moving.
The subscription stopped. The repository did not.
The obvious fallback has an app-shaped cost
On a phone, the obvious fallback is to leave the Claude app and open ChatGPT for Codex, or leave ChatGPT and open Claude. That works, in the narrow sense that another agent is available. It also replaces the whole cockpit at the exact moment you need continuity.
Navigation moves. Approval controls look different. Session history is organized differently. One app may expose a workflow the other does not, and neither is a general SSH terminal with your usual tmux sessions, SFTP browser and tunnels beside the agent. You spend the first minutes learning where the new app put the controls instead of learning what the previous agent changed.
Make the terminal the stable layer
Run Claude Code and Codex where the work already lives: on the same machine, reached through the same SSH client. In Mobile SSH, changing vendors can be as small as opening another tmux pane and running the other command. The phone interface stays familiar because it is the interface to your server, not to one model vendor.
| Working state | Carries over? |
|---|---|
| Repository files and uncommitted editsOn the same disk | ✓ Yes |
| Git status, diff and test outputInspectable by either CLI | ✓ Yes |
| SSH host, shell and working directoryThe same session | ✓ Yes |
| tmux, SFTP, tunnels and Agent AlertsThe same mobile tools | ✓ Yes |
| The other vendor's conversation historyNeeds a fresh handoff | — No |
This is the useful kind of portability. The next agent can inspect the files, diffs, test output and project instructions left on disk. Mobile SSH still knows the connection. The tmux manager still knows the session. SFTP and port forwards are still where you left them. Agent Alerts work for either agent because the hook reports terminal state rather than pledging allegiance to one vendor.
Vendor-neutral does not mean context magically transfers. It means the evidence survives the switch.
The honest handoff
Claude's conversation does not become Codex's conversation, and the reverse is not true either. Do not tell the replacement agent “continue” and hope it can see a chat owned by another service. Give it the durable state: repository rules, the working-tree diff, commands already run, and the result you still need.
A four-step handoff
- Freeze the evidence
Do not clean or overwrite the tree. Capture
git status --shortand inspectgit diff --stat. - Read the local rules
Have the new agent read
AGENTS.mdand the relevant project documentation before it edits. - Re-establish the baseline
Run the smallest relevant test or check and record what passes, fails or was never tried.
- Continue in a new pane
Start the other CLI beside the old pane, give it the goal and constraints, and ask it to inspect the existing diff first.
Read AGENTS.md, git status and the current diff. Preserve the existing work. Run the focused tests, explain what remains, then continue the task. If the first agent stopped before it could write a summary, the diff is the summary of record. Ask the replacement to inspect before editing. That protects partial work, catches assumptions embedded in the patch, and gives you a clean point to decide whether to continue, revise or revert.
One interface for whichever agent is useful today
This is not an argument that Codex and Claude Code are interchangeable. They have different strengths, models, tools, limits and account rules. That is precisely why the interface should not force a permanent choice. Pick the agent that fits the task, the allowance you have and the policies of the repository.
A native vendor app is often the quickest zero-setup route to that vendor's cloud agent. Keep it when that is what you need. But when the work is on a machine you control, a general terminal gives you a more durable home: one app to reach the server, any agent installed there, and the rest of the SSH toolbox when the job stops being an agent prompt and becomes ordinary engineering again.
Choose the agent on its merits. Keep the workspace on yours.