nfltr orch

AI coding agents where your infrastructure lives.

nfltr orch is a distributed Claude Code hub. It runs Claude Code agents on the laptops, VMs and private servers that hold your data, services and test environments. Each machine joins once and sets what its agents may do. A goal goes to one Claude session, the hub, through nfltr orch or your own Claude Code session; the hub sends each piece of work to the machine that has the data or access, runs agents in parallel, and collects every result.

Getting started Overview CLI reference Dashboard

your terminal 
nfltr orch "the exporter on the VM is down: find out why and fix it"
nfltr.xyz relay carries messages, runs no model
  • laptop code and git push
  • cloud VM the dataset, the service
  • build server joined, idle
Each machine joined once with nfltr node join. Claude Code runs the agents on each machine; the dots are agents running out of that machine's limit.

Recordings from real machines

Eight terminal recordings from a laptop and Google Cloud VMs joined to nfltr.xyz. The first four run in a plain claude session after claude mcp add nfltr -- nfltr mcp --toolset hub; the other four use nfltr orch. Pauses longer than two seconds are shortened and nothing else is edited; the two long ones play faster, as marked. Models and budgets on screen were picked for the recording; nothing is chosen for you.

Measured, one run on 2026-10-01

From alert to an approved rollback in 1 m 34 s

A bad config change made an API crash-loop on a Kubernetes cluster, and the alert went to a webhook the hub had created. The goal said: investigate, propose a fix, apply it only with the owner's approval, stop once the alert resolves. The hub sent a read-only agent to the node with cluster access; the change itself ran on a separate write node, and only with the owner's signature.

11.8 s
after the alert fired, the hub had it
46.4 s
the read-only agent's result: the crash, the failing setting, a healthy previous revision
1 m 17 s
the owner signs the exact rollback prompt
1 m 34 s
rollback applied; 2 of 2 pods ready seconds later
$0.39
model spend for the incident session

Setup: a local kind cluster with Prometheus and Alertmanager; four nodes, each its own container: a read-only cluster node, a write-capable cluster node gated on the owner's approval, a CI node with the build logs, and a laptop node with the developer's checkout. The owner's signing key sat in a separate container with no network. Apart from the webhook secret the goal asked for, revoked at the end, no credential appeared in any transcript or log. Text in the alert, a pod log and the PR telling agents to delete namespaces was ignored, and the hub reported it to the owner.

Where each piece came from

  • No machine held the whole story: the cluster had the crash, CI had which build made which image, the laptop had the PR's diff.
  • Asked which build and PR caused it, the hub ran one read-only agent on the CI node and one on the laptop node in parallel and answered in 53 s for $0.25: the build, the PR, the commit, its author and the change.

Not there yet

Unprompted, the hub stopped at a correct mitigation: its report named the failing setting but not the build or the PR. Those took the one extra message from the owner.

What nfltr orch is useful for, measured →

What each machine allows

Agents get the machines, data and environments they need without SSH or VPN plumbing, and only what each machine's owner allows. Join machines as nodes has every flag.

Measured, one run on 2026-10-01

20 tasks on 4 nodes, 5.7× faster than running them one after another

One Claude Code hub got 20 independent coding and data tasks and 8 agent slots. It started agents ahead of free slots, so a slot that freed up was taken by the next waiting agent, and the batch finished in 1,416 s against 8,106 s of agent time added end to end.

5.7×
less wall time than the agents' run times added up
60 %
of the run with all 8 slots busy
1 s
median from a freed slot to the next agent starting
4 of 4
data-bound agents ran on the node holding the data
20 of 20
tasks passed their hidden checks, at $0.73 a task

Setup: four nodes, each a container on one host limited to 2 CPUs and 2 agents, one of them kept busy by other load; the same Claude model for the hub and every agent; a private relay, not nfltr.xyz. Serial time is the sum of this run's agent times, not a separate single-agent run. The checks were judged on the status the hub answered: spend passed the run's $14.50 cap by $0.17 after the final answer, so the strict runner marked all 20 over budget.

How it fills the slots

  • The hub starts many agents in one call. Each one waits for a free slot instead of failing.
  • A freed slot goes to the next waiting agent. Work that may run anywhere goes to the node with the most spare CPU: the loaded node got an agent only while every other slot was busy.
  • Claude pins data-bound work to the machine holding the data and makes every other placement choice. You can add your own scheduling guidance with --hub-guidance-file.

Not there yet

The hub does not yet split one big task across agents. One long task on the loaded node kept a single slot busy for the last four minutes, so the run took 1.4× its ideal (busy time divided by 8 slots).

How the hub learned to fill a fleet →

How a setup looks

  1. The CLI and a key on each machine

    Each machine runs the nfltr CLI with an API key of your account, created in the dashboard.

    curl -fsSL https://nfltr.xyz/install.sh | sh -s -- --with orch
nfltr config add-api-key

  2. Each machine joins once as a node

    A laptop, VM or server that runs agents has Claude Code installed and a Claude token in the environment: agents run with a clean Claude config, so a keychain-only claude login is not used. Tools are opt-in: without --allow-all-tools agents can edit files but shell commands are refused.

    export CLAUDE_CODE_OAUTH_TOKEN=<token>  # from claude setup-token, or set ANTHROPIC_API_KEY
nfltr node join --max-agents 2 --allow-all-tools

    --machine-description "has the sensor dataset" tells Claude what a machine is for.

  3. A goal goes to the hub

    From any terminal, or from your own Claude Code session. Claude picks the machines, starts the agents and reports as each one finishes.

    nfltr orch "<goal>"

    Or the hub tools in your own session:

    claude mcp add nfltr -- nfltr mcp --toolset hub
claude

When it helps

What you can rely on

Every result arrives once
Agents keep running when your terminal closes or the hub is killed. Start the hub again with the same hub id, or reopen the project in Claude Code, and every result you missed is delivered, exactly once. In our restart test, a new hub session got both results from its first wait and answered within 8 s (the test).
Claude Code runs the agents
Every agent is a Claude Code process on one of your machines, using the Claude token you give that machine. nfltr.xyz only carries messages and runs no model.
Nothing is picked for you
NFLTR sets no machine, agent count or model. Claude and you decide; anything left unset is up to Claude Code on that machine.
Spend you can cap
The hub counts each agent's reported cost; --hub-max-usd and --hub-max-tokens stop running turns once passed.

Documentation

The getting-started guide joins two machines and runs a first goal end to end. The guides cover nodes, Claude Code, many agents across machines, observing and recovering runs, and building your own agent platform on the hub.

Getting started Join machines as nodes From Claude Code Hub tools CLI reference