Blog
Claude Code says your session limit is reached. What to do with the next four hours
The annoying part is not the wait. It is that the wait usually costs you the twenty minutes of context the agent had just built up, and you pay for that twice.
When a coding agent hits its usage limit mid-task, the expensive loss is not the time, it is the state: the plan, the decisions and the half-finished reasoning live in a conversation that will be gone or compacted by the time your quota returns. Before you close anything, get that out of the conversation and into a file or a task list that is not owned by the agent. Then write the next prompt now, while you still remember what you wanted, and put it on a timer for the reset instead of coming back to a blank prompt in four hours.
Do this before you close the tab
The limit is temporary. The context is not, and it is the thing you actually lose.
An agent that has been working for twenty minutes holds a great deal that never got written down: which approach it settled on and why, the two things it already tried, what it was about to do next, the file it discovered was the real problem. All of that is in a conversation that is about to be compacted, closed, or simply forgotten by you.
- Ask it to write the plan and its current state to a file in the repository, in whatever detail it can manage. This costs one small request and saves the whole session.
- If you have any quota left at all, spend it on that rather than on one more edit.
- Note what you were going to ask next. In four hours you will remember the task and not the specific next step.
Then set up the restart, now
The common pattern is to come back later, open a fresh session, and spend the first ten minutes re-explaining the project. That is the cost being paid over and over, and it is avoidable.
Write the next prompt while it is fresh and leave it somewhere that will hand it over when the window reopens. If your setup can fire a prompt on a timer, set it for roughly when you expect the reset and go and do something else. If it cannot, write the prompt into a file so at least the first message of the next session is not typed from memory.
Point the new session at the notes the old one wrote, not at your recollection of them.
The structural fix: stop keeping the plan in the conversation
Everything above is a workaround for one design fact. The plan lives inside the agent's conversation, so anything that ends the conversation ends the plan. A usage limit is only the most predictable way that happens. Context compaction does it silently, closing a pane does it, quitting does it, and switching vendors does it permanently, because one vendor's memory is not readable by another.
The durable answer is that the plan should not be in the conversation at all. Keep the objective, the tasks, what is done and what is blocked in something the agent writes to and reads from, but does not own. Then a limit is a pause rather than a loss, and the next session, from any vendor, starts by reading rather than by being told.
The free version of this is a markdown file in the repository that every agent is instructed to update. It is unglamorous and it works. The tooled version is a task board outside any conversation, which Forkbench includes free on every plan, for the same reason the file works: it belongs to the job rather than to the agent.
How this works in Forkbench
Each Thread carries a board the agents write to as they go: tasks, progress notes, blockers. It is on disk as it changes, so a compaction, a closed pane, a quit or a reboot leaves it where it was, and the next session reads it instead of asking you. You can also hand a pane a prompt on a countdown, so the next instruction lands at the time you choose rather than when you happen to sit back down, and Sleep Control keeps the Mac awake with the lid shut so a long run finishes overnight.
Both of those are free, on every plan, and it is worth being straight about why. They are not what Forkbench is for. It is a Mac app for running coding agents where the keys they need are used by the command and never handed to the agent, and where a Thread can be locked to its folders by the macOS kernel. The board and the notes are the convenient part that comes with it, because agents working one job need somewhere to keep out of each other's way. If a durable plan is genuinely all you want, a markdown file in the repository gets you most of it for nothing.
Two limits, stated plainly: Forkbench does not detect rate limits and cannot read your remaining quota, so the time on that countdown is yours to choose. And if the Mac slept past the deadline, it holds and asks rather than firing a stale command at a session that has moved on.
Related: Schedule a prompt for when your quota resets
Frequently asked
What should I do when Claude Code says the session limit is reached?
Spend your last request, if you have one, getting the plan out of the conversation and into a file. That is the part you cannot get back, because the limit expires and the context does not. Then write the next prompt while you still remember what you wanted and schedule it for the reset, so you are not typing it from memory hours later. Everything else is waiting.
Does the plan survive a context compaction?
Not reliably, and that is the same failure as a usage limit arriving early. Compaction summarises the conversation and decides what to keep, and the detail it drops is exactly the specific reasoning you would want tomorrow. Anything you need to survive should be written outside the conversation, in a file or a task list the agent updates as it works.
Can I make the next prompt run automatically when the limit resets?
Yes, if your setup can hand a pane a prompt on a countdown, which is what Forkbench's scheduled runs do. You choose the time, because nothing here reads your remaining quota or detects a rate limit. If the machine slept past the deadline, the sensible behaviour is to hold and ask rather than fire a stale command into a session that has moved on.
Will a new session remember what the last one was doing?
Only if the last one wrote it down somewhere the new one can read. A conversation is per session and per vendor, so a new Claude Code session starts cold and a Codex session cannot read Claude Code's memory at all. A plan kept in a file or on a task board outside the conversation is readable by whichever agent opens next.
Does running several agents make the limit come faster?
Several agents on the same account share that account's usage, so yes, in the sense that you spend it faster. What changes the economics is running agents from different vendors on their own subscriptions, which is possible when nothing about your setup assumes one vendor, and keeping the plan somewhere all of them can read so a limit on one does not stop the work.