http://127.0.0.1:8000 by default. Start it with fleet serve. The terminal client uses the same API.
- The API has no caller authentication. Keep it on loopback. See Security.
- Routes have no
/apiprefix.openapi.yamlin the package documents every route and response model. - Errors use the FastAPI shape
{"detail": "..."}with an HTTP status code. Invalid request bodies, IDs, and paths return422. Request bodies reject unknown fields. - Session IDs are 1 to 64 letters, digits, dots, underscores, or hyphens, and can’t contain
... Fleet creates a Session the first time you use its ID. There is no create route.
Session lock
Each Session runs one Turn at a time. A Turn holds the Session lock until its stream ends and its sandbox work has drained. These routes take the same lock: Turn, mode, model, and context changes, memory writes and deletes, Skills, workspace files, and attachments. When a Turn already holds the lock, they wait 2 seconds and then return409. Retry when the Turn completes.
History and Turn status don’t take the lock. They read from PostgreSQL, so they work during a Turn and from any server process.
Turns
Run a Turn
The response is a
text/event-stream of Turn events. See Stream events.
- The stream reports exactly one outcome event:
turn_complete,error, orturn_cancelled. A finaldoneevent follows it after cleanup. If the Turn stops without reporting an outcome, Fleet sends a sanitizederrorevent. - A second Turn on a busy Session gets
409after 2 seconds, before any stream starts. - Closing the connection before the outcome event cancels the Turn. Closing it after the outcome keeps the completed Turn and its warm root Sandbox. Either way, Fleet keeps the Session locked until the sandbox work has drained, so two Turns never overlap in one sandbox.
- Fleet records the Turn intent before it runs. If you resend a completed Turn with the same
idempotency_key, Fleet replays the stored outcome instead of running it again. A failed or uncertain earlier attempt is not replayed. Reusing a key for a differenttaskreturns anerrorevent. record_replaycan retain sensitive workspace content. Use it only for data approved for that purpose.
Get a Turn’s status
turn_id, status, result, and updated_at from PostgreSQL, or 404 when the Turn is unknown. Use it to recover an outcome after a dropped stream. It doesn’t replay the Turn.
result.provenance_state tells you whether the stored outcome records which sandbox snapshot it ran on:
Get history
session_id and the stored turns. Fleet reads history from PostgreSQL without starting the Session’s sandbox.
Sessions
Mode, model, and context selections persist and survive a server restart. Model discovery is optional. You can always set a model route manually.
Context
Select a workspace file as the Session’s dataset context.Workspace files
These routes operate on the Session’s workspace. Paths are relative to the workspace root. Files are limited to 25 MB.storage.max_upload_bytes and 25 MB. Larger uploads return 413. Unavailable or invalid file paths return 404.
Memory
Skills
These routes take an optionalsession_id query parameter. It defaults to default.
See Skills.
Experiments
These routes run and review GEPA optimization for a Session on the server. Fleet runs the optimizer in a separate worker process and stores each run’s lifecycle in PostgreSQL. The server runs one optimization at a time, so a start request while another run is active returns409 instead of queueing.
The start body accepts the same search options as
fleet optimize:
Each run has
run_id, session_id, status, and, when known, stage, options, candidate_version, gate, dataset_sizes, progress, failure, mlflow_run_id, decision, and timestamps. status is running or approving while the run is active, and completed, failed, cancelled, interrupted, approved, or rejected once it ends.
A passing candidate stays inactive until you approve it. Approval works only on a completed run. Fleet rechecks the candidate’s evidence before it serves the candidate from the Session’s next Turn. Rejection records the decision without installing anything.
These routes return 404 for an unknown run, 409 when the request conflicts with the run’s status or another active operation, 422 for an invalid body or run ID, and 503 when experiment storage or the worker is unavailable.
Health
Routes return
503 while Session storage or the Session runtime is unavailable. This includes a server that has reached runtime.max_active_sessions or a Session owned by another server process.