Home

Fleet RLM

Fleet RLM is a backend-first recursive language-model (RLM) workbench for long-running operator tasks. It couples a FastAPI HTTP/SSE backend in src/fleet_rlm/ with native dspy.RLM execution, and ships a pi-tui terminal client in tools/fleet-tui/ as the maintained interactive surface. There is no graphical web frontend.

Operators create Sessions, submit idempotent Turns over the local HTTP/SSE API, attach files, select bundled Skills, and watch bounded Run evidence stream into a monochrome terminal timeline. Two public Run Environments exist:

• Daytona — the full runtime. Each Turn executes inside a Daytona Sandbox with workspace-scoped durable Volumes, Session Workspace files, Workspace Memory, durable Attachments, and committed Artifacts.
• Deno — the reduced local runtime. A real LLM with DSPy's default Deno/Pyodide interpreter, Attachment reads, and Skills, but no durable Artifact promotion.

The canonical backend is src/fleet_rlm/ (Python 3.11–3.13, dspy==3.3.0b1 pinned exactly). Runtime policy is BYOK: [config] default_profile in config/fleet.toml selects a profile, and only environment variables named by that profile supply secrets and endpoints.

Quick links

Topic	Page
System design	Architecture
Install, run, validate	Getting started
Vocabulary	Glossary
The two runtimes	Applications
Backend internals	Systems
Operator capabilities	Features
HTTP and SSE contract	API
Configuration reference	Configuration
History of the codebase	Lore

Product boundaries

Fleet has one deterministic process-local User and Workspace scope. It does not offer multi-user authentication, caller-provided execution profiles, a public provider-key API, or a general-purpose Sandbox filesystem browser. Provider credentials stay in the process environment or .env values referenced by the selected policy and are never returned by the API. See PRODUCT.md for the full boundary statement.

---

Generated by Factory