Fleet RLM is a Session-first FastAPI application. DSPy owns the reasoning loop, Daytona runs generated Python, and the terminal client consumes the public HTTP and SSE contract.
Components
The life of a Turn
A Turn is one user request. A Run is one attempt to execute it.
- Request. Your client sends
POST /api/sessions/{session_id}/turns with an Idempotency-Key header. The SSE stream opens immediately and emits turn_status heartbeats while Fleet prepares.
- Claim.
TurnRuntime claims the Run for the Session. Only one Turn runs per Session at a time.
- Prepare. Fleet resolves authorized context, Attachments, selected Skills, and tools, and acquires a Daytona Sandbox.
- Execute. DSPy runs the RLM loop. Generated Python runs in the Sandbox and calls back to Fleet through an authenticated broker for host tools and semantic calls.
- Settle. Fleet validates the result and any candidate Artifacts.
- Commit. The answer and Artifacts become durable only through a successful Turn Commit. Late work can’t change a settled Turn.
- Clean up. Fleet releases or retires the Sandbox.
Where state lives
- Committed Turns are the conversation history. Fleet projects them into a native
dspy.History for the next invocation.
- The task checkpoint keeps a bounded goal and progress record for the Session. Read it with
/task or GET /api/sessions/{session_id}/task.
- The Workspace holds files, memory, Skills, Attachments, and Artifacts on a Daytona Volume.
- Python variables in the Sandbox are not durable state. A healthy Sandbox can be reused across sequential Turns, but each invocation starts with fresh bindings, tools, budget, and DSPy history.
See Sessions and workspaces for details.
Runtime policy
Non-secret policy lives in config/fleet.toml. The file names the environment variables that hold secrets. Fleet reads it once at startup, so changes take effect after a restart. See the configuration reference.
Related pages
Last modified on October 9, 2026
