Darkbloom “machine_busy” or “your machine is at capacity” while the Mac is idle

Updated September 29, 2026

Short answer: machine_busy comes from Darkbloom’s coordinator, not from your Mac. It means the coordinator’s own record says your Mac has no free slot for that model, and that record can say “full” while the Mac sits idle. Providers reported it again and again in late September 2026, mostly on Qwen 3.6 35B. Darkbloom hasn’t published a cause for those reports. Below is what the message means in Darkbloom’s open-source code (links at the end), what you can check and what to try.

Where the message comes from

You only see machine_busy on a self-routed request: one sent with the header X-Darkbloom-Route: self, or with a key set to use only your own Mac. Darkbloom’s API docs list it as a 429 reply with a Retry-After header, sent when your own machine is at capacity.
There are two versions. “your machine is at capacity — retry shortly” means the coordinator’s queue was already full. “your machine is at capacity (timed out waiting for a free slot) — retry shortly” means the request waited in the queue and no slot opened in time.
Other customers’ requests never show you this. When the coordinator thinks your Mac is full, it just sends their requests to another Mac, so the same problem shows up only as missing paid work.

Why an idle Mac can look full

Before sending a request, the coordinator checks whether your Mac has room for it. Darkbloom’s routing docs list three capacity checks, and any one of them can mark an idle Mac as full:

Concurrency (no_headroom): the Mac, or the model’s slot, already has as many requests as it is allowed.
Token budget (free_memory): the coordinator counts each request’s prompt plus its max_tokens, the most it may write, against the token budget your Mac reports. A request that asks for a very large max_tokens can fill that budget even if it will use far less.
Recent refusals (capacity_cooldown): after your Mac turns a request away for capacity, the coordinator stops trusting the budget it reports until a new heartbeat shows room and a request is accepted, or 5 minutes pass. Five capacity refusals within 60 seconds, with no success in between, also pause your Mac for that model for 2 minutes, doubling each time up to 10 minutes.

What providers reported on Qwen 3.6

In the Darkbloom Slack in late September 2026, several providers serving Qwen 3.6 35B saw machine_busy on self-routed tests while the Mac was idle and its local endpoint answered normally. Paid work came in bursts, then stopped for up to an hour, and a self-routed nudge didn’t help. Providers asked Darkbloom to check how the coordinator tracks free capacity; no answer had been posted by September 29. Separately, a provider’s analysis of Qwen 3.8 27B (GitHub issue #1250) counted 3,145 “429” replies in 16,105 requests over one day and points at the prompt-plus-max_tokens reservation above. Darkbloom has not confirmed that this is the cause, and an open Darkbloom issue (#846) is looking at where the coordinator’s estimates and the Mac’s own admission disagree.

What to check

Run darkbloom status. If the model is listed as Not loaded, Preload skipped or Cold load blocked (memory), it isn’t ready to take a request.
Run darkbloom doctor and fix any warning under model fits in RAM, recent model load or competing inference. Another AI app holding memory shrinks the budget your Mac reports (see running Ollama next to Darkbloom).
Give it 10 minutes. In Darkbloom’s code the budget distrust ends after 5 minutes and the longest capacity pause is 10.
If paid work still doesn’t arrive, run darkbloom stop and darkbloom start, as for any routing stall, and let the start finish.
If one model keeps doing this, serve a different model for a while and check the Darkbloom Slack for others seeing the same.

Does it cost base rewards?

No. Base rewards need only a loaded model and a steady connection, so they keep arriving. What you lose is paid requests for that model while the coordinator thinks your Mac is full.

Sources

API contract (machine_busy, 429, Retry-After): github.com/Layr-Labs/d-inference/blob/master/docs/reference/api-contracts.md
Routing gates and capacity signals: github.com/Layr-Labs/d-inference/blob/master/docs/architecture/routing.md
The two machine_busy messages: github.com/Layr-Labs/d-inference/blob/master/coordinator/api/dispatch.go
Token-budget check (prompt plus max_tokens): github.com/Layr-Labs/d-inference/blob/master/coordinator/registry/scheduler.go
Provider analysis of 429s on Qwen 3.8: github.com/Layr-Labs/d-inference/issues/1250
Coordinator estimates vs provider admission (open): github.com/Layr-Labs/d-inference/issues/846

How BloomGauge helps

BloomGauge shows live whether paid work is reaching your Mac and what it earns each hour, and its network view shows demand and warm Macs per model, so you can tell a quiet model from a Mac that has stopped getting work.

Download BloomGauge, free for Mac

Questions

What does machine_busy mean in Darkbloom?

It is a 429 reply from Darkbloom’s coordinator to a self-routed request: the coordinator’s record says your own Mac has no free slot for that model. It comes with a Retry-After header. It doesn’t mean the Mac itself refused the request.

Why does Darkbloom say my machine is at capacity when it is idle?

The coordinator decides from its own view of your Mac: its concurrency limit, a token budget that counts each request’s prompt plus max_tokens, and a short pause after capacity refusals. Any of these can mark an idle Mac as full. Check darkbloom status and darkbloom doctor, wait up to 10 minutes, then stop and start the provider.

Does machine_busy stop Darkbloom base rewards?

No. Base rewards need only a loaded model and a steady connection. You lose paid requests for that model while the coordinator thinks your Mac is full.

Updated 2026-09-29. Still stuck? Ask in #bloomgauge on the Darkbloom Slack or contact us. BloomGauge is independent and not affiliated with Darkbloom.