[BUG] Six `/ultrareview` crashes in one day, all billed as Extra Usage with no findings posted

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Six /ultrareview crashes in one day, all billed as paid Extra Usage

On 2026-05-10 I ran cloud /ultrareview against three open PRs on my practiceforge repo (PRs #4, #5, #6) — three Leptos refactor sprints awaiting review. Across the day the cloud reviewer crashed six times in total. Every one of them was a paid Extra Usage run; none of them posted findings back to the PR.

Total estimated burn: roughly $30–120 of Extra Usage with zero useful output.

Per-PR breakdown

PR #4 (leptos-sprint-3-clinic) — 5 attempts, all failed:

• First 2 attempts: timed out because the PR was in CONFLICTING state vs main. I resolved the conflicts (merge commit 9a7f924) and retried.
• Next 3 attempts: cloud reviewer crashed at the Dedupe phase after Find produced 19 candidates. So the work was done but never reached me.
• Most recent crashed session: 01XtVEXX7Hh7L2R3TvCxJSoD

PR #5 (leptos-sprint-4-compare-inspector) — 1 attempt:

• Crashed at the Dedupe phase after Find produced 19 candidates. Same shape as PR #4.
• Session: 017rnWAXN6wiVJtWKNBLqTdp

PR #6 (leptos-sprint-5-remaining) — 1 attempt:

• Crashed at the Find phase itself, no candidates produced. The diff is large (~4,710 lines across the Sprint 5 surface migration); plausible the Find-phase budget couldn't accommodate it.
• Session: 01B8pPT5gWeadHRANUSzLBNo

Recovery I had to do myself

For PRs #4 and #5 I recovered the 19 candidate findings each from the session UI by taking screenshots before the session pages went away, then asked three parallel CC sessions to apply them. That's how the cloud-review work product ended up on those PRs (commits f262d88 for Sprint 3, 01fbedd for Sprint 4) — manually recovered, not posted by the cloud reviewer.

Issue

I was billed Extra Usage for all six runs even though none of them produced findings on the PR. This isn't a one-off — it's six in a row, two distinct crash shapes (Dedupe-phase post-Find, Find-phase outright), across three different PRs in the same repo on the same day. The Find-then-Dedupe-crash shape in particular is wasteful because the work to produce candidates did happen — the reviewer just couldn't ship them back.

I am requesting a refund for the Extra Usage burned across these six runs.

What Should Happen?

A crashed /ultrareview session — one that does not post findings back to the PR — should not be charged as a successful Extra Usage run. Where possible, partial state (the 19 candidates produced by Find before Dedupe crashed) should be surfaced to the PR even on partial failure, rather than discarded.

Error Messages/Logs

PR #4 latest: session 01XtVEXX7Hh7L2R3TvCxJSoD  (Dedupe crash, 19 candidates lost)
PR #5:        session 017rnWAXN6wiVJtWKNBLqTdp  (Dedupe crash, 19 candidates lost)
PR #6:        session 01B8pPT5gWeadHRANUSzLBNo  (Find crash, 0 candidates produced)

The three earlier same-day attempts on PR #4 do not have session IDs preserved in my local notes — happy to pull them from billing if Anthropic wants the exact session IDs for all six.

Steps to Reproduce

1. Open a non-trivial PR (Rust workspace, mixed source + asset diff, ~few thousand lines).
2. Run /ultrareview <PR>.
3. Crash at Dedupe or Find — paid run, no findings posted.

Reproduced consistently across three different PRs on 2026-05-10.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.138

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

WezTerm (macOS)

Additional Information

Related prior reports: #57300, #57129, #55814, #54794, #52819. The pattern repeats and the burn rate is high enough on a multi-PR day that it warrants attention beyond the single-incident refunds I've filed previously.