Rush, 2.0

We're releasing a new version of our agent mode rush.

Prior to this change, rush’s usefulness was limited. It was faster and cheaper, but also made more mistakes and required more attempts to get to the same results than a slower and ultimately not that much more expensive frontier model.

Now, rush is tuned to lean into its advantages — speed, low cost — instead of trying to make up for its shortcomings.

It uses GPT-5.5 with no reasoning instead of Haiku 4.5. It is tuned for small coding tasks that don’t require contemplating the whole repo, but to find the relevant files, make the smallest correct change, run a focused check, and stop.

This is what rush is good at:

  • “Fix the failing renders empty state test.”
  • “Update @src/components/ui/Select.tsx to match the focus-ring styling in @src/components/ui/Button.tsx
  • “Rename enableLegacySearch to enableSearchV2 in all files that use it”

Do not use rush for transient bugs, architecture changes, migrations, complex features, and tasks where you do not yet know what “done” means. In those cases, reading more, thinking longer, and building a larger model of the codebase is what gets you good results. Use deep or smart for those.

What Changed

The previous system prompt in rush mode was “speed first.” It told the model to move fast, keep explanations short, edit, verify, and stop. With GPT-5.5, we can be more precise: gather only the context needed to act safely, make the smallest correct change, verify narrowly, and stop. This makes it less prone to save time by skipping the parts that make the result usable and to over-contextualize - to keep reading and thinking.

rush now uses shell_command for searching, reading, and verification, and apply_patch for edits. That means we can remove quite a few tools that all do almost the same thing - grep, glob, and create_file.

The task subagents have the same configuration as the main agent: no reasoning, GPT 5.5.

Evals

On our internal evals, rush solved 44% of tasks, up from 39% for the previous version.

The cost moved up slightly: $0.58 per task on average, compared to $0.44 for the previous version (an 18% increase).

The speed changed much more. Rush 2.0 finished in 1 minute and 32 seconds on average, down from 2 minutes and 59 seconds.

That is the tradeoff we wanted: a little more expensive, meaningfully more capable, and almost twice as fast.

It is not deep. On the same evals, deep solved 58% of tasks, 14 points higher than rush.

Pair It with the Oracle

The best pattern we have found is rush plus the oracle.

Let rush build. Ask the oracle to plan, criticize, or review. The oracle is slower and more expensive, but it is read-only and good at adversarial thinking.

This works especially well for tasks that are still bounded, but not trivial. You know the area of the codebase. You know roughly what needs to change. But there is enough surface area that a second, more deliberate pass can prevent rush from making the locally obvious but globally wrong edit.

Try prompts like:

  • “Ask the oracle to inspect @src/billing/applySeatLimit.ts, @src/billing/planLimits.ts, and the failing seat limit is enforced after downgrade test. Have it propose the concrete fix first: which behavior should change, which file should own the rule, and what should stay untouched. Then implement the smallest patch and run the billing tests.”
  • “Update the workspace invite flow so expired invites show the same error state in @src/routes/invites/AcceptInvitePage.tsx and @src/components/invites/InviteBanner.tsx. After the patch, ask the oracle to review the diff and suggest the focused tests or manual checks that would actually prove this works. Run the relevant ones before calling it done.”
  • “Before changing the caching behavior in @src/search/useSearchResults.ts, ask the oracle for two or three implementation options beyond the obvious one. Have it judge them in context of the codebase: consistency with the existing query hooks, risk of stale data, complexity, and testability. Then implement the best minimal option.”

To use it: run mode: use rush in the Amp CLI.