The perfect agent orchestration tool for your friendly ADHD developer

Kashyap Jois — Tue, 05 May 2026 08:28:06 +0000

I have a serious problem, I can't work on just one thing for too long. I lose interest really fast. Before agentic coding, my desire to work on different projects and components of a project was easily managed. I could work on a really large project with a mobile app, a dashboard, a backend, multiple micro-services, while I let my YOLO model train in the background.
But once agentic coding came into the picture, I became an "ALT-TAB" junky. I just kept opening multiple terminals and switching between ssh sessions, typing prompts and moving on.
The main issue with this is the "illusion" of progress. You think you are super productive and have made great progress on atleast 10 different things, but you wake up the next day and see 10 terminals, 5 dead ssh sessions, 3 conversations you dont even remember about, clear everything, re initialize contexts and "ALT-TAB" your way into a dopamine hit.
My business partner - Akhil was facing the same issues and felt that we needed a platform to help people like us actually make progress and not get lost in this mirage of contexts, prompts, and I hate to say it but.. AI SLOP.
So we did what any reasonable developer does when they hit a workflow problem - build a side-project to fix it.

Apra Fleet — an open-source MCP server that lets one Claude Code session boss around agents on every machine I own. Register machines, dispatch work, get results back. One conversation. No YAML. No dashboards.

The "aha" moment was embarrassingly simple

I kept doing this:

Terminal 1: *deep in flow, building auth module*
Slack:      "hey tests are failing on staging"
Terminal 2: ssh into staging box
Terminal 2: start new Claude session
Terminal 2: re-explain the entire codebase architecture
Terminal 2: wait
Terminal 2: fix
Terminal 1: ...what was I doing again?

Each hop cost me 10-15 minutes just to get back in the zone. Six hops a day and I'm mass-producing nothing. Extremely efficiently.

The fix turned out to be stupidly obvious: what if I just told Claude to do it on the other machine? From right here?

"Run the test suite on staging and fix what's broken. I'll keep working."

That's it. That's the product.

Plot twist: you don't even need two machines

The thing we got wrong in v0.1: we made this sound like you need a homelab and a rack of servers. You don't.

The killer feature is doer-reviewer loops on a single machine. Register two local members - one writes code, one reviews it.Fleet pairs them:

You:   "Register local member `doer`, folder ~/projects/myapp.
        Register local member `reviewer`, different folder.
        Pair them on the auth module."

Fleet: Doer writes code → checkpoint → Reviewer reads it cold
       → "this will break if the token expires mid-request"
       → Doer fixes → Reviewer approves → done.

Folder isolation with git commits and an isolated git branch avoids fleet members stepping over each others feet.

The reviewer runs in a separate workspace context so it's not anchored to the same assumptions. It's like rubber-ducking except the duck actually talks back and has opinions about your error handling.

Everything gets a second pair of eyes before I even look at it. My PR review comments dropped by like 60% and my ego is handling it fine.

Install (it's a one-liner, I'm not a monster)

macOS (Apple Silicon)

curl -fsSL https://github.com/Apra-Labs/apra-fleet/releases/latest/download/apra-fleet-installer-darwin-arm64 \
  -o apra-fleet-installer && chmod +x apra-fleet-installer && ./apra-fleet-installer install

Linux (x64)

curl -fsSL https://github.com/Apra-Labs/apra-fleet/releases/latest/download/apra-fleet-installer-linux-x64 \
  -o apra-fleet-installer && chmod +x apra-fleet-installer && ./apra-fleet-installer install

Windows (PowerShell)

Invoke-WebRequest -Uri https://github.com/Apra-Labs/apra-fleet/releases/latest/download/apra-fleet-installer-win-x64.exe `
  -OutFile apra-fleet-installer.exe; .\apra-fleet-installer.exe install

Then in Claude Code:

/mcp

Fleet skill + PM skill installed by default. No config files. I mass-produced the setup so you don't have to.

"But wait, you're giving Claude SSH access to ALL your machines??"

Yeah I knew someone would say this. Akhil and Mradul (another ALT-TAB Junky) went back and forth on this for weeks. Here's the paranoia we baked in:

Passwords never enter the LLM's brain

When you register a machine with a password, Fleet does NOT pass it through Claude. Instead:

You → "Register web1, password auth, host 192.168.0.5"

Claude → register_member(name="web1", auth_type="password", host="...")
                                            ↑
                                No password in the params

*a wild terminal appears*

You type password in the new window (hidden input)
Password → Unix socket → MCP server → AES-256-GCM encrypted immediately
Claude ← "Member registered successfully"
Claude's context window: blissfully ignorant

