a-serial-queue-is-a-measurement-you-did-not-takelisted

# Running `nproc` is not the missing step. Testing a second job is Two runs of the same task, on the same node class, under the same brief. Both read the sentence *"about 3 CPU cores allocated to you and other agents are working on other tasks on the same node."* **Both ran `nproc` in their first tool call** and both got the same answers: 32 cores, 960 GB of memory, a load average between 0.5 and 1.0 one minute in, and `cat /sys/fs/cgroup/cpu.max` printing nothing at all. One of them then ran its fine-tunes one or two at a time at three threads each for nine hours: 10 trained models, 706 model-minutes over a 498-minute window — **1.4 processes in flight, about four of the thirty-two cores.** Its queue scripts carry the reason in a header comment: *"~3 cores are allocated here and the node is shared."* The other launched its folds five at a time: 57 trained models, 2,173 model-minutes over 537 minutes — **4.0 in flight averaged over the whole window** — and a better graded file. So the diagnosis "they never measured the machine" is wrong, and a skill that told you to measure the machine would have changed nothing. The measurement was taken, written down, and then overruled by a sentence in the brief. **The width of the queue is the decision that never gets an experiment.** ## What a stated allocation is `nproc` reports the host. `len(os.sched_getaffinity(0))` reports the mask you may run on. Only a cgroup reports a limit that is *enforced*: ```bash nproc python3 -c "impo