I looked into durable agents with OpenCode v2 and Pi v1, using the Syntax discussion about a shared backend across terminal, web and desktop interfaces alongside the framework documentation.1 This was a research pass, not a new service I had deployed.
The part I wanted to get clear was what actually survives a restart. Being able to reload the conversation is useful, but it does not tell me whether unfinished work resumes, whether the checkout still exists or whether a tool call is about to happen twice.
Four things to keep separate
- The conversation and its configuration.
- The execution state of unfinished work.
- The files and environment the tools operate on.
- External actions that may already have succeeded.
The Cloudflare integrations helped make the distinction concrete. The OpenCode example replaces unsupported local file and shell tools rather than pretending a Worker has a normal coding checkout.2 Pi's recovery documentation distinguishes tools safe to replay from other interrupted tools, which return control to the model instead of automatically running again.3
Neither observation gives arbitrary external actions an exactly-once guarantee. A saved transcript cannot, by itself, tell me whether an API request succeeded just before the process died.
The prototype I would want next is deliberately small: one persistent conversation, one replay-safe read and one idempotent write, with crashes injected around the write and the result recording. That remains a proposed test, not a result from this research pass.