v0.13.0

Waiting costs next to nothing now: a poll that finds the queue unchanged keeps its last decision, and jobs of a kind are judged once, so 160 waiting jobs take 0.1 cores in all instead of 4. Where the jobs record the same limits, the rule now starts every job that can start without risking one.

Changed

• Waiting jobs use far less CPU. The rule depends only on the jobs and the CPU outside the queue, so a poll that finds the database as the last one left it keeps the last decision (whether the jobs are alive, and how old the CPU measurement is, are still checked on every poll). And two jobs with the same amounts and limits have the same condition, so one start stands for every later one of its kind: judging a job costs as many steps as jobs times kinds, not pairs of jobs. Behind one job holding an 8-core machine, the waiting processes used in all:

  Waiting jobs	0.12.0	0.13.0
  40	0.14 cores	0.006 cores
  80	0.65 cores	0.018 cores
  160	4.05 cores	0.10 cores

• No job waits that could start without risking a limit, where the jobs record the same limits and start with their weights. Jobs may end and leave at any time, so any set of the jobs ahead that fits within its members' limits may be what runs when a job ahead starts; the rule now checks exactly that, and a test compares it with a search of every such set. Before, a dimension that could not bind on its own (often CPU) was counted at its sum even where the sets that fit on another one (a resource) could not use all of it: 0.1% of the decisions in a random simulation, 1.3 to 2.5% of the mean wait.

• A job that cannot run beside a start by its own limit no longer holds others back. Where repositories record different capacities, a running job whose smaller capacity rules out a waiting job's start beside it was still counted beside that start.

• The rule changes were reviewed by Codex (GPT-6-Astra). What it found in versions before this one, among them one that let a job past a limit and one that made status cubic in the line, is fixed and covered by tests.

The decisions are otherwise the same, and so are the promises: no job is delayed by jobs that got in line after it, and the running jobs never use more than the smallest limit any of them records.

Upgrading

The queue file stays queue-v4.db, and 0.12 and 0.13 keep the limits together in it, so agents can move to 0.13 one at a time.

mise use -g github:ktanaka101/loadmaster@0.13.0

Or download the archive for your platform below: macOS (Apple Silicon and Intel) and Linux (x86_64 and arm64, statically linked).