Skip to content

open source · apple silicon · MIT

Batch AI jobs
across idle Macs

A job queue, lease scheduler, and worker CLI for latency-tolerant work — embedding, OCR, classification. Every worker runs a whole model and takes a shard of the queue. Machines are assumed unreliable; tasks are reassigned when they vanish.

npm i -g macbatch
252,686
items / hourmeasured, one Mac
0
failed tasksacross every published run
600s
lease, then reassignworkers may die freely

Not a live inference API. If you need low latency, use a hosted provider — the cost model shows where this does and does not pay off.

What it does

You have Macs sitting idle. macbatch turns them into a pool that chews through work where latency does not matter — re-embedding a corpus after a model change, OCR on a document backlog, classifying a table of records overnight.

It is three moving parts: a control plane that holds the queue, worker processes that lease shards of it, and Ollama on each worker actually running the model.

System architectureone control plane · N workers · any network
public internet →clientmacbatch benchor your scriptPOST /v1/jobssubmit itemspoll → resultscontrol planeFastAPI · one processjobs → shards → taskspending · leased · done · failedlease table + reclaimexpiry 600s → back to pendingworker registryheartbeats · stale after 60sSQLite · WAL · ~/.macbatch/control-plane no scheduler thread — leases reclaimed on request worker · your Macmacbatch serve · localhostOllama :11434worker · friend Macmacbatch serve · Cloudflare tunnelOllama :11434worker · any Macmacbatch serve · HTTPSOllama :11434 workers pull ⟵ lease · heartbeat · complete_batch
Workers pull. The control plane never opens a connection to a worker, which is why a friend's Mac behind home NAT can join with nothing but an outbound HTTPS connection.

What it is not

A live inference API. There is no streaming, no per-request SLA, and a task can be retried on a different machine at any moment. If you need a completion in under a second, use a hosted provider — that is a different product with different physics.

The honest numbers

The largest measured win so far is not distribution, it is batching: packing items into shards cut the same 500-item job from 20.2s to 7.1s on one machine. Adding a second Mac over a tunnel gave only 1.18×, because greedy leasing lets the fast local worker drain the queue first.

Embedding throughput500 items · nomic-embed-text · 2026-08-03
050k100k150k200k250k1 Mac · unsharded20.158s wall · 0 failed 89,2962 Macs · unsharded17.11s wall · 0 failed 105,2001 Mac · shard_size=327.123s wall · 0 failed 252,686items / hour →
All three runs completed 500/500 items with zero failures. Artifacts and methodology are under Benchmarks.

Start here

Looking for the hosted pool with signup, dashboards, and managed machines? That is a separate product — see macbatch cloud.

MIT licensed. Every benchmark on this site is reproducible with macbatch bench.