Skip to main content
Prompts can run for seconds or minutes depending on the task. This guide covers the patterns for controlling prompts in flight: checking status, canceling early, rewinding destructive changes, replaying history after a disconnect, and choosing between REST and WebSocket delivery.

When to use this

  • You need to cancel a prompt that is taking too long or going off track
  • You want to undo file changes the agent made during a prompt
  • You lost a WebSocket connection and need to recover the agent’s output
  • You are choosing between REST polling and WebSocket streaming for your integration

Prerequisites

  • An API key with sessions:prompt scope (and sessions:write for rewind)
  • A running session with at least one prompt already submitted

Check prompt status

The session object includes a last_prompt field with the status of the most recent prompt:

Cancel a running prompt

POST /api/sessions/{id}/prompt/cancel interrupts the current prompt. The agent task is stopped, the running flag is cleared, and any event streams receive their final events.
This endpoint is safe to call even when no prompt is running - it returns success either way. Use it as a “make sure nothing is running” gate before submitting a new prompt.
Canceling stops the agent, but file changes already written to disk are not reverted. Use rewind (below) to undo file changes.

Rewind file changes

POST /api/sessions/{id}/prompt/rewind restores the filesystem to a checkpoint captured during a prior prompt. The conversation history is preserved - only file contents are reverted.
Checkpoint IDs are surfaced in the agent’s event stream (via result events) and in prompt history. Use rewind when:
  • The agent made destructive changes you want to undo
  • You want to try a different approach from the same starting point
  • A prompt went off track and you want to restore the workspace
Rewind only affects files. The agent’s conversation context is preserved, so follow-up prompts retain awareness of what happened. If you want a clean slate, start a new agent session with resume: false.

Replay prompt history

GET /api/sessions/{id}/history returns the full parsed conversation for an agent session. Use this to reconstruct the conversation after a disconnect or to audit what the agent did.
The events mirror the same shape as the live WebSocket stream: user, assistant_text, tool_use, tool_result, and completion.

REST vs WebSocket: choosing the right approach

Use REST + SSE when:
  • You want simplicity and do not need to display streaming events in a UI
  • Your integration is a local script, coding agent, or CI pipeline
  • You only need the final result
Use WebSocket when:
  • You are building a UI that shows live agent output
  • You want structured event types (tool calls, file edits, text deltas) as they happen
  • You need the lowest-latency path from agent to client

Common patterns

Submit → wait → collect

The simplest REST pattern: submit a prompt, poll until done, read the result.
Python

Guard against concurrent prompts

Only one prompt runs per session. If you submit while one is running, you get 202 with status: "already_running". Guard against this:
Python

Next steps

Stream prompts over WebSockets

Full WebSocket connection flow with code samples.

Work with session files

Read, write, and download files from the sandbox.

Run Prompt reference

REST endpoint specification for submitting prompts.

Prompt History reference

Replay parsed conversation history.