English static mirror for SEO/GEO · AI-assisted translation · Read Chinese original

Superpowers v6 Deep Dive: How Fable Drove 36-Hour Autonomous R&D, Cutting Build Time 50% and Token Cost 60%

Forum topic · 小凯 · 2026-07-06

Summary

Superpowers jumped from 5.2 straight to v6 after Anthropic released Fable, which founder Jesse Vincent tasked with optimizing the framework's own Subagent Driven Development build loop. In roughly 36 hours and about $165 in tokens, Fable ran 25 hypothesis-driven experiments plus 4 backlog items, producing a ship-ready configuration (E27) that delivers ~50% wall-clock speedup and ~60% token cost reduction versus the baseline combo config. Three structural changes powered the gains: a pre-baked review packet that eliminates redundant git work, the merger of two separate reviewers (code-quality and spec-compliance) into a single stage with an explicit 'unverifiable from diff' status, and an autoresearch loop with preregistered hypotheses. The eval suite also exposed a Codex isolation bug that had been benchmarking 5.1.0. The release ships hard evidence on what works, what does not, and how to measure both.

Superpowers v6 Deep Dive: How Fable Drove 36-Hour Autonomous R&D, Cutting Build Time 50% and Token Cost 60%

> Author: Jesse Vincent (Prime Radiant) > Published: 2026-06-15 > Project: https://github.com/obra/superpowers > Evals: https://github.com/prime-radiant-inc/superpowers-evals > Original blog: https://primeradiant.com/blog/2026/superpowers-6.html

1. Why 5.2 Became 6

Superpowers was ready to ship 5.2. The branch already pulled in Pi / Antigravity / Kimi Code support, model-agnostic skill rewrites, visual-brainstorming polish, and a long bug-fix tail. Then Anthropic released Fable.

Instead of asking Fable for new features, Vincent handed it the build loop itself. The result was not the expected 15% token trim but a ~50% wall-clock speedup and ~60% token-cost reduction, large enough to skip a version and ship a major release.

2. Superpowers' Standard Workflow (Before v6)

1. Brainstorming with a visual mind-map → design doc 2. Isolated workspace per task 3. Detailed implementation spec 4. Strict red/green TDD 5. Two-gate review (code quality + spec compliance) 6. Merge

Every step guarantees quality but pays for it in latency and tokens. As Vincent put it: "It's never made me happy that it's slow and expensive."

3. The Three Structural Breakthroughs in v6

Breakthrough 1 — Coordinator→Reviewer Handoff: Pre-baked Review Packet

Reviewer subagents were re-running git commands to assemble diffs. v6 replaces the prose instruction with a shell script that emits a formatted review packet containing the diff plus metadata. Effect: ~10% reduction in tokens and wall-clock each. The reviewer no longer prepares; it judges.

Breakthrough 2 — Collapsing Two Reviewers Into One

The original pipeline ran a code-quality reviewer and a spec-compliance reviewer back-to-back. Vincent floated the idea of merging them in internal Slack before bed. Fable independently converged on the same hypothesis overnight, ran the experiments, and the next morning the eval results were waiting. Net savings: another ~15% in wall-clock and tokens, driven by a unified two-stage prompt and a new "unverifiable from diff" verdict state that closes a bypass.

Breakthrough 3 — Fable's Autonomous Research Loop (36 h, 25 experiments)

Vincent's directive to Fable:

> /goal once this is done, run an autoresearch loop to improve cost-efficiency of the superpowers build loop. test with opus as the coordinator. make an hypothesis log. run experiments. run at least 25 experiments.

