subscaler

# /subscaler — tiered model composition `/superscalar` decides **how eagerly** to fan out. This skill decides **what each lane runs on** — tier *and* effort. The two are orthogonal; set them independently. The mechanism that makes a tier drop safe is **spec completion before offload**: a fully-specified lane loses little from one tier down, an underspecified one loses a lot. Spec completeness is the quality moderator, not model size. ## Toggle contract - State = **one marker file**: `.agent/subscaler.json` — `{"on": true, "family": "<vendor>", "effort": "<level>"}`. Read at invocation time; never mirror the state into other settings surfaces (duplicated per-role model bindings have shipped state-convergence bugs). - `/subscaler on` writes it · `/subscaler off` removes it (or sets `"on": false`) · `/subscaler status` reads it back and reports where it would apply next. - **Default OFF.** ON is recommended where fan-out has *already* forfeited the shared prompt cache. A delegated subagent starts cache-cold on its own model, so a small, cache-hot, deep-context edit loses money on delegation. ## Step 1 — read the registry, don't recall it `plugins/superscalar/model-registry.json` is the source of truth for anything perishable: which models occupy which tier, their exact `apiModelId`, context windows, prices, **the vendor's exact effort values**, per-plan availability, and per-harness binding keys. Read it before binding a lane. Never bind a model id from memory. Model ladd...