Fleet RLM

Recursive language-model backend with live streaming, durable sessions, and sandboxed execution.

Fleet RLM runs DSPy dspy.RLM behind a compact FastAPI + SSE API. Turns execute in Daytona sandboxes with workspace-scoped volumes, host-mediated tools, and a terminal client that streams reasoning, code, and output. The selected runtime reuses a healthy Session sandbox across sequential successful Turns; recursive children receive isolated disposable sandboxes.

Why Fleet RLM

• RLM-native — Native dspy.RLM execution with fresh invocation history and Turn bindings, native sub-LM queries, and optional recursive child RLMs.
• Operator-visible streaming — Reasoning, tool calls, interpreter code, and stdout flow over SSE to the maintained pi-tui terminal.
• Durable by default — Sessions, turns, attachments, artifacts, and workspace memory survive across runs.
• Sandboxed execution — Daytona interpreters run in isolated sandboxes with bounded workspace volumes and host-mediated memory tools.
• Policy-driven runtime — Non-secret behavior lives in config/fleet.toml; secret values stay in environment variables.

Current state

• Dependency baseline — pyproject.toml pins DSPy 3.3.1, Daytona 0.210.0, and MLflow 3.16.0; the optional optimize extra pins GEPA 0.1.4. The exact-version guard (CERTIFIED_DSPY_VERSION) rejects DSPy drift. Dependency checks and historical receipts do not certify a new source revision.
• Runtime boundary — retained broker execution is the sole supported architecture. The shipped daytona-recursive profile enables bounded child RLM tools, while comparison profiles may disable recursion; neither setting is a provider, quality, or capacity certification. See the implementation status.
• Turn orchestration — TurnCoordinator is the sole owner of the claim → cleanup path with atomic turn commit; the stream vocabulary is the closed v1 Runtime Event set (freeze suites in tests/freeze/).
• Recursive RLM — Native DSPy 3.3.1 child RLMs run under one contracted runtime owner (src/fleet_rlm/daytona/recursive_child_runtime.py) with a child deadline fence and zero-leak certification lanes in tests/live/backend/.
• Tools — Explicit Session Workspace (7 tools) and Project (6 tools) hosts; cross-sandbox Workspace Memory append coordination is unsupported by design.
• Optimization — src/fleet_rlm/optimization/gepa_runner.py drives the official gepa.optimize API under a max_metric_calls budget; no fleet optimize CLI exists yet.
• Live evidence — FLEET_LIVE=1 serial lanes write receipts under .fleet-evidence/receipts/ (archived sets under .fleet-evidence/receipts-archive/); see the testing strategy.

Quick start

1. Install

git clone https://github.com/Qredence/fleet-rlm.git
cd fleet-rlm
uv sync --all-extras --dev
pnpm --dir tools/fleet-tui install --frozen-lockfile

You need Node 22.19+ and pnpm for the terminal client (fleet cli). uv sync does not install TUI dependencies; run the pnpm step above before fleet cli.

2. Configure credentials

Pick a runtime profile in config/fleet.toml (default_profile; shipped default is daytona-recursive), then export the provider and Daytona variables for that profile. See the profile matrix for the exact environment names.

Fleet connects through an OpenAI-compatible Chat Completions base URL, so Databricks is only the shipped example. To use OpenAI or another compatible provider, update the selected profile's model, api_key_env, and base_url_env entries in config/fleet.toml; the base URL is typically the provider's /v1 root, such as https://api.openai.com/v1.

export FLEET_DATABASE_URL='postgresql+asyncpg://...'
export FLEET_DAYTONA_API_KEY='...'
export DATABRICKS_TOKEN='...'
export FLEET_LLM_BASE_URL='https://<workspace-host>/ai-gateway/mlflow/v1'

uv run python scripts/db_init.py

FLEET_LLM_BASE_URL is the committed Fleet chat-inference base; the client appends /chat/completions. Keep DATABRICKS_HOST for Databricks MLflow or evaluation tooling. FLEET_DATABRICKS_AI_GATEWAY_BASE_URL is reserved for explicit custom or benchmark paths and is not read by the shipped profile.

Startup never applies migrations automatically — initialize the database explicitly before serving.

3. Run

Supervised backend + terminal (recommended for local development):

uv run fleet cli

For an explicitly selected policy, pass its non-secret profile name to both launchers. The Phase 4 campaign profile is opt-in and does not change ordinary defaults:

uv run fleet-rlm serve-api --profile phase4-campaign --port 8000
uv run fleet cli --profile phase4-campaign

Backend only:

uv run fleet web
# or
uv run fleet-rlm serve-api --port 8000

Resume a durable session:

uv run fleet cli -- --session <session-uuid>

Before your first turn, verify Daytona connectivity:

uv run fleet doctor daytona

Profile mismatch fails fast. fleet cli requires a Daytona profile that matches your credentials. Select profiles with /profiles in the TUI or edit default_profile, then restart Fleet.

FastAPI is Fleet's canonical backend interface. fleet cli supervises that backend and attaches the pi-tui client; the TUI does not define a second execution path. An explicit --profile NAME is validated before provider, database, Daytona, or TUI initialization. The existing default_profile selection remains unchanged when the option is omitted, and explicit profiles cannot be combined with --reload.

The Phase 4 campaign sends all four arms (A/B/C/D) through supervised disposable FastAPI services via the public API/SSE transport, so lifecycle, authority, Daytona creation/deletion, and cleanup are measured on the same transport Fleet ships. The earlier receipt at .scratch/benchmark-reports/phase4-ablation-decf0da7.json is immutable, incomplete, and superseded; it is not value proof. Live campaign modes require the profile's MLflow tracking server to be reachable before they admit a trial, and every completed trial links its receipt row to the trial's MLflow root trace.

For a bounded live transport sample, run the fixed ten-trial API probe (the driver supervises all four arm services; no separately running backend is needed):

FLEET_LIVE=1 uv run python scripts/benchmarks/run_phase4_campaign.py \
  --partial-live \
  --output .scratch/benchmark-reports/phase4-api-partial-YYYYMMDD.json

The probe keeps every arm on the public FastAPI/SSE path and writes a content-safe exploratory receipt. It is not the 144- trial value campaign and cannot mark Phase 4 complete; unknown spend remains explicit in that receipt.

The 2026-09-10 exploratory receipt is retained at .scratch/benchmark-reports/phase4-api-partial-20260910.json and remains incomplete.

How a turn works

Client  →  POST /api/sessions/{id}/turns  →  SSE stream
                │
                ├─ validate scope, attachments, skills
                ├─ TurnCoordinator opens run + prepares context
                ├─ RLMRunner executes one native dspy.RLM in Daytona
                ├─ stream reasoning, tools, code, output events
                └─ RunLifecycle commits result, artifacts, and turn history

The root agent can answer directly, delegate to sub-LMs, or fan out bounded recursive child RLMs. Session history stays host-side; workspace memory (memory/MEMORIES.md) persists across sandbox replacement.

Commands

Backend logs for supervised runs: .fleet_rlm/logs/.

API surface

Full contract: HTTP API reference and OpenAPI.

Project layout

Development

make check                 # lint, typecheck, tests (default lane)
make api-sync              # regenerate OpenAPI + TUI types
make check-security        # security scans

Contributing workflow and architecture rules: CONTRIBUTING.md.

Key docs:

• Architecture
• P41 behavior freeze
• Configuration
• Terminal UI guide
• DSPy + Daytona integration
• Testing strategy

License

MIT — see LICENSE.