Skip to content

Qredence/fleet-rlm

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1,923 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

fleet-rlm

PyPI version License: MIT CI PyPI Downloads Ask DeepWiki

fleet-rlm thumbnail

fleet-rlm is a persistent, Daytona-backed recursive DSPy workbench. Give it a task and optional context — files, URLs, pasted text, repository refs, datasets, or prior session state — and it adapts across direct reasoning, tool use, sandboxed execution, recursive sub-task delegation, and offline prompt optimization.

It targets developers and AI engineers who want an inspectable Web UI and CLI around long-context task execution without hand-rolling WebSocket transport, session persistence, Daytona lifecycle management, execution traces, and recursive DSPy orchestration.

Documentation | Source docs | Discord | Contributing | Changelog | Paper

Quick Start

Install the published package in a uv project:

uv init
uv add fleet-rlm
uv run fleet web

Open http://127.0.0.1:8000. Published installs ship built frontend assets, so normal users do not need a separate pnpm or frontend build step. If you already have a uv project, skip uv init and run uv add fleet-rlm.

What You Can Do

  • Run adaptive task sessions in Workspace.
  • Attach context from local files, staged documents, pasted text, URLs, repository URLs, and existing session history.
  • Watch reasoning, tool calls, sandbox activity, warnings, final answers, summaries, and generated evidence stream live.
  • Optimize registered DSPy modules or Fleet skills with dataset upload, run history, result inspection, and comparisons in Optimization.
  • Browse persisted runtime files and artifacts in Volumes.
  • Inspect runtime health, model connectivity, Daytona connectivity, and local runtime settings in Settings.
  • Manage LLM profiles, role bindings, auth state, sessions, sandboxes, traces, and runtime diagnostics over the FastAPI API.
  • Use terminal chat, HTTP, WebSocket, Daytona smoke checks, snapshot bootstrap, and offline DSPy optimization from the CLI.

The maintained routed product surfaces are /app/workspace, /app/optimization, /app/volumes, and /app/settings. The root route and /app redirect to /app/workspace.

Primary Commands

# Start the Web UI
uv run fleet web

# Terminal chat
uv run fleet
uv run fleet-rlm chat --trace-mode compact

# Run the API server directly
uv run fleet-rlm serve-api --host 127.0.0.1 --port 8000

# Validate Daytona connectivity without invoking an LM
uv run fleet-rlm daytona-smoke --repo https://github.com/qredence/fleet-rlm.git --ref main

# Create or refresh the reusable Daytona base snapshot
uv run fleet-rlm daytona-snapshot

# Run offline DSPy optimization for a registered module
uv run fleet-rlm optimize list
uv run fleet-rlm optimize <module> <dataset.jsonl> --report

See the CLI reference for the full command surface.

How It Works

fleet-rlm has four layers:

  • Product and transport shell — the React Web UI talks to FastAPI HTTP and WebSocket routes.
  • Runtime core — a DSPy ReAct agent coordinates task execution, tool use, streaming events, and recursive delegation.
  • Daytona substrate — sandbox interpreters, durable mounted roots, child-sandbox isolation, and execution artifacts keep work inspectable and persistent.
  • Persistence and optimization services — SQLModel-backed sessions, Neon/Postgres or SQLite storage, LLM profile management, trace feedback, and GEPA/DSPy optimization keep runs recoverable and improvable.

The runtime is goal-first rather than repo-first. A repository is one possible context source, alongside documents, URLs, pasted text, durable files, and previous session state.

Deeper detail: Product spec, Architecture overview, Recursive RLM isolation, Backend codebase map, Frontend/backend integration, HTTP and WebSocket API.

Codetree

The backend (src/fleet_rlm/) has eight canonical packages: api/ (FastAPI transport), runtime/ (DSPy agent core), integrations/ (Daytona, database, observability), config/ (constants), quality/ (offline evaluation and optimization), cli/ (operator commands), migrations/ (Alembic schema migrations), and ui/ (packaged frontend assets). The frontend (src/frontend/src/) has six: features/, components/agent-elements/, lib/workspace/, routes/, lib/rlm-api/, and config/.

Import boundaries are enforced by make check-codebase-tree:

  • runtime/ may not import from api.routers.
  • quality/ may import from runtime/ and integrations/ but not from api/.
  • Frontend features/ and components/ must not import directly from src/fleet_rlm/ (use lib/rlm-api/ for backend types).

See the codebase map for the full package inventory, ownership, public exports, allowed importers, and off-limits imports.

Runtime Contract

