Cancellation and deadlines
Cancellation and deadlines for Q integrations.
Durable agent jobs use one deadline from acceptance, including queueing, retries and approval waits. Resuming a job does not extend it. Cancel with POST /v1/agents/{agent_id}/runs/{run_id}/cancel, using the existing authenticated client and an idempotency key. Read the run status to distinguish cancelled, expired and a completion that won the race. A successful cancellation acknowledgement records the decision; it does not promise that every remote service has stopped.
Provider calls, tool waves, subagents, research and sandbox commands inherit the remaining deadline. Cancellation blocks further dispatch, closes provider streams, drains child tasks and terminates owned sandbox process groups and named containers. Workers also observe the committed terminal state every 250 ms as a fallback to Temporal notification. Each cleanup wait has a two-second allowance; multiple resources can require more than one allowance. Normal cooperative cancellation is qualified separately from this upper allowance.
Synchronous answer generation stops when the original response consumer disconnects. Reconnecting with GET can replay retained events, including the interruption result; it does not restart generation. Only explicitly durable agent jobs continue after their observer disconnects. SDK observation timeouts stop that reader; use the job cancellation endpoint to stop a durable run. Legacy inline agent execution does not acquire durable-job guarantees.
Effects and usage
Cancelling cannot undo a committed write or establish that a remote provider stopped billing. The tool journal preserves completed local observations, including a result that arrives after cancellation. Unresolved intents remain unknown. New developer-hosted result submissions to terminal runs remain rejected; reconcile the external system using its invocation ID.
The authorised run status includes usage_json.execution:
{
"provider_attempts": 2,
"usage_complete": false,
"observed_input_tokens": 120,
"observed_output_tokens": 30,
"reported_cost_usd": 0.004,
"cost_complete": false,
"effects": {"completed": 1, "unknown": 0, "awaiting_external": 0},
"cleanup": {"complete": true, "reason": "run_cancelled"}
}Provider attempts are journalled before dispatch, with a maximum of 4,096 per run. These metadata-only observations supplement the existing billing ledger; they do not charge again. Reported partial usage and cost are lower bounds when their completeness flag is false. null cost means unavailable. An unobserved or interrupted provider call never implies zero cost. The status resource can acquire late observations after a terminal stream frame was recorded; fetch it again for the current audit view. cleanup: null means no worker cleanup acknowledgement; complete: false requires operator inspection. Cleanup completion concerns local resources, not remote billing settlement.
Rollout and limits
Deploy 20261008_020000_provider_observations before matching APIs/workers. The provider journal uses mandatory tenant RLS and immutable final observations. Retention follows the owning run; downgrade refuses to discard observations. Existing tool and event-journal migrations are prerequisites. Budget worker database capacity for cancellation polling and provider receipts. Research workflow histories use a version marker for the new shared deadline.
Cancellation-suppressing Python cannot be forcibly killed safely inside a worker. Bounded cleanup reports unfinished tasks and retains their dispatch fence. Hard termination is provided at the sandbox process/container boundary. The legacy thread-based restricted Python executor is unavailable inside controlled executions; use authorised workspace sandbox tools. Existing uninstrumented delegation recovery barriers remain. Live provider billing reconciliation, remote VM termination, deployment capacity and production latency bounds require staging qualification; local synthetic tests do not establish those guarantees.