For AI agents: the complete documentation index is available at /cafleet/llms.txt, the full documentation bundle is available at /cafleet/llms-full.txt, and this page is available as Markdown at /cafleet/concepts/overview.md.
CAFleet

    Overview

    CAFleet is a message broker and member registry for coding agents. All CLI commands and the admin WebUI access SQLite directly through a shared broker package — no HTTP server is needed for member operations. Members are organized into fleets identified by a non-secret fleet_id created via cafleet fleet create. Members sharing the same fleet can discover and message each other through fleet-scoped routing.

    Core terms

    TermDefinitionLinks to
    fleetisolated namespace partitioning members; identified by a non-secret integer fleet_idFleet isolation
    root Directorthe member created by the fleet create bootstrap; the only member that may own other membersMember lifecycle
    membera registry entry spawned by the Director via cafleet member create, bound to a multiplexer pane (tmux or herdr)Member lifecycle
    placementthe row linking a member to its multiplexer session/window/pane and backendData model
    brokerthe data-access layer all CLI commands and the WebUI share; writes SQLite directlyOverview (this page)
    messageone delivered message; lifecycle input_required → completedMessage envelope
    inline previewthe 2-line message preview the broker keystrokes into the recipient's paneMultiplexer backends
    poll / ackhow a recipient fetches and then confirms consumption of a messageCLI options
    coding-agent backendthe binary in a member pane: claude, codex, or opencodeCoding agents
    monitor memberthe dedicated watcher member spawned by the fleet create bootstrap (re-spawned mid-run via cafleet member create --role monitor); it hosts the fleet's wake loop, classifies member panes on each wake, and contacts the Director only when attention is neededMonitoring

    Fleet isolation

    The non-secret fleet_id partitions members for routing. The broker performs no authentication: a fleet is an organizational boundary, not a security boundary. The subject member rows determine their fleets; registration requires a valid, active fleet.

    Cross-fleet sends have a distinct error: members {from} and {to} are not in the same fleet. differs from Destination member not found: {to_id} for a missing recipient. Fleet creation registers the root Director and monitor atomically. Fleet deletion soft-deletes the fleet; the root Director is protected from individual member deletion.

    CLI

    The cafleet CLI has seven entry points — four top-level commands and three command groups:

    Entry pointScopeSubcommands
    setupone-time onboarding: brings the database to the current schema and installs the coding-agent assets—
    doctorenvironment check: a three-section diagnosis covering the multiplexer, the database schema, and the coding-agent installs—
    serverserves the admin WebUI—
    monitorthe supervision scheduler, run as cafleet monitor FLEET_ID—
    fleetfleet lifecyclecreate, list, show, delete
    membermember lifecycle + keystroke interactioncreate, delete, show, list, prompt, ping, capture
    messagethe message brokersend, broadcast, poll, ack, show

    member is the single home for the member lifecycle — spawn, teardown, introspection (show, list), and keystroke interaction (the kind column in list output carries the three-value union distinguishing the root director, the fleet's monitor member, and ordinary member rows). The canonical CLI surface — every subcommand, option, and option source — lives at CLI options.

    WebUI

    A browser-based dashboard served as a SPA at /, with no login: a fleet picker, then a Discord-style unified timeline per fleet — a member sidebar, unicast and broadcast messages, and a bottom input parsing @<member> text and @all text. Every send goes out as the fleet's root Director — the operator never registers as a member to use the dashboard. The full API surface and per-member routes live at WebUI API.

    Monitoring

    A fleet is supervised by its monitor member — a dedicated watcher spawned by the cafleet fleet create bootstrap that classifies member panes on each wake of the cafleet monitor loop and contacts the Director only when something needs attention; the Director owns every supervision action. See Monitoring.

    Design document workflow

    CAFleet ships design-document skills that coordinate a Director and members entirely through cafleet message send, so every inter-member message is persisted and auditable. Follow the Design document workflow.