Resuming chats

Continue a coding-agent session across turns and sandbox replacements.

A chat is designed for multi-turn work. Each turn runs in the chat's sandbox, then the sandbox is stopped until the next turn.

Resume request

Send the previous chat_id, a new prompt, and the provider credential needed for this run:

{
  "chat_id": "01K...",
  "prompt": "Review your previous change and simplify the implementation.",
  "provider_api_key": "sk-proj-..."
}

Do not create a second turn until the current one reaches a terminal status. Concurrent turns in the same chat return 409.

What carries over

The chat retains:

  • harness and model;
  • system prompt;
  • MCP servers;
  • CPU, memory, and disk selection;
  • sandbox filesystem while that sandbox remains available;
  • agent session context from earlier turns.

The harness is launched in resume mode after the first turn.

Sandbox replacement

Cloud sandboxes are not assumed to live forever. If Epho cannot restart the original sandbox, it creates a replacement and restores the most recent agent session snapshot uploaded by an earlier turn.

This lets the harness recover its conversational session even when the original compute environment is gone. Files that only existed in an unavailable sandbox are not guaranteed to be reconstructed; use repositories and output artifacts for durable inputs and outputs.

Per-turn values

These values may change on every turn:

  • prompt
  • provider_api_key
  • repos
  • input_files

Repository tokens are therefore easy to refresh on a resumed run, and new repositories or attachments can be introduced later in the conversation.

Chat-level values

Treat these as creation-time settings:

  • harness
  • model
  • system_prompt
  • instance
  • env
  • mcp_servers

The existing values are inherited on resume. env and mcp_servers are explicitly rejected if supplied with chat_id; omit the other chat-level fields because they do not reconfigure the existing chat.