Train at Home troubleshooting: stopped overnight, stuck queue, no routable peers

Most Train at Home symptoms that look like a failure are either expected behavior the official UI never explains, or a known cause you can read straight out of the CLI log. This guide goes symptom by symptom, grounded in what the log and the official docs actually say — not guesses about what Macrocosmos's backend is doing internally.

"It stopped overnight"

This one is expected, not a bug. The official FAQ is explicit: "Training stops automatically. Nothing continues running when the app is closed or your computer goes to sleep." Train at Home holds no power assertion of its own — if your Mac slept, training stopped the moment it did, and needs a keep-awake method to survive an unattended run. See the keep-awake guide for the exact caffeinate/pmset setup, and the optimal setup guide for the full checklist.

Queue position climbing instead of falling

If your position shows ▲ (rising) instead of ▼ (falling), something re-registered you. Restarting the official app — even to "fix" a number that looked stuck — sends a fresh registration request, and the orchestrator answers with a brand-new queue id at the current back of the queue. The fix is simply to stop restarting it: leave it running and the position drops on its own. See the queue position guide for exactly which log fields to watch.

Stuck on "confirmed" for a long time

confirmed is a registration status, not a stall. Per this app's own parser (built from watching real registration responses), the lifecycle is queued → processing/confirming → confirmed → succeeded. confirmed specifically means the app is still waiting for a layer slot to open up — it can sit there for hours before succeeded arrives and real training begins. It is not evidence anything is broken; there is simply no published guarantee on how long that wait can take.

An orchestrator error that lost your place in line

Register-status calls occasionally fail server-side. In one observed case, /miner/register/status answered with 500 three times in a row; the app then re-registered with a brand-new queue id, starting again from the back. This is an orchestrator-side error, not something you caused, and there is no local setting that prevents it — if you see a burst of 500/503 responses in the log around the time your position resets, this is the most likely explanation. It happens rarely enough that if it recurs constantly, it is worth reporting to Macrocosmos rather than assuming your own setup is at fault.

Persistent "No routable peers" warnings

A line like No routable peers for layer-<N> (activation <uuid>): 0 node(s) matched means the app couldn't find a peer-to-peer partner for one specific data transfer at that moment.

The network and ports guide covers what you can check locally (lsof -nP -i, the "Registered with P2P node ID" history) and what avoiding a VPN as a general precaution can rule out.

Dropped back to the queue after training

Going from actively training straight back to the queue, with no restart on your part, is a real pattern this project's own fleet-monitoring tools watch for (internally: a working → queued transition between two reports). What causes any single instance of it isn't documented publicly by Macrocosmos, so this guide won't speculate about why the orchestrator reassigned that slot. What's known: it's a normal state the miner can recover from on its own, the same way a restart does — there's no indication it's a punitive or permanent state, just a slot that changed hands.

Work always shows "idle"

This is expected until you actually reach the front of the admission queue and get assigned a layer — idle simply means you're past registration but haven't been handed work yet. It resolves on its own once assignment happens; it isn't something to fix.

A speed test result that looks alarmingly low

The miner's built-in speed test result depends heavily on which server it happens to pick, not on your actual line. A documented same-line, same-afternoon comparison found 995 Mbps down on macOS's own networkQuality against as little as 13.8 Mbps from the miner's own test later that same afternoon — purely a server-selection artifact. Before concluding your connection is the problem, compare against networkQuality as described in the speed test guide. A run affected by this can also coincide with the orchestrator errors described above, since a slow-looking registration attempt and a 500-series response can land close together in the log.

When to just wait

Several of the symptoms above — a long confirmed wait, an idle work status, a single "no routable peers" line, a one-off register error — are ordinary parts of the process, not failures. The one genuinely counter-productive action across all of them is restarting the official app "just in case": it's the one thing in this list that reliably makes your position worse.

Checklist

1. Confirmed the official app is actually running and its log is updating (not ⛏ off).
2. If it stopped overnight, set up a keep-awake method — see the keep-awake guide.
3. If your position is climbing, stop restarting the app and let it recover on its own.
4. Treat a long confirmed phase and an idle work status as normal, not broken.
5. Note any 500/503 burst around a position reset — it's an orchestrator-side event, not yours to fix.
6. For "no routable peers", read the network guide before assuming something is misconfigured.
7. For a suspiciously low speed test, cross-check with networkQuality per the speed test guide.
8. Install subnera (or subnera hub for several Macs) to see these signals without re-reading the raw log every time.

If none of this matches what you're seeing, the optimal setup guide is the best starting point for a full review of your setup.