Skip to main content
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.
The Sandbox must become ready before the Devin worker begins.

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.