What do you do when the agent hits its rate limit mid-feature?
by•
Half a feature in, agent taps out on usage, and now you're staring at code you didn't fully read yourself. Do you wait for the reset, switch to a different model, or just finish it by hand? Curious how people handle getting cut off mid-flow, not at a clean stopping point.
187 views
Replies
hello @bickov I usually avoid switching models immediately. First I review the current diff, run the tests, make a small WIP commit, and leave a short handoff note with what’s finished, the decisions already made, what’s broken, and the next step.
Then I can either resume after the reset or give that handoff to another agent without asking it to reverse-engineer the feature from half-written code. Rate limits are still annoying, but small checkpoints make them much less destructive.
SlimSnap
@alpertayfurr The handoff note is basically doing by hand what @abdullah_javaid3 describes below with a memory folder, worth combining the two. Write the note the way you already do, but drop it into a file the next session reads on start instead of carrying it in your head or a chat scrollback. Doesn't remove the diff-reading step either way, that part stays on you regardless of where the note lives.
@alpertayfurr @bickov
That combination is the right move. Here is the gap I would flag. A handoff note gets written right at the moment you are about to stop, so it is fresh by construction. A memory file only helps if something wrote to it recently, and the moment you are most likely to skip an update is the one right before getting cut off mid thought.
Worth stealing Alper's habit: force a write to the file at the same trigger, a WIP commit or a stopping point, instead of updating it whenever it happens to occur to you.
@abdullah_javaid3 Exactly, the trigger is the important part. Tying the memory update to every WIP commit or planned stopping point is much safer than relying on remembering to update it manually. Ideally, that checkpoint should become part of the agent’s normal completion routine.
@abdullah_javaid3 @bickov That makes sense. I’ll probably combine them by keeping the handoff in a small repo-level memory file that every new session reads first. The diff still needs a human check, but at least the next agent won’t start without the reasoning behind it.
@bickov @alpertayfurr Careful with keeping the reasoning though. Rabnoor's point above is why my index entries cap at one line, reasoning does not fit and that is the part worth losing. Reasoning is the forty thousand tokens including whatever early guess got corrected later. Keep the decision, not the argument that produced it, or the next agent inherits the same false starts.
SlimSnap
@alpertayfurr @abdullah_javaid3 The real gap left standing is the decision that was still being formed when the cut happened, nothing gets written for it because it was never finished into a decision yet. No trigger catches that one, WIP commit or otherwise, the discipline only fires after you have already landed somewhere. @rabnoor_s 's framing, keep decisions and drop the reasoning, holds up fine for everything before that point, just not for the thing still being worked out in the moment.
the real problem in that sentence isnt the rate limit. its 'code you didnt fully read yourself.' the rate limit was probably a gift because it forced you to stop before shipping something you couldnt actually own. my move is: before restarting the agent, read the last diff it produced end to end. if you cant explain each block to a reviewer, delete it and rebuild the feature slower. rate limits are the only mechanism that reliably catches the 'ill just trust it and keep going' pattern. worth using them as the checkpoint instead of routing around them.
SlimSnap
@thenameisarian Rate limit as forced checkpoint, not a delay, that's basically what I've landed on too. Read the diff before touching it again, and if I can't explain a block out loud I don't build on top of it. Still haven't figured out how to catch that without needing the limit to force it.
Just wait and tell it "go on" when limits lifted :)
Also, run ClaudeCode and Codex, both in CLI, in parallel - and integrate them. So ClaudeCode is your main developer, and Codex is an external reviever/adviser. They can communicate directly even without a plugin, and it saves tons of tokens, aside from other benefits
Dial
I stopped switching models mid-feature after doing it a few times. the second model doesn't know the decisions the first one already made, it just sees the code, so you either get something inconsistent or you spend the reset explaining context you already burned tokens explaining once. these days I use the wait to do the boring stuff, read the diff properly, write the test I was going to skip, or just think about the next step instead of coding blind. the rate limit is annoying but it's rarely the thing that actually cost me time.
The memory-file thread buried in here is the real answer, not the rate limit workaround. Once decisions live outside the model's context window, which agent picks the work back up stops mattering nearly as much.
@irahimiam yeah, and it's not only agent swapping. it also covers resuming three days later after switching to a different task entirely. same file, same decisions, no reconstructing what already got decided.
Worth asking why the handoff note works at all, given the agent had far more information available to it than the note contains. It works because it is lossy in the right direction. It keeps decisions and throws away the reasoning that produced them. The agent's own context is the exact opposite. It keeps everything, including the intermediate reasoning that was wrong and got corrected three steps later, and restoring that restores the confusion along with it. Which means the thing you want persisted is decisions, not context. Those are two different objects and this thread keeps treating them as one. A decision is "we went with X over Z because Y". Context is the forty thousand tokens of finding that out. Mustafa's checkpoint framing is right and I would push it further. Writing decisions down as you go beats having the full transcript, whether or not anything ever cuts you off. The rate limit is not creating that discipline. It is just currently the only thing forcing it.
@rabnoor_s Rabnoor's distinction is the one I didn't have language for. What forced it for me in practice: my index file caps each entry at about one line, so the reasoning simply does not fit in the format. Only the decision survives. Turns out the length limit was doing the filtering the whole time, not any discipline on my part.
@abdullah_javaid3 The length limit doing the filtering is the most portable thing in this thread. A format where the wrong thing physically does not fit beats any rule you have to remember, because the rule fails exactly when you are busy, which is the same moment the decision is being made. Has the one line cap ever cost you something you actually needed later, or does the dropped part turn out to be reconstructible every time? That is the bit I cannot tell from my own notes, since I only notice the ones that worked.
@rabnoor_s Mostly reconstructible. The one time it wasn't: a note said a batch of pages weren't done yet, and by the time anyone acted on it most already were, it just carried the verdict and not the date it was true as of. Now anything like that gets a timestamp attached, not just a conclusion.
@abdullah_javaid3 "It carried the verdict and not the date it was true as of" is the best sentence anyone has given me this week, and it generalises past notes. Almost every stale-context bug I have hit is that shape: the conclusion survived and the as-of stamp did not, so a claim that was true on Tuesday keeps getting read as true today with no way to tell. Timestamping the conclusion is the whole fix and it costs one field. Disclosure since it is the same argument: I hunted Atuin today, which does this for shell history, keeping when and where and whether it worked alongside the command instead of just the command. Not asking you for anything, and if you think a timestamp is insufficient and it really needs an expiry rather than a date, I would rather hear that, because I am not sure a date alone makes anyone re-check.
SlimSnap
@rabnoor_s The distinction holds up because it is basically a compression problem. At write time nobody knows yet which early guess is about to get corrected, so there is no cheap way to filter reasoning down to decisions automatically, someone has to do that filtering by hand, in the moment. Which is the same discipline problem the rate limit accidentally enforces, it forces the human to do the filtering right when a decision lands instead of trusting they will reconstruct it later from the transcript.
The wait was never the expensive part for me. The expensive part was that the reset wiped every decision the agent had already made.
What fixed it was keeping those decisions outside the model. I run a folder of markdown memory files with a small index loaded at the start of each session. Decisions get written there as they happen, so the session after the reset starts from the file instead of from whatever survived in context. Gal's point about a second model not knowing the first one's choices stops applying once the choices live somewhere any model can read.
It does nothing for the half read diff. That part I still have to read like everyone here says.
The decision vs reasoning split matches something I do without ever having a name for it. Before I stop for the day I write one line per thing I changed and why, not what, git already has that part. What breaks it is exactly what got said upthread, the decision that's still half-formed when the cut happens never gets written, because it wasn't actually a decision yet, it was still an argument with myself. Don't have a fix for that half either.
@raffay_sajjad That's Rabnoor's third record type showing up in practice. Not a decision, not reasoning, an unresolved argument. If it's still open when you get cut off, "unresolved: X" is one line and survives, which beats losing it entirely.