The current backend runtime is Daytona-backed and exposes these stable public surfaces:

  • /health, /ready, /api/v1/info
  • /api/v1/auth/*, /api/v1/sessions/*, /api/v1/runtime/*
  • /api/v1/llm-profiles/*, /api/v1/sandboxes/*, /api/v1/runs/*
  • /api/v1/optimization/*, /api/v1/traces/feedback
  • /api/v1/ws/execution, /api/v1/ws/execution/events

Most commonly integrated endpoints: /ready, GET /api/v1/auth/me, GET /api/v1/sessions/state, GET/PATCH /api/v1/runtime/settings, GET /api/v1/runtime/status, GET /api/v1/runtime/volume/tree, GET /api/v1/runtime/volume/file, GET /api/v1/optimization/status, POST /api/v1/optimization/run, GET /api/v1/optimization/modules, and the /api/v1/ws/execution socket.

WebSocket execution frames may include repo_url, repo_ref, context_paths, batch_concurrency, and an execution_mode hint. Durable mounted roots are memory/, artifacts/, buffers/, and meta/. Auth identity comes from the configured auth provider; browser WebSocket auth uses short-lived tickets instead of raw JWT query strings.

The canonical OpenAPI schema is openapi.yaml. When backend request or response shapes change, regenerate and verify API artifacts with make api-sync and make api-check.

RLM Capability Evaluation

Fleet-RLM has been benchmarked against the published RLM paper and Prime Intellect's official primeintellect/oolong-rlm environment.

Benchmark Paper RLM(GPT-5) Fleet-RLM + Gemini 3.1 Pro
S-NIAH (50 tasks, 50K-200K chars) solved 100.0%
OOLONG-Official (trec_coarse @ 128K) 56.5% 91.67% (+35.2 pp)
OOLONG synthetic (30 tasks) 56.5% reference 74.0%

Methodology, caveats, and the result breakdown live in RLM capability evaluation. Local generated result bundles may also exist under output/, but the docs page is the stable repository reference.

Source Development

Clone and install Python dependencies:

git clone https://github.com/qredence/fleet-rlm.git
cd fleet-rlm
uv sync --all-extras

Run from source:

make dev

For frontend development:

cd src/frontend
pnpm install --frozen-lockfile
pnpm run dev

The frontend dev server runs on http://localhost:5173 and proxies API requests to the backend on http://localhost:8000. make dev and uv run fleet web serve a built bundle from src/frontend/dist on http://127.0.0.1:8000; in a source checkout the server never falls back to packaged fleet_rlm/ui/dist assets. Build first with cd src/frontend && pnpm run build, or use pnpm run dev for HMR.

Common source checks:

make format-check
make lint
make typecheck
make test
make check-docs
make quality-gate

Frontend-only checks:

cd src/frontend
pnpm run api:check
pnpm run type-check
pnpm run lint:robustness
pnpm run lint:style-tokens
pnpm run lint:dead-code
pnpm run test:unit
pnpm run build

Or run the full frontend lane:

cd src/frontend
pnpm run check

See developer setup, testing strategy, and scripts inventory for the maintained contributor workflow.

Documentation and Validation

Start with the documentation home. Useful entry points:

For README-only or docs-only edits:

uv run python scripts/check_docs_quality.py --skip-contract-checks

When durable docs, command surfaces, generated contracts, or harness links move:

make check-docs

Environment Notes

At minimum, configure an LLM provider before running real task sessions:

DSPY_LM_MODEL=openai/gpt-4o
DSPY_LLM_API_KEY=sk-...

For Daytona-backed sandbox execution:

export DAYTONA_API_KEY="..."
export DAYTONA_API_URL="https://app.daytona.io/api"

See .env.example and installation for the full environment reference. Do not commit .env files or shared secrets.

Repository Layout

src/fleet_rlm/api/                   FastAPI app, auth, routers, WebSocket transport
src/fleet_rlm/runtime/               DSPy agent runtime, execution helpers, tools
src/fleet_rlm/integrations/daytona/  Daytona interpreter, sandbox lifecycle, durable volumes
src/fleet_rlm/integrations/database/ Postgres repository, schema, migrations-facing models
src/fleet_rlm/integrations/local_store.py  SQLite fallback store and local session helpers
src/fleet_rlm/quality/               Offline DSPy evaluation and optimization
src/fleet_rlm/cli/                   `fleet` and `fleet-rlm` entrypoints
src/frontend/                        React/TanStack Web UI, routed product surfaces, generated API client
docs/                                User, contributor, architecture, and reference docs
scripts/                             Maintained helper scripts and validation tooling
migrations/                          Alembic schema migrations

Generated or synced artifacts should not be edited by hand, including openapi.yaml, frontend OpenAPI client files, route trees, and packaged UI assets. Use the commands documented in AGENTS.md and the agent harness.

License

fleet-rlm is released under the MIT License.

About

DSPy's Recursive Language Model (RLM) with Daytona Sandbox for secure cloud-based code execution

Topics

Resources

License

Code of conduct

Contributing

Security policy

Stars

49 stars

Watchers

0 watching

Forks

Sponsor this project

 

Packages

 
 
 

Contributors