Claude Code usage limit: what happens to the run, and how to pick it back up
A turn that dies on your Claude Code usage limit normally waits for a human to come back and send it again. What the limit does to a running session, and how TermLink resends the stopped turn a minute after the limit resets.
The limit never lands while you are watching.
It lands twenty minutes after you walked away from a long refactor, or at two in the morning on the machine that exists only to run agents. You come back to a session that stopped mid-task, and the work between "it started" and "it quit" is still there — but the turn that was running is not. You send it again, and wait again.
What a usage limit actually does to a session
Claude Code's limits are usage windows on your plan, and when you reach one, the turn in flight ends. It does not pause. It does not queue. It ends the way any other failed turn ends.
If you are sitting in the interactive CLI, Claude Code can restart itself when the window resets. That behaviour belongs to the interactive CLI specifically — and it only helps if the thing that resumes is the thing you were using.
Anything driving Claude Code programmatically goes through the Agent SDK's query() instead, which is what a session manager uses to run your agent inside a session it can relay. query() has no restart-at-reset of its own. A turn that hits the limit there simply ends, failed, like any other error.
So the gap is not "Claude Code has no answer for limits". The gap is: the answer is in the place you are not.
What TermLink does instead
TermLink's host supplies the missing behaviour for Claude sessions. When a turn fails on a genuine usage-limit hit:
- It works out when your limit actually resets.
- It waits.
- A minute past the reset, it sends the same turn again — by itself.
You do not have to be at the keyboard, and you do not have to retype anything. While it waits, the session carries a live countdown to the retry.
The waiting is real session state, not a notification that flies past. If the limit hit at 2am and you open TermLink on your phone at 8am, the session still shows that it is waiting and when it will go. It survives you being disconnected the whole time, because it was never a message — it is what that session is until the retry fires.
Telling a real limit from everything else
Retrying on the wrong thing would be worse than not retrying. A turn can fail because the service was overloaded, because a request was malformed, or because you pressed Stop — none of those should silently re-run.
The host treats a failure as a usage-limit hit only when Claude Code says so: either the API error code attached to the turn is literally rate_limit, or the failure text starts with one of Claude Code's own "you have actually reached the limit" prefixes, re-exported by the SDK itself.
Notably that excludes the warnings that sit next to them — "approaching your limit", "now using credits". Those are informational, never a hard stop, and a session that restarted itself on a warning would be restarting on nothing.
Where the reset time comes from
Two sources, in order of how much they can be trusted:
- The SDK's own rate-limit event, when one has arrived: a structured frame with a status of rejected and an exact reset timestamp. This is the real answer.
- Claude Code's own sentence, as a fallback:
... resets 7:30pm (Asia/Seoul). It carries a clock and a zone but no date, so the host resolves it to the next time that clock occurs in that zone.
Whatever zone Claude Code names is the zone that gets used — America/New_York, Europe/London, Pacific/Auckland, plain UTC. The host does not assume the machine's own clock, which matters precisely because the machine running your agent is often not in the same place you are.
If neither is available, nothing is scheduled and the turn simply stays failed — exactly as it did before any of this existed. A guessed retry is worse than no retry, because it burns a turn and teaches you not to trust the feature.
Why a minute after, not exactly at it
A reset is a server-side event, and arriving at the same instant is a good way to be told no a second time. One minute is long enough that the reset has genuinely landed and short enough that nobody waiting notices the gap.
The edges, stated plainly
This is a convenience, not a way around your plan:
- Claude only, for now. Codex CLI, Cursor Agent and Copilot CLI sessions do not have it.
- Resent once, not retried forever. A run of repeated limit hits stops retrying after a few tries rather than looping.
- The wait does not survive restarting the host. TermLink never stores conversation text, so after a restart there is no turn left to resend. The session comes back without the armed wait, and sending to it again works normally.
- Typing cancels it. Any message you send clears the wait and goes immediately — if you came back early, you are not stuck behind a countdown.
- It does not raise your limit. It removes the part where a human has to notice the limit expired.
What this is worth in practice
The value is not the retry itself — it is a few seconds of work. The value is that the gap between "the limit reset" and "somebody noticed" goes to zero.
That gap is usually hours. A limit that resets at 3am gets picked up when you sit down at 9am, and a long task you expected to find finished is instead sitting where it stopped six hours ago. With the retry armed, that task finished at 3:01am and the result was waiting for you.
It compounds when you run several agents. Checking "did any of these die on a limit overnight?" across four machines is exactly the kind of chore that does not get done, and the answer arrives as lost hours rather than an error you can see.
Frequently asked questions
Does TermLink increase my Claude Code usage limit?
No. The limit is between you and your Claude plan, and nothing here changes it. What changes is what happens at the moment it resets: the turn that stopped is sent again automatically instead of waiting for you to notice.
What happens to a Claude Code session when the usage limit is reached?
The turn that was running ends as a failure — it does not pause or queue. Everything the agent already did stays in the session. In TermLink the session then shows that a retry is armed, with a countdown to it, instead of just looking failed.
Will it retry on its own if I am not connected?
Yes. The retry is scheduled on the host, on your own machine, so it does not need a browser open or a phone awake. When you do reconnect, you see either the countdown or the result.
Does this work with Codex, Cursor or Copilot?
Not today. The behaviour is implemented for Claude sessions only, because it depends on signals Claude Code itself emits about a reached limit and its reset time.
How does it know the limit reset, instead of guessing?
It reads the reset time from Claude Code — preferably the structured rate-limit event the SDK sends, otherwise the reset clock in Claude Code's own message. If neither gives a usable time, it does not schedule anything and the turn stays failed rather than retrying blind.
Can I cancel the wait?
Yes. Type into the session and it sends straight away, cancelling the scheduled retry. You can also stop the session as usual.
This is part of what keeps a session useful when nobody is watching it: see a session manager for AI coding agents for the rest, automatic approvals for the other half of unattended runs, and running multiple Claude Code agents at once for what this looks like across several machines.
TermLink keeps your agent running on your own machine and gives you the terminal from anywhere. Register a machine and open its session from any browser. Free plan, no card.