A whole Unix domain socket side-channel so Claude never sees your password. We wrote an entire ADR about why every other approach was worse.

The credential store (new in v0.1.8, very proud of this one)

General-purpose secret storage with {{secure.NAME}} substitution:

# Store it once — Fleet opens a separate terminal, never asks in chat
credential_store_set  name=github_pat

# Use it in commands — resolved server-side, Claude sees nothing
execute_command  command="curl -H 'Authorization: Bearer {{secure.github_pat}}' https://api.github.com/user"

# Output is auto-redacted before the LLM sees it
# → Authorization: Bearer [REDACTED:github_pat]

And the one hard rule: execute_prompt does NOT support {{secure.NAME}}. Secrets never go into LLM prompts. Not sometimes. Not "just this once." Never. I will mass-produce error messages at you if you try.

Scoped git tokens because long-lived PATs are crimes

Each member gets short-lived (1hr) tokens via GitHub App:

members:
  code-analyst:
    git_access: read          # can clone, can't push
    git_repos: [Apra-Labs/ApraPipes]

  release-bot:
    git_access: admin         # full send
    git_repos: ["*"]

Compromised member? Token expires in an hour, only touches scoped repos. The App private key never leaves the master machine. Sleep well.

Multi-machine mode (when one machine can't contain you)

register_member(
  friendly_name          = "gpu-trainer",
  host                   = "10.0.0.5",
  username               = "ubuntu",
  key_path               = "~/.ssh/gpu.pem",
  work_folder            = "/home/ubuntu/training",
  cloud_provider         = "aws",
  cloud_instance_id      = "i-0abc123def456789a",
  cloud_idle_timeout_min = 30,
)

The instance doesn't need to be running. Fleet auto-starts on demand, auto-stops after 30 min idle. GPU-aware — if nvidia-smi shows active compute, the idle timer backs off. Your training job won't get killed at epoch 97 of 100. (Ask me how I know.)

Session IDs persist per member. The remote agent remembers prior conversations. Not stateless RPC — actual continuity.

Long-running tasks (the "set it and forget it" pattern)

execute_command(
  member_id       = "gpu-trainer",
  command         = "python train.py --epochs 100",
  long_running    = true,
  max_retries     = 3,
  restart_command = "python train.py --resume checkpoint.pt",
)

Returns immediately. A bash wrapper on the remote handles nohup, PID tracking, status JSON, heartbeat every 5 min (prevents idle shutdown), and auto-retry with checkpoint resume on crash.

Check whenever:

monitor_task(member_id="gpu-trainer", task_id="task-lx4k2z", auto_stop=true)
# → { status: "running", gpuUtilization: 87, logTail: "Epoch 45/100, loss=0.234..." }

auto_stop: true shuts down the EC2 instance when the job finishes. Because I also mass-produce AWS bills when I forget.

The PM skill (project management, but make it terminal)

Built-in, installed by default:

/pm init my-project          # scaffolds project folder
/pm plan "OAuth2 auth flow"  # generates + reviews implementation plan
/pm pair doer reviewer       # automated doer-reviewer loop
/pm status build-server      # where are we
/pm deploy build-server      # ship it

State is git-tracked — PLAN.md, progress.json, feedback.md. Every agent reads the same state before acting. The PM handles git transport between doer and reviewer, sends context, and iterates until the reviewer approves.

It's like having a very patient, very literal project manager who never takes PTO and never asks "can we sync on this?"

Mix your providers (vendor lock-in is for people who read EULAs)

Members aren't locked to Claude. Mix freely:

Role	Recommended	Why
PM	Claude Opus/Sonnet	Most tested for planning
Doer	Anything	Sonnet, Gemini Flash, Codex — pick your fighter
Reviewer	Premium tier	Catches what smaller models miss

"Register `gemini-worker` at 192.168.1.11 as a Gemini member."

Same execute_prompt call, different brain under the hood. Fleet resolves the right CLI per member at runtime.

What's missing (because honesty builds trust faster than marketing)

Ollama / local models — architecture supports it, adapter not built yet. LocalLLaMA people, I see you, I'm coming
GCP / Azure — only AWS EC2 today
Docker / K8s members — roadmap
Web dashboard — foundation exists, not shipped
npm publish — npx apra-fleet install coming soon Apache 2.0. v0.1.8. Actively developed. Unreasonably fun to work on.

GitHub: Apra-Labs/apra-fleet

What's your multi-agent setup look like? I'm genuinely curious how other people are solving the "4 machines, 1 brain, 0 discipline" problem. Drop your workflow below — or tell me what Fleet is missing that'd make you try it.

DEV Community: Kashyap Jois