Session token limits repeatedly kill in-flight subagents mid-task; resume UX is manual and lossy
Feedback: session limits are disruptive to long-running agentic work
Filed on behalf of the user from an interactive session.
Today, during a single milestone implementation session (a 22-task plan executed via subagent dispatches), the session token limit terminated in-flight subagents twice:
- ~16:08 PT: an implementer agent was killed mid-implementation ("resets 4:30pm") — partway through wiring a module, with uncommitted work in the tree.
- ~21:10 PT: the final milestone-closure agent was killed the same way ("resets 9:30pm") — mid-way through multi-file documentation edits.
Both times the recovery path was: wait for the reset, then manually re-message the dead agent to resume, and have it re-derive its own on-disk state (git status/diff) to avoid duplicating half-applied edits. It worked, but only because the orchestrating session knew to do this; the failure mode risks half-applied multi-file edits in a workflow whose whole design is TDD + atomic per-task commits.
What would help, in rough priority order:
- Graceful wind-down instead of hard kill: when the limit is imminent, let the agent receive a signal so it can commit/checkpoint and report state, rather than dying between tool calls.
- Automatic resume on reset: an opted-in "resume terminated agents when the window resets" behavior, rather than manual re-messaging.
- Budget visibility before dispatch: expose remaining-window headroom so an orchestrator can decide not to launch a 10-minute agent into a 2-minute window.
- Limits pacing that accounts for agentic sessions: a burst of subagent work hits limits very differently than interactive chat, and the current UX treats both the same.
The user's summary: these limits are irritating and problematic for exactly the long-running, multi-agent workflows Claude Code is otherwise excellent at.