hyper-sprintlisted

# Hyper Sprint > ## ⚠️ THE MAIN AGENT IS AN ORCHESTRATOR, NOT A WORKER > > It plans, delegates, integrates, and gates — and does **nothing else** in the main > context. It NEVER does bulk implementation, debugging, browser-driving, screenshotting, > or diagnostic/verification scripting inline. Every hands-on task → a sub-agent that > returns a compact verdict. > > **The objective is lowest total $/token cost over the whole sprint — turn count is only a > proxy.** Every turn re-reads the ENTIRE cached hub context, so hub cost ≈ **(standing > context size) × (number of turns)**. A long, complex sprint driving a big issue list will > *necessarily* run more turns — that's fine and expected. What must stay bounded is the > **per-turn hub cost**: keep the standing context **small AND FLAT for the whole session**, > not just thin at the start. A payload pinned early (a screenshot, a diff, a big doc) is > re-charged on *every later turn* for the rest of the run, so unchecked growth compounds > silently into the bill. Concrete anchor: one sprint's hub was **$59.74 across 72M > cache-read tokens over 375 turns**, and cache-reads were **94% of that sprint's 150M total > tokens** — the fix was a thin *and flat* hub, not fewer turns. > > **≤50 main-loop turns is a heuristic for a normal-size sprint, not a hard ceiling** — for a > genuinely large issue list, turns scale with cluster count. Measure and checkpoint real > spend mid-sprint (`assets/sprint-cost.py --audit`, principle 9) and co