LoadTableFive agents. One laptop. Nobody freezes.
Claude Code, Codex, Cursor and the rest all reach for cargo test and gradlew at the same moment. LoadTable queues their heavy commands, runs each one on whichever of your machines can take it, and keeps a record of who ran what, where, and how long it took.
Your agents keep running where they are. Only the builds and tests move.
- 4712cargo test -p core --lib videoETA 3m10s
- 4713./gradlew :app:assembleDebugETA 1m45s
- 4714cargo clippy --workspace -j 6queued #1
- 4715xcodebuild -scheme App testqueued #2
Agents are fast. Your laptop is not.
Everything starts at once
Four sessions each run a full Rust test build. Memory fills, swap thrashes, the desktop stops responding.
Timeouts turn into retries
An agent's tool call gives up after ten minutes, so it starts the same build again on top of the first one.
The spare machine sits idle
The old desktop or the Mac on the shelf has cores and RAM nobody uses, because getting work there means SSH scripts and copied folders.
Nobody knows what ran
Which agent started that 45-minute build? Did it pass? How long does it usually take? The answer is scattered across terminal scrollback.
From one command to a result
The agent submits
loadtable run --who NAME -- <command>from the CLI, orsubmitthrough the MCP server. It gets the job id straight away.Admission decides when
Each machine admits work by real memory, CPU and disk pressure, queue class and slots, so jobs start when they can finish, not when they are typed.
Placement decides where
--anywherepicks the machine that can start soonest,--peernames one,--pinkeeps it local. Device jobs stay with the device.The checkout travels, not the repo
Only the commits and edits the worker lacks are sent, over an encrypted peer-to-peer link between paired machines. No SSH, no open ports.
The log streams back
Output arrives live with an estimate from past runs of the same command.
runexits with the job's own exit code.Outputs come home
--fetchbrings named files, such as an APK, back into the checkout once the job ends.Everything is recorded
Who, what, where, how long, exit code, full log, and a tamper-evident audit log. Searchable later with
loadtable logsandlog-search.
Built for Rust, Gradle and Apple builds
Warm caches on every machine
sccache for every cargo build, each checkout's target/ on a cache disk, a shared Gradle home and a disk reserve that refuses jobs before the disk fills.
Fair across vendors
Claude, Codex, Cursor and pi agents share one queue. --who names each one, and queue classes let a blocking fix go ahead of background lint.
Estimates you can plan around
Per-command timing history, split by warm and cold builds, gives queued and running jobs an estimate and flags the build that is running far over its usual time.
House rules, enforced
A per-repo run policy defines suites, caps -j and refuses unnamed broad test runs with the command to use instead, rather than hoping agents read the docs.
Phones, one at a time
--device SERIAL gives a job sole use of a test phone. Personal devices can be excluded outright.
Made for agents to read
An MCP server, a fixed one-line result at the end of every run, --detach for long jobs and clear "wait on job N, do not resubmit" messages.
Small teams with real hardware
A good fit if you
- run two or more coding agents at the same time
- build heavy things: Rust workspaces, Android with Gradle, iOS and macOS apps
- have a second machine: an old laptop, a desktop, a Mac mini or a Mac for Apple builds
- mix agents from different vendors and want one queue for all of them
- want to know afterwards what ran, where, and whether it passed
Not what you need if you
- run one agent on small projects that build in seconds
- already send every build to cloud CI or a build farm
- need a sandbox for untrusted code; jobs run as your user
- want to split one compile across machines, like distcc or Bazel remote execution
- run a fleet of servers; this is for a handful of personal machines
Next to the tools you have
These move whole sessions or single compile steps. LoadTable schedules the heavy commands underneath them, so it works alongside all of them.
| Tool | What moves | Shares resources between agents | Multiple machines |
|---|---|---|---|
| Remote agent sessions | The whole agent session | No, each session builds on its own | Yes, one session per seat |
| Vendor cloud agents | The whole session, to vendor machines | No | Vendor machines only |
| Single-machine command queues | Nothing; commands wait their turn | Yes, on one machine | No |
| distcc, sccache-dist, Bazel RE | Single compile steps | Not agent-aware | Yes, with build-system setup |
| LoadTable | Heavy commands: builds, tests, device runs | Yes, by pressure, slots and queue class | Yes, your own paired machines |
Early, and used every day
Shaped by written reports from the agents that use it on real projects.
- Linux laptop with Linux and macOS workers
- Queue, admission, queue classes, estimates
- Peer sync, log streaming, fetching outputs
- Build caches, MCP server, desktop window
- Showing each machine's exact build
- Moving a waiting job when another machine frees up
- A Mac worker that goes to sleep
- Emptying idle caches automatically
- GPU and file requirements for placement
Tell your agents in one paragraph
Install on each machine, pair them once, then paste this into the repo's AGENTS.md or CLAUDE.md.
Every build and test goes through LoadTable: loadtable run --who YOUR_AGENT --anywhere -- <command> --anywhere picks a free machine, --peer NAME picks one, --pin keeps the job on this machine (GUIs, dev servers). Sessions with MCP can use the loadtable tools instead. Check `loadtable list --active` before starting. If a call times out, query the printed job id; never resubmit. Name test targets: cargo test -p X --lib FILTER.