Problem
Alluka sessions retain conversation history, but an interrupted long-running task has no durable, user-addressable execution checkpoint. A user cannot see where a task stopped, distinguish an interrupted run from a completed run, or resume the task with its prior session context and selected model.
This is especially visible for automations, browser/tool-heavy tasks, provider failures, server restarts, and user-initiated cancellation. The current session status field is too broad to represent a specific run's lifecycle or recovery state.
Feature
Add durable task checkpoints for agent sessions.
A checkpoint represents the state of one task/run at a meaningful lifecycle boundary. It records the owning agent and session, selected model and thinking level, active conversation position, start time, terminal state, and a concise reason when the run does not complete normally.
Users can view prior checkpoints and explicitly resume eligible interrupted or failed work with an optional follow-up instruction. Completed checkpoints remain historical records and are not represented as resumable work.
Expected behavior
- Starting a task creates a checkpoint before model work begins.
- Checkpoints visibly transition through running, completed, interrupted, failed, and cancelled states.
- A process/server restart does not leave a task presented as still running.
- Resume preserves the task's intended conversation context and selected model when that provider supports continuation; unsupported continuations are represented honestly.
- Resuming an invalid, completed, unavailable, or concurrently active checkpoint returns a clear state-specific outcome.
- Checkpoint history remains local to the relevant agent/session and does not expose secrets or hidden provider credentials.
Why this matters
Alluka positions agents as durable local collaborators. Durable task state makes an interrupted task recoverable without asking users to reconstruct the goal, infer the last safe state, or start an unrelated new session.
Reference
Problem
Alluka sessions retain conversation history, but an interrupted long-running task has no durable, user-addressable execution checkpoint. A user cannot see where a task stopped, distinguish an interrupted run from a completed run, or resume the task with its prior session context and selected model.
This is especially visible for automations, browser/tool-heavy tasks, provider failures, server restarts, and user-initiated cancellation. The current session
statusfield is too broad to represent a specific run's lifecycle or recovery state.Feature
Add durable task checkpoints for agent sessions.
A checkpoint represents the state of one task/run at a meaningful lifecycle boundary. It records the owning agent and session, selected model and thinking level, active conversation position, start time, terminal state, and a concise reason when the run does not complete normally.
Users can view prior checkpoints and explicitly resume eligible interrupted or failed work with an optional follow-up instruction. Completed checkpoints remain historical records and are not represented as resumable work.
Expected behavior
Why this matters
Alluka positions agents as durable local collaborators. Durable task state makes an interrupted task recoverable without asking users to reconstruct the goal, infer the last safe state, or start an unrelated new session.
Reference