Boost wraps a turn in extra reasoning. Before the work it can reconstruct the task independently; after the work it checks whether the task is actually complete, and can trigger one repair.
/boost enable for this session
/boost <task> enable and run this task with Boost
/boost off disable
/boost status current state and budget
/boost trace what each pass concluded
/boost budget 1-4 set the pass budget
Use it when correctness matters more than speed — a fix you can't easily verify by eye, or a change going somewhere consequential.
All draw on one shared budget (default 4, range 1-4).
| Pass | When | Purpose |
|---|---|---|
plan |
before the work | independent task reconstruction, invariant-first |
alternative |
only if the plan asks for it | dissenting reconstruction, failure-first |
verify |
when the turn would end | is this actually complete? |
recheck |
after a repair | did the repair work? |
Planning is gated on a budget of 3 or more. So:
budget |
Behavior |
|---|---|
| 1-2 | verification only — no planning passes at all |
| 3 | plan + verification |
| 4 (default) | plan, optional alternative, verification |
Setting budget 2 to "make Boost cheaper" silently turns off planning entirely rather than
trimming each phase. If you want light Boost, that's the trade you're making.
At the point the session would end, an isolated pass — the same model as the lead, but with no tools and no coding-harness prompt — receives a bounded evidence bundle: the original task, the lead's final response, and the last handful of tool results. It returns a verdict.
A negative verdict must name the unmet criterion, cite the evidence it used, and propose a bounded repair. Vague or uncited criticism is discarded, because a bad verdict would otherwise inject pointless repair work.
If a defect is confirmed, one repair cycle runs, then a recheck.
Every failure path is fail-open. If the verifier errors, times out, or returns something unusable, the session finishes and reports as degraded — you still get your answer. Worst case Boost appends a note that verification was unresolved.
Warning
Boost costs extra model calls, billed like any other. A boosted turn can be several times the cost of a normal one.
/boost statusshows how much of the budget the last task used.
The verifier reads the conversation, not your repository. Its strongest evidence about whether something works is the lead's own claim plus tool output already in the transcript — it cannot run your tests itself.
So Boost is a rigorous second opinion, not objective proof. For "did this actually fix it", pair it with /bug-fix, which requires a regression test that fails before and passes after.
| Use case | Effect | Why |
|---|---|---|
| Design / Architecture / Planning | Much better | The least obvious fit and one of the strongest. The planning passes reconstruct the task independently — one invariant-first, optionally a second failure-first — which is exactly the "what am I missing?" second opinion a design needs, before any code exists. |
| Migration | Much better | High blast radius and hard to eyeball. The completion check catches "converted 40 of 47 call sites" claims that read as finished. |
| Bug-Fixer | Better | Verification pushes back on a fix that was asserted rather than demonstrated. Pair it with /bug-fix, whose regression test is the objective half. |
| Feature Development | Better | Worth it for work going somewhere consequential; the cost is hard to justify on routine changes. |
| Testcase creation | Some | Can catch tests that don't actually assert anything, but it reads the transcript, not test results. |
| Reviewer | Little | Overlapping purpose. /review already fans out across aspects, and running both doubles the calls for the same job. |
Boost is the one to reach for when being wrong is expensive — and specifically when you can't cheaply check the answer yourself.