Deliverables:

  • Complete autoresearch harness
  • 25 closed experiments + 4 backlog items
  • Preregistered prediction per hypothesis
  • Full log: docs/experiments/2026-06-11-build-loop-autoresearch.md
  • Loop cost: ~$165 (~$650 at unsubsidized token rates)
  • 4. Key Findings from the 25 Experiments

    Ship candidate E27

    Stack: opus controller + elicited plan + conditional Haiku implementers + terse reviewer contract + narration recipe + final-review tier pin.

  • Cost: $6.24 / $6.60 per run (vs. $11.67–14.84 for the baseline combo config)
  • Quality: 2/3 planted-defect gates passed. The single miss was attributed to reviewer variance and judge strictness, not the terse contract.
  • Wins with numbers

    | Optimization | Effect | |---|---| | Terse reviewer contract | -41% reviewer output, verdicts still complete | | Narration recipe | -54% output, zero variance | | Conditional implementer tiering | ~$0.5–1/run saved; correctly refuses Haiku on prose plans | | Fixture-realism on Svelte | -24% scope-matched work |

    Proven-dead intuitions

    1. Capping controller thinking — turns rose from 92 to 138, output doubled. 2. Plan word budgets — even with code exempt, test content shrank -62%. 3. Sonnet plan generation — fidelity held, task structure collapsed. 4. Implementation bodies inside plans — zero marginal value once tests + interfaces + structure are present.

    Risk note: diff-only review

    When reviewers see only the diff package, they produce confident spec verdicts while silently redefining "spec" to mean "global constraints." 0/5 missing briefs were flagged. Vincent compared it to the Haiku-reviewer advocacy failure family.

    Already optimal (do not re-buy)

    Report reads, cache health, reviewer floor, Haiku fixers, todo bookkeeping, dispatch re-derivation.

    Measurement bugs Fable caught and fixed

    1. grep counted template echoes as self-review catches. 2. The harness never inlined diffs. 3. The scorer regex dropped newlines.

    One early "-74%" verdict was retracted and re-measured honestly as -41%. Manual inspection is non-optional in autoresearch.

    5. Eval System: From "Feels Faster" to Quantified

    The v6 release stands on the Superpowers eval suite:

  • Cross-harness validation across Claude, Codex, OpenCode, and Cursor
  • Per-change deltas in build speed and token cost
  • Surfaced a Codex isolation bug — the harness had been benchmarking 5.1.0 without realizing it
  • Repo: https://github.com/prime-radiant-inc/superpowers-evals

    If your eval environment is not isolated, you may be optimizing a ghost version.

    6. Generalizable Design Patterns from v6

    1. Hand-offs are cost centers. Pre-bake the packet so reviewers start where reviewers should start: at the judgment. 2. Merging review gates is a prompt-engineering problem, not a subtraction problem. You need a coherent two-stage prompt and an "unverifiable from diff" status. 3. Autoresearch is the right posture for cost optimization: preregistered hypotheses, systematic measurement, and recorded failures. 4. Proving what does not work is as valuable as proving what does. Saved days are real wins.

    7. Caveats and Risks

  • E27 still needs the larger N=5 gate battery.
  • Terse contracts depend on reviewer consistency — variance is a quality risk.
  • Diff-only review has a documented context-collapse failure mode.
  • Codex isolation must be fixed before trusting its eval delta.
  • 8. Takeaway

    Superpowers v6 is the first AI-coding workflow framework systematically improved by an Fable-class autonomous research loop. The 50%/60% gains did not come at the cost of quality: 2/3 planted-defect gates still pass, and the one miss is variance, not the prompt.

    The full experiment log (docs/experiments/2026-06-11-build-loop-autoresearch.md) ships with the repo as a free experience pack — what worked, what did not, and why. Vincent's sign-off sums it up: "We're very proud of the improvements that we (and our robot buddies) have made."

    References

  • Project: https://github.com/obra/superpowers
  • Evals: https://github.com/prime-radiant-inc/superpowers-evals
  • Blog: https://primeradiant.com/blog/2026/superpowers-6.html
  • Author: Jesse Vincent (founder, Prime Radiant; author of Superpowers)
  • Key tool: Anthropic Fable (autoresearch loop)
  • Experiment log: docs/experiments/2026-06-11-build-loop-autoresearch.md
  • Date: 2026-06-15

Tags

#superpowers#fable#anthropic#subagent-driven-development#autoresearch#code-review#evals#token-cost-optimization

This page is an English static mirror generated for search and AI citation. It may be a full translation or structured summary of the Chinese original. Canonical interactive discussion lives on the Chinese page: https://zhichai.net/topic/178209100