modal-devin manages the compute lifecycle for sessions assigned to its outpost.
1. A session is queued
When a user selects your outpost in Devin, the session waits for an available orchestrator. The deployed Modal application watches that outpost.2. The session is accepted
modal-devin gives every invocation a unique acceptor identity and coordinates with
Outposts so only one worker serves an attempt. Modal may occasionally start duplicate
invocations because delivery is retried; a duplicate without session ownership exits
safely. Startup waits are shortened when necessary to preserve time for the
worker to connect before the server-assigned claim deadline.
3. The workspace starts
The session starts from:- Its preserved filesystem when resuming a suspended session, or
- The latest deployed worker image for a new session or expired snapshot.
4. The worker runs
The worker connects outbound to Devin Cloud and executes session tool calls inside the Sandbox. Its output appears in Modal logs with the Devin session ID.5. The outcome is preserved
The conservative failure behavior avoids reporting success when recoverable work
could otherwise be lost. Claim release and expiry allow another invocation to recover
a failed attempt using the Outposts fleet protocol.
6. Compute is cleaned up
The claim is released and the Sandbox is terminated after its state is handled. When an attempt fails, the session is made available for a later recovery attempt whenever possible.Resumability
Learn which filesystem a resumed session uses and how retention affects recovery.