there’s one bash file at /usr/local/bin/5dive on every box running 5dive agents. you over ssh, the agent halfway through a refactor inside its own tmux, the managed dashboard at 5dive.com talking to its own box — they all call the same binary. the host can’t tell them apart, and that’s the design.

it runs on your hardware. it runs on ours. it runs in the docker demo on someone’s laptop. one contract for humans, scripts, and the agents themselves.

the rest of this post is the why.

---

one binary, two callers

5dive runs your coding agents — claude code, codex, gemini, hermes, openclaw, opencode — as linux users with systemd units. each agent is one user (agent-<name>), one unit (5dive-agent@<name>.service), one tmux session. credentials go straight from the agent’s home dir to the model provider. we don’t proxy auth.

5dive is what manages that stack. it doesn’t talk to a remote control plane. it runs on the host because that’s where the work happens.

the reason matters. the most interesting call to 5dive isn’t always you, sitting at home, spawning a worker. it’s the claude code agent that’s been working for two hours, halfway through a refactor, deciding it wants a subagent to audit middleware while it keeps going.

that call has to come from inside the box. so the binary lives there.

---

the surface, intentionally narrow

group	what it does
agent	lifecycle: create, list, send, ask, logs, stats, tui, clone, rm
account	shared auth profiles a team of agents can pull from
auth	per-type credentials: login, set, status, device-code
skill	install / list / remove SKILL.md bundles on an agent
pair	telegram / discord pairing
compose	declare a team of agents in yaml, stand it up in one shot
doctor	dependency, type-binary, auth, registry checks. --repair fixes the easy ones

you can read the whole reference in one sitting. more importantly, an LLM can use it without trial-and-error. that’s the actual product — a small host api with commands that recover cleanly when something is missing.

---

fan-out without a framework

the non-obvious thing about a cli on the host is that the agents on that host can call it.

every agent’s linux user is in the claude group, with sudo 5dive ... whitelisted in its sudoers. from inside one tmux session:

# spawn a worker for a side task
sudo 5dive agent create worker-1 \
  --type=claude \
  --workdir=/home/claude/projects/myrepo \
  --json

# send it a task, don't wait
sudo 5dive agent send worker-1 "audit auth middleware for OWASP A01"

# pull a fact back synchronously
sudo 5dive agent ask worker-1 "what did you find?" --timeout=120

# tear it down
sudo 5dive agent rm worker-1

two verbs — send (fire-and-forget) and ask (wait for the reply). no coordinator service. no orchestration layer. no JSON-RPC gateway to keep alive. the binary on the host is the bus.

we wrote about the consequences in your AI agents are coworkers — a claude agent asks codex for an image, codex asks gemini to animate it, the files pass through /tmp. that whole pipeline is two verbs and a shared disk. nothing in the middle.

---

same binary, your box or ours

we open-sourced 5dive. MIT, one bash file.

the version you curl … | sudo bash onto your own box is byte-for-byte the binary running on every 5dive.com vm. the skills bundles are the same. there is no open-core trick, no features locked behind a paywall — the CLI is the CLI.

what you pay 5dive.com for is operations: the vm, the hardening, the allowlists, the backups, the agent uptime, the fleet-of-agents view, and the dashboard at 5dive.com that drives all of it. that’s the differentiator — the OSS side stays terminal-first by design, like tailscale’s CLI vs. tailscale’s admin console. you can read the code that’s about to run your tokens, which is the only way the auth-token promise can actually be verified.

---

a json envelope for non-human callers

pass --json anywhere on the command line. stdout switches to a stable envelope. progress lines stay on stderr, so the caller can parse stdout without scraping a terminal transcript.

{
  "ok": false,
  "error": {
    "code": 6,
    "class": "auth_required",
    "message": "claude is not authenticated (missing) — run: sudo 5dive agent auth login claude"
  }
}

you branch on error.class. the human-readable message can change; the class doesn’t. twelve of them documented — auth_required, not_running, not_installed, pairing, timeout, conflict, and so on. the shell exit code matches error.code, so a bash script and a claude code agent both handle the same failure cleanly.

the design point: when something fails, the message tells the caller what command to run next. that’s the difference between a cli you can parse and a cli an LLM can drive.

---

isolation tiers, because not every agent should be trusted equally

three tiers — set at create time, applied by the systemd unit:

• admin — full host access. for the agent you actually trust to push to your repos and run your scripts.
• standard — its own home, can sudo into the 5dive surface only, can’t touch other agents’ files.
• sandboxed — quarantined home, locked-down sudoers, network egress restrictions. for an agent you’re letting a customer talk to, or one running an experiment you don’t want eating your filesystem.

you don’t manage it by hand. the create flag is the whole interface.

---

the 5dive-cli skill for claude code

drop it onto an existing agent on the host:

sudo 5dive agent skill <name> add \
  --source=5dive-com/skills \
  --skill=5dive-cli

once installed, the agent knows the right 5dive agent ... invocations and ordering, branches on the json envelope’s error.class instead of guessing from prose, and can spawn a worker on the same host, hand it a task, watch its tmux scrollback, tear it down when it’s done.

the skill is intentionally thin. it doesn’t re-implement the cli. it teaches the agent the surface and the recovery loop, then points at the docs as the source of truth. when the cli changes, the skill barely changes.

---

what we deliberately left out

• no remote control plane. you don’t point one cli at a fleet of vms from your laptop. each host is its own world. failure modes stay local. cross-host orchestration belongs in the hosted dashboard.
• no plugin system. the verbs are flat. we’ll add commands when we have to, not before.
• no telemetry, ever. the cli does not phone home. it only talks to the model providers you’ve configured.
• linux only. macos and windows via the docker image. native macos is on the list, not soon — systemd is load-bearing.

---

try it

if you’re already on a 5dive vm, you already have the cli. if you’re not, the install path is one prompt into your existing claude code / codex / gemini session — the agent runs the installer and ends up with the skill that drives it.

sudo 5dive agent create hello --type=claude --channels=none
sudo 5dive agent send hello "write a haiku about systemd"
sudo 5dive agent hello tui      # ctrl-b d to detach

full reference at the repo. bugs and feature requests on github.

short version: the cli isn’t a side door for power users. it’s the shared language between the host, the agents running on the box, and the managed dashboard at 5dive.com when you let us run the box — and now it’s yours to run on your own box too.