Nightshift benchmarks: what the machines finished, and what they didn't

The short version

Nightshift turns a machine you already own into an overnight production line. It runs many attempts at a job across several local models, clusters and judges the results, checks them, and records whether it was accepted. On a DGX Spark the whole fleet stays in memory and the machine has run for weeks. Its log holds 361 jobs, 5 361 landed attempts and 1 828 signed receipts, but only 5 of 104 recorded outcomes are accepted. The main bottleneck is judging: 8 % of shortlisted candidates were ever scored. On a 16 GB Apple M5 the runtime is solid: 301 of 301 jobs in a 3-hour soak, and after the defects found live were fixed, 24 of 24 catalog-fleet jobs completed with 24 of 24 correct winners. The limit there is memory. With the owner's apps open, about 8.6 GB is available to models, so larger fleets rotate models through memory and each job takes minutes, not seconds. 14B models run only when about 11 GB is free. The weakest link on both machines is the step after generation: judges abstain or are missing, the product sometimes picks a worse answer than one it already has, and it cannot yet state a cost in electricity per accepted result. Every number below comes from a job log, a benchmark harness record or a test report. Each one names the machine it was measured on, and the runs that failed are counted too.

At a glance

1. What Nightshift is

Nightshift is a local AI production control plane. It sits above the runtimes you already have (llama.cpp for language; whisper, stable-diffusion.cpp, ACE-Step and TTS engines for media) and decides what runs, when, on how much of the machine, and whether the result is good enough to keep (NIGHTSHIFT.md, "What it is").

