You can also read this post on our corporate blog at https://primeradiant.com/blog TL;DR: Superpowers 6 is much, much faster and burns many fewer tokens to get the same high-quality outcomes. If you're tokenmaxxing, maybe skip this release, but if you care about your builds being up to 50% faster and up to 60% cheaper, you're going to love Superpowers 6. A week ago, we were gearing up to release Superpowers 5.2. We'd slipped the release a couple of times already to add "just one more improvement." We added support for Pi, Antigravity and Kimi Code. We made Superpowers work better on Codex and OpenCode, and Cursor. We rewrote a bunch of the Superpowers skills to be model and harness agnostic, which helps them be more reliable everywhere. We also wrote a new contribution guide for how to add support for a new coding agent harness for Superpowers. We did a bunch of work to make Visual Brainstorming easier to use, safer, and more reliable. And we fixed a whole slew of bugs, including a particularly nasty one that led to code review subagents sometimes reviewing the whole branch, rather than a single task. It was going to be a great release. And then Anthropic shipped (and unshipped) Fable. In the few days that I had access to Fable, I put it to the best use that I could. It's no secret that the most common lament we hear from Superpowers users is that tokens are expensive and Superpowers uses a ton of them. Building software with Superpowers is slower than building without it, too. The "slow" part shouldn't matter - it happens during the autonomous subagent driven development orchestration of the build process. But it does matter. Slow isn't fun. And expensive isn't fun either. A bunch of the reasons that Superpowers builds have taken longer and cost more are the same reasons that it delivers good outcomes for so many users. It does a ton of up-front planning work to make sure your implementations can be hands-off, forces strict red-green TDD while implementing, and then the orchestrator inside Superpowers reviews every single change on two axes: 1. did the agent implement exactly what was asked, no more and no less. 2. is the quality of the work up to snuff. Just by the nature of what it's doing, it's going to be slower than yoloing an untested implementation and calling it a day. But it's never made me happy that it's slow and expensive. When Fable came out, I decided to see how well it could optimize Subagent Driven Development. I think I was hoping for something like a 15% reduction in token spend. I got that. And a whole lot more. Our first angle of attack was looking at the coordinator to reviewer handoff. Fable analyzed thousands of Subagent Driven Development sessions and found that code and spec-compliance review subagents sometimes ran a lot of git commands while doing their reviews. Simply switching the written instructions for how to find the commits to review to a shell script that pre-generates a review package containing well-formatted diff and some other metadata decreased token spend and wall-clock time by about 10%. As I was going to bed that evening, I told Fable to see about shaving another 15% off wall clock time and token cost for our evals while I slept. As I was going to bed, I posted a note on our internal Slack that we should look at evaluating what happens if you combine the code reviewer and the spec compliance reviewer. I don't really know what I expected to happen overnight, but I don't think it was waking up to find that Fable had independently come to the same conclusion, tested it, and found that across our eval suite, it saved that additional 15% I'd asked for. https://blog.fsck.com/assets/2026/06/pasted-image-20260615-200048.png The next night, I got a little more ambitious. Fable built out a full autoresearch harness and ran overnight. You can check out what it built on GitHub (https://github.com/prime-radiant-inc/superpowers-autoresearch). The long and the short of it it is that across about 36 hours of work and what would have been $650 of unsubsidized token spend, our Anthropic eval benchmarks were looking like we'd reduced wall-clock runtime for Superpowers builds by 50% and token spend by 60%. And then we ran our evals against Codex. The results were not good. I'd worried that they might not show the same level of improvement, but they showed no improvement. A few minutes of digging and we found the culprit. On Codex, the evals weren't yet sufficiently isolated from the host OS....so we were always benchmarking Superpowers 5.1.0. A little bit of fiddling later....yup. Everything held up. https://blog.fsck.com/assets/2026/06/pasted-image-20260615-195959.png The biggest improvements came from combining the spec compliance and code quality review agents, pre-baking the review "packet" handed to the reviewers so they rarely need to run git, and changing the guidance we give to the orchestrator about what kind of agent you need for a given task. We've been working hard on our evals suite for Superpowers and without it, it would have been impossible to measure and test the changes we made. The suite is still relatively young, but it has meant that we're able to make and test changes to Superpowers across a variety of supported harnesses and to quantify what those changes do across a growing set of coding agents. You can find it at https://github.com/prime-radiant-inc/superpowers-evals We're very proud of the improvements that we (and our robot buddies) have made in Superpowers 6. We think you're going to love the new version. You can install it right now from https://github.com/obra/superpowers. It'll start to percolate into the first party plugin marketplaces over the next couple of days. PS: We're hiring! If you know someone who should be working on Superpowers full time, please share the posting with them: https://primeradiant.com/jobs/superpowers-community-engineer/