Documentation Index
Fetch the complete documentation index at: https://docs.worldflux.ai/llms.txt
Use this file to discover all available pages before exploring further.
Where the model lives
The model lives on whatever machine you trust to hold the data. WorldFlux watches the run from the side, picks up the manifest, and uploads it. That is the whole boundary.| Source | What you do | What WorldFlux sees |
|---|---|---|
| Local script | worldflux init, drop your code into run.py, worldflux run. | Manifest, metrics, logs, committed artifacts. |
| Vendor runtime | Pass --runtime replicate (or aws-ec2, modal). | Whatever the runtime plugin returns in RuntimeResult. |
| External model | worldflux import lerobot:<model_id> to pull it into the catalog. | The imported adapter shows up in worldflux curated list. |
| External dataset | worldflux import lerobot-dataset:<id> to download. | The dataset id is referenced from the recipe. |
local, modal, aws-ec2, replicate) all produce the same manifest shape. The dashboard does not care which plugin produced the run.
Data boundary
Three rules:- The CLI uploads manifest fields, metric numbers, log lines, and any artifact paths the recipe marks
commit. Nothing else. - Secrets stay outside the manifest. The CLI keyring (or
~/.worldflux/credentials.tomlwith--allow-plaintext) holds the API key. The audit payload never carries it. - API keys travel as
Authorization: Bearer wbx_…headers, scoped to one workspace, expirable.
Pre-flight
Before the first sync:error: block runs.
Pass --json from CI
What changes when you sync
Nothing on disk. The CLI POSTs to FastAPI and exits. The next time the dashboard loads, the run shows up in the workspace’s runs table. Failed uploads leave the local manifest untouched andworldflux sync re-tries from the same client_run_id.