Open source agent frameworks on boxd

Every agent framework hits the same wall at the same moment. The agent works. Now it has to run somewhere that is not the laptop of the person who wrote it.

A laptop is a fine place for a demo and a bad place for anything that executes generated code, serves live requests, or fans out a hundred benchmark trials at once. So framework authors go shopping for a runtime, and most of what is on the shelf hands back something narrower than a computer.

Three open source frameworks now run their agents on boxd machines. All three are live today, and the interesting part is that no two of them want the machine for the same job.

Flue: one machine per agent

Flue is the agent harness framework from Fred K. Schott, known from Astro. It feels like Claude Code, and it is fully headless and programmable in TypeScript.

A Flue agent can opt into a full sandbox. The boxd connector gives each agent a Linux VM of its own, so two agents in the same program never share a filesystem. That stops being a nicety the moment you run more than one of them.

import { Compute } from '@boxd-sh/sdk';
import { boxd } from './connectors/boxd';

const c = new Compute({ apiKey: process.env.BOXD_API_KEY });
const box = await c.box.create({ name: 'my-agent' });
const agent = await init({ sandbox: boxd(box), model: 'anthropic/claude-sonnet-4-6' });
const session = await agent.session();

You own the machine's lifecycle through the TypeScript SDK. You create it, and you decide when it goes away. The connector's whole job is adapting that machine to Flue's sandbox interface, so the agent sees the sandbox it expects and nothing has to be faked.

The connector is written so a coding agent can install it into your Flue project for you. (More integrations should ship in that format.) Flue's own docs cover it under sandboxes.

Bindu: the machine as the server

Bindu is the identity, communication, and payments layer for AI agents. Wrap an agent written in any framework with bindufy(), and it becomes a signed A2A microservice.

A microservice needs somewhere to live. With the boxd runtime, that somewhere is a boxd machine instead of your laptop.

bindu deploy my_agent.py --runtime=boxd --auto-suspend=60

✓ my-agent serving at https://my-agent.boxd.sh

The agent gets its own HTTPS URL. Auto-suspend fits that shape well: the machine sleeps between requests and wakes when a call arrives.

So a deployed agent spends most of its life asleep at a stable address, and the first call wakes it up.

The Bindu repo has the full runtime options, including deploying from a custom Docker image.

Harbor: the machine as a disposable test rig

Harbor evaluates and optimizes AI agents and models. It runs agents like Claude Code, Codex, or OpenHands against benchmarks like Terminal-Bench and SWE-Bench, across many parallel sandboxes.

Evaluation is the harshest thing you can point at a sandbox, and it is harsh in a boring way. Benchmark tasks ship as Dockerfiles, and often as multi-container docker-compose.yaml stacks. A sandbox that cannot run Docker properly cannot run the task, and the usual workaround is editing the task until it fits the sandbox, which quietly changes what you are measuring.

The boxd environment provider gives every trial its own isolated KVM microVM with a full Docker daemon. The tasks run unmodified.

export BOXD_API_KEY=<your-key>
harbor run --dataset terminal-bench@2.0 --agent claude-code --model anthropic/claude-opus-4-1 -e boxd

For benchmarks we recommend starting from snapshots. Prepare a machine to your liking, snapshot it, then start every sandbox from there with --ek from_snapshot=<name>.

This shortens the startup sequence drastically. Each trial restores a machine whose Docker cache already holds the task image, so no trial builds that image from scratch.

The provider is awaiting merge upstream. You do not have to wait for it. Install Harbor from the pull request's branch, and everything above works today.

uv tool install "harbor[boxd] @ git+https://github.com/MichielMAnalytics/harbor.git@add-boxd-environment"

Three jobs, one primitive

Flue treats a boxd machine as a sandbox, Bindu treats it as a server, Harbor treats it as a disposable test rig. Underneath it is the same thing every time: a full Linux machine the framework owns outright. None of the three had to work around the machine to get what it wanted from it, which is the best evidence we have that the primitive is the right shape.

All three integrations are open source, and the code sits behind the links above. Read the connector, the runtime, and the environment provider before you run any of them. We would rather you did.

Building an open source framework that should run on boxd? Or using one you would like to see supported? Email contact@boxd.sh.

Michiel Voortman

PostShare⎘Copy link