Skip to main content
When a human-requested task reaches a run limit, Mesh saves its context and asks whether to continue. The original requester can reply in the same thread without mentioning the agent again. This is available when the durable database is configured; no per-agent switch is needed.

What happens at the limit

The default work allowance is 60 model calls with a separate 30-minute wall-clock backstop; operators can change those limits. The closing completion removes tools and either delivers the finished result or explains what is done, what is saved, and what remains. A hard deadline can use a saved-context fallback. Explicit cancellation does not automatically ask to restart the task. A pause ends the current run. Its consumed budget is not reset. Continuing starts another bounded run with the saved task context and the requester’s new message. Commitment attempts have separate authorization and cannot treat their own notices as human consent.

Replying to the pause

Silence, a timer, a bot message, or a different participant cannot authorize continuation. Source and audience checks bind the decision to the original requester, agent, conversation, and message. An atomic transition allows one child run to consume a pause. Every later exhausted allowance asks again. The ambiguous path is conversational judgment, not a deterministic proof that the person approved more work. Its instructions preserve the original scope and require the model to resolve uncertainty before continuing that work.

What survives

The checkpoint includes the objective, summary, admitted background, working model/tool transcript, requester corrections, and source lineage. Restoration regenerates current system policy and tool authority. Saved system/developer instructions and raw image bytes are not replayed. Whole historical records are selected under the ordinary prompt budget; the objective, progress summary, and latest reply remain required context. Completed declared external effects reuse their recorded results. An interrupted operation without a recorded outcome is marked unknown, never assumed to have failed. Shell and browser writes require inspecting actual state before retrying.

Workspace retention

The default and maximum continuation hold is 14 days. An idle-persistent backend can retain a ready workspace during that window, which may incur idle cost. A snapshot-only backend restores from its available checkpoint instead of inheriting an expired sandbox reference. Neither mode guarantees every file survives: the resumed run must inspect the workspace and report missing state. Accepting continuation transfers an eligible workspace atomically; credentials are resolved again. Decline or expiration makes retained work eligible for cleanup. An unrelated question does not dismiss the paused task or its hold. Backend changes fail safely rather than reusing an incompatible workspace. The pause is saved before sending, and becomes eligible for consent only after the delivered question is recorded. A failed or uncertain send is not an approved continuation. Restart recovery handles a process exit within a run; it is a different mechanism from renewing a finished run’s allowance. Implementation: internal/continuation (repository) and internal/turn/continuation.go (repository).