Recovery after a failed, stuck or uncertain run

Three things can go wrong, and they need different reactions:

• the task failed (the provider refused, or the request errored);
• the task is stuck (no output, and you want it to stop);
• the task is uncertain (the service does not know whether it was billed).

Only the third one blocks you, and it blocks you on purpose.

🧭 First: look, do not re-run

Re-running blindly is the most expensive mistake in this system, because a second run is a second task with a second budget.

dsh status            # last task: state, spend, held amount
dsh tasks             # recent tasks
dsh task TASK_ID      # one task in detail
dsh sessions          # saved conversations

In the browser, the Usage tab shows the same information per task: provider, model, tokens, limit, spend, state.

🔹 Failed task

A failed attempt ends the task. There is no automatic paid retry — the client does not silently send the same request again.

What to do:

1. Read the error class. An authentication or balance refusal happens before generation and costs 0. A timeout or server error may not be free.
2. Fix the cause (scope too large, route unavailable, account limit reached).
3. Decide whether to run a new task, with a smaller scope.

Do not paste the same prompt five times hoping for a different answer: five failures cost five times as much and teach you nothing.

🔹 Stuck task

dsh stop TASK_ID

Stopping ends the task and keeps the attempt in the ledger — the row stays, because money may already have moved. In the editor, Ctrl+C during a task does the same thing; Ctrl+C at the prompt just exits the chat.

🔹 Uncertain task

This is the state where the service cannot prove whether the call was billed. Behaviour you should expect:

• the task stays uncertain; it is not rewritten as zero;
• further paid turns are blocked until it is resolved;
• dsh reconcile SESSION_ID inspects the uncertain task or grant and recovers it using the saved idempotency key — it never resends inference;
• dsh reconcile SESSION_ID --cancel additionally requests cancellation.

The rule behind this is simple: an unknown spend is not a zero spend. Resolving it is a deliberate action, not a timeout.

➡️ Resuming work

A conversation can continue without re-sending history:

dsh sessions
dsh resume SESSION_ID

Resuming keeps the context; it does not refund or reopen a finished task. Each new question is still a new task with its own cap.

🔹 If you run several lanes

• A lane that fails does not invalidate the others — collect the finished outputs first.
• Stop a lane by its own id; never kill the whole process group if other lanes share it.
• Keep every lane's output and receipt, including the failed ones: the receipts are how you explain the cost.

🚧 When this does NOT work

• You want the client to retry automatically. It will not. That is a design decision, not a missing feature.
• You expect a timeout to be free. It may be billed; the state stays uncertain until reconciled.
• You want to reconcile without knowing the task id. Find it in dsh tasks or the Usage tab first.
• The service itself is down. Then receipts stop appearing; do not keep firing tasks — wait for a terminal state.

➡️ Next

• Costs, budgets and limits — why uncertain blocks the account.
• Splitting work across agents — isolating a failing lane.
• Models and routing — reading the receipt.