• Jobs, not prompts. A job is durable work that checkpoints and survives crashes and pauses. Five kinds ship: best_of_n (race many attempts, cluster, judge), deliberate, batch, bulk (the same work over every file in a folder or corpus) and app_stream.
• Fleets and lanes. A fleet is a named set of complementary local models sized to the machine. Each model runs in a lane with a production duty: race (explore), judge, verify, generate (media) or embed (the "scribe" that reads attempts for search and clustering). The catalog holds 203 fleets: 130 text and 73 media (Fleet catalog v2.6).
• Many attempts, then selection. Lanes race on one job. Every finished attempt is kept. Attempts are clustered into families of similar answers, and a judge panel or rubric picks among them. Losing answers are compared with the winner and can be reclaimed.
• Checks. Artifact validators (HTML, code, Markdown, JSON, SVG, CSV), a headless-browser sandbox that opens generated web apps and presses their buttons, an NLI contradiction guard, and byte-level media gates (the file decodes, is the right size, isn't silent, frozen or noise). A check that could not run is recorded as not_run and never counts as a pass.
• Outcome Contract. Before a night spends compute it commits to what a usable result is. Afterwards it answers in one of three words: Accepted · Not accepted · Not yet decided.
• Synthesis and continuation. Cluster reports and a night report summarise agreement and disagreement. Continue run lets a curator model fold last night's consensus into tonight's attempts.
• Makes. Media is a separate production plane: 42 transforms produce stills, clips, narration, music, transcripts, documents, decks and apps. A make is tracked separately from an attempt.
• Receipts. Every routed answer carries a signed receipt.
• Two shifts. By day the box is an OpenAI-compatible endpoint for your other apps (the Depth posture). In the quiet window, with no interactive traffic for ten minutes, it switches to Swarm and the night gets the machine. The first interactive request drains jobs back to one lane.

Where it runs. On a DGX Spark (128 GB) a fleet of 27–32B models stays resident and races simultaneously. On an Apple Silicon Mac the same product runs on Metal inside one signed-in user's app. The admission gate works from live free memory, because the owner's other apps compete for the same unified memory. A fleet larger than the Mac rotates: its lanes are loaded in batches, and every attempt is kept across the switches (Decisions D5, D10, D11). The Mac port adds a 16 GB starter kit (Phi-4-mini + Qwen2.5-Coder-3B + nomic, all resident, D12), a "Refactor fleet to fit" option for members that cannot load at all, planning against the memory a seat can get now (D21), and a keep-awake assertion while work runs (D22).

2. How we measure

Why not tokens per second. Tokens per second tells you how fast a model writes. It says nothing about how much finished, correct work the machine produced, or whether any of it was worth keeping. We count jobs completed, attempts landed, winners that are actually correct, artifacts that actually run, judge coverage, and time per job. Failures stay in the denominator (DGX page, intro).

The Mac fleet harness (bench/fleet-bench.mjs, Mac bench §4.6). Each installed catalog fleet is materialised exactly as the UI does it (using the live device profile), saved and activated. It then runs three best_of_n jobs with n = 4:

Memory is sampled every 5 s. A job is cancelled after 10 minutes with no new attempt (stalled_cancelled). "Winner correct" scores the attempt the product crowned, not the best one it had. "Candidates correct" scores every attempt.

Caveats that matter.

• The suite is small and on the easy side. 82 % of all candidates were correct. It measures whether the runtime delivers a fleet's ability, not how capable the models are. The fact scorer is a regex rule and was re-checked by reading. The §7 runs (fleets5–7) used the harness's built-in fact check, which is stricter than v2.
• The Mac is a working laptop, not a lab. It is an Apple M5 (4P + 6E cores, fanless) with 16 GB and macOS 26.4. Slack, VS Code and WindowServer were open throughout; Chrome was closed for the fleet runs. The daemon's safe capacity is 11 807 MB, but the live gate granted about 8.6 GB with nothing resident. Swap sat at 2.6–4.9 GB (Mac bench §1, §3). Runs were on AC power. §4 ran under caffeinate; §7 used the app's own keep-awake instead. Because free memory moves from run to run, compare magnitudes, not single seconds.
• The DGX numbers are read from one production box's job log (the public benchmarks page). They cover a month of fleet experiments, not a controlled suite. The substrate rows (prefill, decode) were measured with other GPU tenants resident; they are working-day numbers, not a clean-room best case.
• The two machines ran different models and different work. The comparison in §3.8 sets their capabilities side by side; it is not a head-to-head score.
• Token rates in the fleet tables use the product's estimated token counts (characters ÷ 4), so they are indicative only (CQ-7).

3. Results

3.1 Mac: every installed catalog fleet, main sweep vs final re-run

Main sweep on build bd0dfbcf (2026-09-26 00:51–06:17Z). The eight fleets hit by defects were re-run on build 64ee1ffa (08:33–10:45Z). Plan mode is the job-level plan the daemon drew. Times are the median wall time per completed job.

Candidates correct: 111/133 (83 %) in the main sweep and 76/95 (80 %) in the re-run (Mac bench §4.6, §4.8). None of the 20 main-sweep failures was a model failure. Fifteen were a job waiting its whole life on a 14B batch that live memory never admitted (F-14). Five were the end-of-job curator lane being reloaded behind the fleet's back (F-13). percept-lite produced 1 of 4 attempts per job because its licence-gated Liquid reader was correctly refused (F-9). All six wrong winners in the main sweep were small (1–4B) models answering the fact or extract prompt. The two wrong extract winners were the 1B MiniCPM5 keeping the time in the date field, a format slip rather than wrong data.

3.2 Before and after the live fixes

The Mac campaign followed one rule: find the defect on the installed app, fix it in source with a regression test that fails without the fix, rebuild, reinstall, and measure again. Over the benchmark campaign that produced F-1…F-17 plus CQ-1 (Mac bench §0, §7; Test report §14i–j). The release-gate rounds before it had already found and fixed 31 others (Handbook §1.1).

The agentcode-lite intermediate builds are worth reading honestly. The first live-memory build took 485 s and the second 655 s, because free memory fell after each plan was drawn (swap rose from 2.3 to 3.5 GB). Two further splits were needed before the final 273 s (Mac bench §7.1). §7.1 lists the before build at 2/3 winners correct under the original fact scorer. Under the v2 scorer used everywhere else in this document, it is 3/3.

3.3 Concurrent vs rotated, small vs 14B, and which models won

Concurrent vs rotated on 16 GB (computed from raw bench/fleets3, fleets4, fleets7):

On the Mac, time goes to memory, not inference. In one pre-F-12 agentcode-lite job, generation took about 7 s of 400 s. The first batch waited 265 s for macOS to push other apps into swap. Batch switches then cost 66 s and 37 s (Mac bench §3, F-12). With a quiet seat, a 1B-to-1B switch costs 1.8–2.5 s (Test report §14d). The planner's first answer was to pack batches to the 11 807 MB capacity. That was wrong for a laptop whose owner is using it, and the fix (D21) plans against the memory a seat can actually get now.

Small vs 14B models. Every 14B lane needs about 11.4 GB at its packed context. None was admitted while 8–9 GB was free. When free memory rose to 11 GB (around 06:00Z), night-core ran all three jobs, and its Qwen2.5-Coder 14B and R1-Distill-Qwen 14B lanes won them (Mac bench §4.6). In the re-run, the "lite" fleets that contain a 14B member finished all their jobs, but the 14B batches were deferred and the four attempts were filled by the 1–8B lanes that fit. On a 16 GB Mac with the owner's apps open, those fleets run as their small-model subsets (Mac bench §4.8).

Which models won (computed from raw harness records, 61 completed jobs in fleets3 + fleets4). A win depends on which lanes a fleet contains and which ones fit, so this table shows where wins came from; it is not a model ranking.

By family, Llama won 23 jobs, Qwen 16 (15 plus 1 for the R1 distill), Phi 12, MiniCPM 6 and Pixtral 4. Adding the §7 runs (fleets5–7, 12 more jobs) moves Qwen2.5-Coder 7B to 19 wins and gives Liquid LFM2.5 8B-A1B 2 wins from 3 jobs. The one clear laggard is VibeThinker 3B: it was in 24 jobs, won none, and was right on 41 % of code and extract attempts. Selection never crowned it, which is the right outcome.

3.4 Selection and judging on the Mac suite

Computed from raw bench/fleets3 + fleets4, 61 completed jobs:

In 58 of the 61 jobs at least one correct candidate existed. The product picked a correct one in 55. In the other three (starter-16 fact, asr-factory fact and extract), a correct answer was in the pool and a wrong one was crowned. But the judge contributed almost nothing to these picks. Only 6 of 61 jobs had a panel that scored anything, and in all six the judge was one of the racers judging its own fleet's work. Four of those six picks were correct. The rest ended with the panel errored (22, the projector-as-judge defect F-11, since fixed), no_judge (21, fleets without a judge lane), unparseable (9, including an OCR model seated as judge) or panel_too_small (3). When the judge abstains, the winner is chosen by the cluster fallback, which is in effect a consensus of the attempts. On this suite that was enough. On harder work, where the majority can be wrong, it will not be (see §3.9).

3.5 Mac platform and runtime

3.6 Media on a 16 GB Mac

One weakness surfaced here that later sections return to. Structural gates cannot see content. A 768² SD-Turbo image with three fused foxes passed, and before F-4 an "edit" that painted the words "Make it Night" onto an unrelated picture was marked verified (Mac bench §2.3–2.4).

3.7 DGX Spark: real nights

All numbers in this section come from the public benchmarks page (nightshift-landing/benchmarks.html), read from the job log of one working DGX Spark, unless another source is named.

One published night, 7 → 8 September 2026 (job_mtrtl3j401, "a compelling 3D landing page, one HTML file", three local lanes, local-only):

Trust funnel (all nights):

Of the 94 that looked valid but did not run, 74 threw uncaught errors, 15 had missing handlers, 4 timed out and 1 rendered blank. An earlier controlled measurement on the same box found the same shape: of 143 static-eligible HTML artifacts, 50 (35 %) did not run. Running the sandbox cost almost nothing: a per-artifact p50 of 211 ms, and 0.5 % decode sag on the coder lane with a 4-browser pool (24 % with 16) (reports/sandbox-measure-2026-09-07.json).

Intelligence multiplexing. Four real races of 250–300 attempts across 4–8 lanes found 25–37 distinct solution clusters, and each was still finding 3–9 new clusters in its final 50 attempts:

Prefill vs decode (17 September 2026; llama.cpp 0865990, flash attention, KV q8_0, prompt cache off):

Running one, two, then three lanes at once gave aggregate decode of 6.7 → 7.0 → 9.7 tok/s: three independent approaches for about 1.45× the throughput of one stream, with each seat at half speed or less. Across every request routed on the box, median latency was 36.8 s and p95 5 m 7 s. The page says it plainly: "That is not an editor experience." An earlier review explains the cost on the provider path. A direct lane answered in 1.0 s, while the full pipeline (planning, a 6-wide race, synthesis, a judge that was misconfigured at the time) took 27.3 s non-streaming, and 11.0 s after the fixes (reports/PROVIDER-LATENCY-REVIEW-2026-09-01.md §1, §6).

Two shifts. By day: 9 apps served from one endpoint, 1 455 app turns, 98 % routed to local models. By night: 44.3 productive compute-hours logged holding 100.8 lane-hours, 2.3 seats busy on average, a peak of 7 concurrent attempts, and 313 posture switches (128 into Swarm, 99 drains for interactive traffic, 86 at window close). A single 3B lane processed 299 of 300 corpus units in 5 h 35 m (53.5 units/hour, 1 failure).

Memory calibration. Across 35 calibrated models, the first footprint prediction was off by a median 17 %. Qwen3.8-27B was predicted at 21 131 MB and observed at 27 369 MB. Every model now carries its own measured safety factor. On the Mac, a resident 1B measured 1 568 MB against a 2 194 MB estimate (Test report §3).

3.8 DGX Spark vs Apple M5 16 GB

The honest reading: the Spark is the machine Nightshift was designed around. It keeps several strong, different models resident and lets them grind through a long night. A 16 GB Mac is a capable host for small fleets and for the runtime itself, but it spends most of a rotated job waiting for memory. It cannot hold the 27–32B models that produce the Spark's best work. The larger Macs the landing page lists (Mac mini M5 Pro, M6) have no field numbers yet. Their rows on the benchmarks page say "awaiting field run", and nothing here should be read as standing in for them.

3.9 Quality: from the content review to the latest runs

On 2026-09-23 a review read every job the Mac tests had produced (CQ review). That was a 302-job soak plus 41 live-gate jobs, 1 967 candidates in all, all from Llama 3.2 1B, judged by the same 1B.

Later results (after CQ-1, 25–26 September, 1–14B catalog fleets, v2 fact scorer): 31 of 37 completed winners correct in the main sweep, 24 of 24 in the final re-run, and 12 of 12 in the §7 runs.

Read this before/after carefully. Three things changed at once: the brief fix, the models (1B → 1–14B fleets of two to five families), and the prompts (a 150-word fact prompt → 80 words, plus an extraction task). The improvement cannot be attributed to CQ-1 alone. The review's controlled replay isolates the brief: the same 1B, same prompts, same temperatures wrote correct interval-merge code 1 in 12 times with the brief and 11 in 12 without (CQ review §2). The bigger models then remove failures no selector could fix, such as the 1B's invented history and "unified memory = RAM + disk".

What has not changed. Only CQ-1 of the eleven content fixes has shipped. Selection still has no eligibility gate. The judge protocol still scores position 1. A self-judge's single score can still read "accepted — supported". On the Mac suite, the product crowned a wrong answer in 3 of the 58 jobs that contained a right one. It got 55 right mostly by consensus, with no working judge (§3.4). On the Spark, 92 of 104 outcomes are "not yet decided", mostly because judges abstain. Selection and judging are the product's largest open quality problem on both machines.

4. Strengths

• The runtime is robust on a small, busy machine. A 3-hour soak ran 301/301 jobs and 1 806 attempts with 0 errors on a fanless 16 GB laptop running hot 60 % of the time, with the owner's apps open, through a real 15-minute sleep (Test report §14f). The numeric release gates passed in every round (7/7; 6/6 measurable in the first).
• Every catalog fleet that fits a 16 GB Mac now runs to completion with correct winners on the suite. After the live fixes: 24/24 completed with 24/24 winners correct, and 12/12 in the §7 runs (Mac bench §4.8, §7).
• Best-of-n adds value even without a working judge. Across 61 completed Mac jobs, 90 % of winners were correct against 82 % for a single random attempt. Code winners were 21/21 (§3.4).
• Search keeps finding new answers. On the Spark, four races found 25–37 solution families each and were still discovering new ones at attempt 250 (DGX page).
• Failures are counted, not hidden. Checks that could not run are recorded as not_run and never pass. The trust funnel publishes that 36 % of the static-valid apps it tested did not run. Judge coverage (8 %) and silent lanes (44 %) are published per run. A never-fit media request is refused by name in milliseconds (§3.6, §3.7).
• Honest memory behaviour. A lane that live memory will not admit waits (D10), and one that can never fit is refused or offered a refactor (D11). After F-12 the planner draws against what a seat can actually get, which cut agentcode-lite from 1 201 s to 273 s for three jobs (Mac bench §7.1).
• Local and private by default. $0.00 of cloud spend on the published Spark night; 98 % of 1 455 app turns routed to local models (DGX page).
• Upgrades are safe. Every Mac upgrade across the campaign preserved keys, manifests, calibration, jobs and models byte for byte, checked by hash (Test report §14a; Mac bench §5).
• Verification checks are cheap. A 4-browser sandbox pool cost 0.5 % of decode throughput on the Spark (sandbox-measure-2026-09-07.json). The NLI guard checked 256 pairs from a 215-attempt night in 22.7 s on CPU (NS-CE-BUILD-001-CP2-calibration.json).

5. Weaknesses and open problems

6. What the numbers say

What Nightshift is good at today. It is good at long, unattended runs of many attempts at work that can be checked. Code can be executed, JSON can be validated, apps can be opened and pressed, and facts can be compared against sources. There the runtime reliably lands every attempt, survives crashes, sleeps and memory pressure, keeps everything, and on a checkable suite picks a correct winner 90–100 % of the time. It is weakest where no mechanical check exists. Open-ended writing, strategy and media rely on a judge, and the judge is the least mature part of the system. On the Spark, that is why 92 of 104 nights end "not yet decided". The product is right to say so, but it means a person still does the final pick.

On a 16 GB Mac, expect a solid, well-behaved runtime and small fleets of 1–8B models. A fleet that fits resident answers a best-of-4 job in seconds. Larger fleets rotate and take a few minutes per job, depending on what else you have open. 14B models only take part when about 11 GB is free, which in practice means quitting other apps or running overnight. Speech in both directions, fast 512² stills and short music cues all work. Image editing and video do not. For overnight use, the keep-awake fix (F-7) matters as much as any model choice.

On a DGX Spark, expect three 27–32B models resident at once, many attempts per night, and search that is still finding new solution families at attempt 250. It is slow per token (6–8 tok/s decode, 13 s to first token on a 6k prompt) and cheap per night ($0 cloud). The result is a large, inspectable body of work with a trust funnel that tells you how much of it actually runs. It does not yet give a verdict you can rely on without looking.

What would change the picture.

1. Judging that works. Eligibility gates before selection, a position-shuffled judge protocol, an independent and larger judge, and an execution selector for code (CQ-2…CQ-6, CQ-10). This is the single change most likely to move the Spark from 5 accepted of 104 toward a useful acceptance rate, and to close the Mac's winner-vs-best-candidate gap.
2. Measured larger Macs. A 32–64 GB Mac would hold the fleets that rotate on 16 GB, and possibly the 27–32B models. Until someone runs one, the landing page's M5 Pro and M6 cards stay empty, as they should.
3. Media accepted by contract. Content-aware gates (a vision judge on stills, a listening pass on music) so that 468 renders can become accepted outcomes.
4. Cost per accepted result. A power meter and an amortisation input, so "cheap when you are sleeping" becomes a number.
5. A harder suite. The Mac suite is easy enough that consensus alone gets 90 %. A suite where the majority is often wrong would test selection properly.

Job modes

This report covers best-of-n jobs only. Every other job mode (the selectors, judge modes, diversity and budget, deliberate, batch, bulk, deadlines and stops, makes and repair, synthesis, continue, Methods, Auto, media autopilot and watchers) was measured separately, on a DGX Spark from 1 to 3 October 2026, with the Mac's modes campaign cited beside it: [Nightshift job modes](modes/NIGHTSHIFT_MODES_BENCHMARKS.md). Its headlines:

The two reports do not disagree on any figure. Where the modes report compares a mode with best-of-n, it uses its own best-of-n baseline, measured on the same fleet and fixtures. It does not reuse the numbers above.

The gallery

The benchmark folder that ships with this report (Benchmarks/) holds a single-file 3D gallery (index.html) and the best jobs generated so far, each an unmodified Nightshift export (GET /v1/jobs/{id}/export), unzipped and renamed in JOBS/. Opened from disk, the gallery draws the jobs as a night sky: every star is a job, coloured by task; the moons circling it are the models that raced for it, and the gold one won. Selecting a star shows the ask, the race, every candidate's answer side by side, the scores, the residency plan, what the job made, and a link to the job's full offline replay.

How the 22 jobs were chosen. For each catalog fleet, the harness's best job: completed, every planned attempt landed, the winner correct, the most candidates correct, the most model families racing, then the fastest (scores from ~/nightshift-build/bench/fleets*/*.json), plus the two media jobs whose outputs passed their gates. That is a selection of the best: 109 attempts across 22 jobs, all on one Apple M5 Mac with 16 GB of unified memory. The failures — the 20 jobs of the main sweep that did not complete, the wrong winners, the refused and failed makes — are in §3 above, and the media night keeps its one defective output (the F-4 edit), flagged, as evidence.

Methodology notes and sources

Machines

• Apple M5 Mac: 10 cores (4P + 6E), 16 GB unified memory, fanless, macOS 26.4 (25E246), Metal 4. Safe capacity 11 807 MB (floor 4 577 MB). Owner's session open throughout. Campaign dates 2026-09-22 → 2026-09-26.
• NVIDIA DGX Spark: GB10, 128 GB LPDDR5x, 273 GB/s, DGX OS 7.2.3 (Ubuntu 24.04), driver 580.173.02, llama.cpp 0865990, one server per lane. Job log from August to September 2026; substrate measured 2026-09-17.

Mac builds

• Final: DMG b56dfc81df9af01416e402e846df2a309c2875597ddd826354602a29d51525e6 (123 346 431 bytes), source 7deb1a3. Development build: ad-hoc signed, not notarized.
• Main fleet sweep: bd0dfbcf…. Re-run: 64ee1ffa… (source 4d75756). §7 runs: a783e23e… → 791edb1b… → b56dfc81….
• Suites on the final source: JS 4 215 tests (4 188 pass, 0 fail, 27 environmental skips); Rust core 146, daemon 175 (Test report §14j).

Sources

• docs/mac/BENCHMARKS_MEDIA_AND_FLEETS.md ("Mac bench"): §1–2 media, §3 memory findings, §4 fleets (§4.6 main sweep, §4.8 re-run), §7 fixes of 2026-09-26.
• docs/mac/TEST_REPORT.md ("Test report"): §0, §3, §4, §14a–j.
• docs/mac/DECISIONS.md: D4, D5, D10–D14, D18–D22.
• docs/mac/CONTENT_QUALITY_REVIEW.md ("CQ review").
• NIGHTSHIFT_MACOS_MIGRATION_STATUS.md; NIGHTSHIFT_MAC_TESTING_HANDBOOK.md ("Handbook") §0–1.
• Raw harness data: ~/nightshift-build/bench/fleets3/, fleets4/, fleets5/, fleets6/, fleets7/ (<fleet>.json, .samples.jsonl); fleets3-summary.md, fleets4-summary.md; fleet-bench.mjs (prompts and scorers); rescore-fact.py (v2 fact rule). Every figure in §3.3 and §3.4 marked "computed" was recomputed from these files for this document.
• nightshift-landing/benchmarks.html ("DGX page"), index.html, how-it-works.html.
• NIGHTSHIFT.md; NIGHTSHIFT_JOBS_USE_CASES_AND_BENCHMARKS.md; NIGHTSHIFT_DGX_SPARK_FLEET_CATALOG.md (v2.6); NIGHTSHIFT_MODELS_BY_CLASS.md.
• reports/PROVIDER-LATENCY-REVIEW-2026-09-01.md; reports/NS-VERIFY-AUDIT-001.md (on the DGX, 783 of 791 verify events had timed out because an embedding model was picked as judge; fixed 2026-09-01); reports/sandbox-measure-2026-09-07.json; reports/NS-CE-BUILD-001-CP2-calibration.json; reports/MEDIA_MODEL_REVIEW_2026-09-14.md; reports/RELEASE_1.2.1.md.

Known limitations of the data

• The Mac suite is small: three prompts, best-of-4, one run per fleet per build, on a machine whose free memory moved between runs. Time comparisons are good to magnitudes, not seconds.
• The fact scorer is a regex rule confirmed by reading the winners. §7.1 of the Mac bench reports the pre-F-12 agentcode-lite run as 2/3 winners correct under the original fact rule. Raw data under the v2 rule gives 3/3, and this document uses v2 throughout. The fleets5–7 fact jobs were scored by the harness's built-in, stricter check, not re-scored with v2.
• The before/after quality comparison is confounded by model size and prompt changes (§3.9).
• DGX figures are taken from the public page and were not re-derived from the raw job log for this document. On the published night, the page gives "202 attempts" (202 dispatched, 130 landed) and also "attempts / accepted 200". These are two different counts of the same night.
• Two catalog counts disagree across documents: NIGHTSHIFT.md (at 0.99.0) says 185 fleets over 274 model rows; Fleet catalog v2.6 (2026-09-23) says 203 fleets. This document uses the newer figure.
• Throughput figures in the fleet tables are estimates (characters ÷ 4).
• Not measured anywhere: power, energy, cost per accepted result, quality retention against a frontier model (the planned one-click quality proof, PLANS/PLAN-quality-proof-report.md, has not been run), any Mac above 16 GB, and the Mac UI on screen.