Your coding agent hits its usage limit halfway through a task. Wait or switch?

Most coding agent plans have a usage limit, and it has a way of running out in the middle of something rather than between tasks.

You have roughly three options. Wait until it resets. Pay for more. Or hand the rest to a different agent.

Waiting keeps everything the agent had worked out, but it might cost you hours. Switching gets you moving right away, but the second agent starts cold: it sees the repo and your prompt, and the first agent's partial work only if you pass it along.

In Styx, the app I'm building, I made the choice visible instead of burying it: when a plan is out, it shows when the limit resets, or sends the same ask to another agent.

So, when your plan runs out mid-task, what do you do? And if you switch agents, does the second one start from your original prompt, or from whatever the first one had done by then?

Comments

[Auten]

When you switch, does Styx hand the second agent the first one's diff, or just the original prompt plus the repo state? One thing that tends to help either way: have the first agent keep a short state file updated as it goes (done, next, what it was about to try), so the second one starts from that instead of cold. (From the Auten team, we build a computer-use MCP for coding agents.)

[Jackson Ly]

I wait. One night a usage limit stopped 30 of my agents mid-task from about 04:20 to 08:20, and after the reset each one resumed from its own transcript with no lost work. In a different run the limit cut off two subagents and they left half-finished files, which a resumed agent, or a second one switched in then, could easily take as intended. So before anything resumes I check what each agent last committed and what's lying around uncommitted.

[Reid Marlow]

Switching cold usually makes things worse because the new model re-reads the repo and undoes half the unfinished changes.The clean handoff pattern is capturing git diff plus the last successful tool result into a markdown scratchpad, then passing that explicitly as the starting context. If the new agent cannot see what broke or what was already verified, waiting out the rate limit reset is almost always faster than debugging a split-brain commit.

[Paul Irolla]

Every turn carries the history again, so the limit arrives sooner in a session that has grown. Trimming old tool output buys turns before the wait.