Needles = last measured runBlue EST bugs = estimateTiles = output tokensLamps = five launch checksTest bench: your app sits in a vice, wired to four gauges. Slide in a cartridge: blue bugs show the estimate. Run measures it and lights the launch lamps.Shipping an app means measuring the right things the right way: time to first token, tokens per second at a stated context and batch, peak VRAM and power, on stated hardware, driver and runtime versions, after a warm-up, with fixed prompts. Here the prompt is 4,000 tokens (3,500 of them a shared prefix), 256 tokens out, batch 1. Each cartridge moves the gauges through _model.js: weight bits change the bytes read per token (decode speed) and the VRAM budget, an FP8 KV cache halves the cache, FlashAttention drops the score-matrix scratch, prefix caching prefills only the 500 new tokens, CUDA graphs cut per-token launch overhead (modelled as 25 µs per layer without, 3 µs with), TensorRT is assumed to lift bandwidth use from 70% to 80% and prefill efficiency from 40% to 55%, and a right-sized 8k window shrinks the cache. All numbers are estimates, not measurements: prefill uses the dense FP16 tensor rate (NVIDIA AI TOPS ÷ 8), power assumes 65% of board power while decoding. Perf needs ≥ 30 tok/s and TTFT ≤ 1 s, UX TTFT ≤ 0.5 s, Reliability ≤ 90% of memory; Perf, UX and Docs light only after a measured run. Needles move only during a run (a discarded warm-up, then the measured run); between runs they stay at the last measurement (grey once settings change) and blue set-point bugs show the estimate for the current settings. The lamps are Perf, Reliable, UX, Docs and Driver. During the measured run, token tiles leave the device on a belt at a rate that follows tok/s (one tile per 4 tok/s, 2–24 tiles) and the bin counts the 256 output tokens; a new run empties the bin through its floor.