5dive speaks ACP now, so the session your client opens lands on one of your own agents.

every coding-agent runtime you can pick from a client is stateless on purpose. you select it, you get a fresh process that knows nothing about you, and you re-explain your repo from scratch.

5dive acp attaches instead. same picker, same protocol, except the thing on the other end already has your week in it.

---

what shipped

one verb: 5dive acp. it speaks the Agent Client Protocol over stdin and stdout, so an ACP client can drive a 5dive agent as its coding-agent runtime.

ACP is Zed’s. they open-sourced it in august 2025 as a way for an editor and a coding agent to talk without either one hardcoding the other, JetBrains came in after, and the two now run a registry of clients and agents that speak it. the useful part for you: it’s a standard with other people’s weight behind it, so this isn’t a 5dive-shaped port you’re locked into.

it isn’t interactive and you don’t run it yourself. the client spawns it. that’s the whole install story, because it’s a native verb in the CLI you already have, not an adapter shim you install alongside it.

your fleet arrives as slash commands

the moment a session opens, before you’ve typed anything, the roster lands:

Fleet agents:
  /marketing  — claude, opus
  /main  — claude, opus
  /community  — claude, sonnet
  /dev  — claude, opus
  /codex  — codex
  /ocqa  — opencode
  /ops  — claude, opus

Attach with /<name> or /attach <name>.

every agent, with what it runs on. and because the roster travels as the protocol’s own availableCommands, it can refresh mid-session: hire someone new, run /agents, and they’re in the list without reopening anything.

attach, not new

pick one and it says so plainly:

Attached to main. Its memory, tasks, org position and heartbeat are
the ones you already have — this session is a front end onto that
agent, not a new one.

main here is the same seat that’s been working your backlog, holding your tasks, and answering in telegram. not a persona wrapper, not a context file loaded to imitate one. the client is just another window onto it.

so a turn in your editor and a turn in chat are the same agent having one continuous week. close the client and it keeps going, because it was never the client’s process to begin with.

where it runs

the client spawns 5dive acp as a local subprocess over stdio. no port, no listener. it lists whatever 5dive agent list can see from that process.

which means the client has to run where your fleet is. on the box, or through an editor whose process lives there over a remote session. point one at a laptop with no fleet on it and it’ll tell you honestly:

No fleet agents are visible from here (`5dive agent list --json` returned none).

the honest edges

• it streams at the granularity of 5dive agent ask, not per token. you get the reply in the pieces that command prints, not a smooth crawl.
• a turn is bounded at 180 seconds by default. override with ACP_ASK_TIMEOUT. on expiry the turn ends clean and tells you nothing came back.
• we answer protocol version 1. clients that ask for 2 get negotiated down, on purpose: we’d rather answer with what we actually speak than claim a version we haven’t read.
• block/buzz is the client we built against, reading their ACP handling at source to match it. today you add 5dive there as a custom runtime by hand.

try it

it’s already in the CLI on your box. if you’re on an older build:

5dive self-update
5dive acp --help

then point your ACP client at 5dive acp and open a session. the first thing you’ll see is your own team.

---

running your fleet from the client you already have beats learning another chat window. and the agent you attach to is the one that already knows what you’re working on.

Start your own fleet →

or read the verb yourself, it’s all open source: github.com/5dive-ai/5dive