Skip to content
Menu

Reading your Train at Home training stats: layer, tokens per hour, passes and steps

Verified with T@H 3.7.0 on macOS 26.6.2 (October 4, 2026)

Published October 4, 2026 · 6 min read

Once your Mac is out of the queue and training, subnera stops showing a queue position and shows a short line such as L1 · 358k tok/h. This guide explains what each part of that line measures, where the same numbers appear in the menu, and how they look in subnera hub. The values used below are examples, not targets. If you are still waiting for a slot, read the queue position guide first.

Everything comes from the log

subnera does not measure your Mac's hardware. It reads the CLI log the official app writes and works out the figures from the training lines in it. So every number below is only as good as what the miner logs, and a number can be missing when the log has not said enough yet. Nothing here is an official Macrocosmos figure.

The menu bar line

L1 · 358k tok/h has two parts:

  • L1 is your layer. IOTA splits one large model into layers spread over many machines (see what IOTA Train at Home is). Your Mac is assigned one layer and works only on that slice. L1 means layer 1, and the number comes from the layer= field of the miner's training lines. It says which slice you hold, not how well you are doing.
  • 358k tok/h is tokens per hour, the rate at which text tokens go through your layer. k means thousands and M millions, rounded down.

While the rate is still being measured, the line reads L1 · …. If the layer is not known yet, it reads working.

How the rate is built

Three figures feed it.

Tokens per pass. Each time the miner receives an activation, the log shows its shape, for example torch.Size([4, 800, 32]). subnera multiplies the first two numbers, batch by sequence length (4 × 800 = 3200 here), and treats that as the tokens carried by one pass. The third number is ignored. This is an example shape, not a value to expect.

Passes per hour. A pass is one activation completing its forward step in your layer. subnera counts only forward passes. The backward pass revisits the same tokens, so counting both would double the figure. Passes land roughly every 15 seconds on a working miner, according to the code's own notes.

Tokens per hour is passes per hour multiplied by tokens per pass.

The rolling window

A single read of the log is far too short to give a rate, so subnera accumulates passes between refreshes, skips duplicates by activation id, and keeps a 20 minute window. The rate is the number of passes in the window divided by the time actually observed, which is capped by the window.

Right after the app starts, or after your Mac begins training, the rate is withheld until there are at least 3 passes spread over at least 3 minutes. Until then the Details menu shows measuring… (N passes so far). Once it has measured, the row reads like 358k tok/h · 112 passes/h (over 18 min), where the last part is how long the app has been watching, up to 20 minutes. These example values are not a benchmark.

Optimization step

The Step row is the number from the miner's Optimization step #N line. It counts the optimizer updates the miner reports. It restarts each epoch, so treat it as a progress counter inside the current epoch, not a lifetime total. subnera does not turn it into a rate.

Run, epoch and heartbeat

The miner also logs the orchestrator's replies to its heartbeats. subnera shows the latest as Run (the run id) and Epoch, with the server-side phase next to it. These come from the orchestrator's answer, not from your Mac's own work, so they can lag the training lines slightly.

GPU memory

If the log contains a line such as GPU memory usage: <used>GB / <total>GB, the Details menu shows a GPU mem row with the used and total figures. A shorter form reports only the used amount. If the miner does not print these lines, the row simply does not appear. The code does not tie this figure to the rate.

Backend counters

When there are any, the Details menu adds a row like Backend: 3×503 queue_state, 0×404. It counts two kinds of error lines in the log tail:

  • 503 queue_state: the orchestrator answering that it has no handler for register.queue_state. The same error is why the official window cannot show your queue position, so it is expected for a queued miner.
  • 404: an orchestrator endpoint returning not found.

The code counts them but does not judge them. A few of either, while everything else looks normal, is not by itself a sign of a problem. If the counters keep climbing while the phase is stuck or the rate is empty, look at the troubleshooting guide.

The same figures in the hub

If you enrolled a Mac in subnera hub (see the fleet hub guide), each machine card shows Layer, Tok/h, queue position and network speed, taken from the report subnera sends. The fleet header adds up the Tok/h of the machines that are online. A machine page draws a Tokens / h history chart, over 6 hours, 24 hours or 7 days, so you can see how the rate moves with a restart, a layer change or a network problem.

Reading it sensibly

  • Compare a Mac with its own past, not with someone else's. What counts as a normal rate depends on the Mac and on the layer it holds.
  • A drop in tokens per hour with the same layer is worth a look at the network and at the setup guide. A change of layer or of batch shape changes the figure by itself.
  • subnera is unofficial and not affiliated with IOTA, Macrocosmos or Bittensor. These figures describe throughput, and this guide draws no link between them and rewards. For payouts, see the rewards guide.

Want to see this on your own Mac?

subnera shows the real queue position and phase in your menu bar.

Install subnera