200 parallel sandboxes researched the Next.js backlog before maintainers closed 1,462 issues

The inactivity workflow moved plenty of issues. Between January 2025 and August 10, 2026 the Next.js backlog fell from 3,109 to 2,244, a net 865 ^[2][3][3]. That window is about 19 months ^[1], and at the stated average of 36 new reports a week the tracker took in something like 2,950 reports over the same span ^[1][2]. To net out 865, the stale rule had to close on the order of 3,800 issues ^[4]. Accuracy was the problem, not throughput. Next.js writes that an old issue might be fixed, a duplicate, expected behavior, something no longer supported, or a real bug nobody had revisited, that a timestamp cannot tell those cases apart, and that the workflow closed some reports it should have kept ^[7].

closability runs each investigation in a fresh sandbox holding the Next.js repository, Node.js, Playwright and Chromium ^[9]. It reads the GitHub conversation, checks the supported versions, searches related issues, pull requests, commits, releases and documentation, and where needed tries the reproduction on the reported version, the latest stable release and canary ^[10]. Then it looks for evidence that contradicts its own conclusion ^[10]. The scoring rules are conservative by construction: a failed reproduction on its own is not enough to recommend closing, and a high confidence score requires strong current evidence with nothing credible against it ^[12]. A finished investigation returns structured data, and the published example carries a closeConfidence of 86 with the merged pull request and a clean canary run listed as evidence ^[11].

Investigations averaged 30 minutes on GPT-5.6 Luna with reasoning effort set to max, and the team raised concurrency until 200 eve sessions were running at once ^[15]. At that width the fleet retires 400 investigations an hour, so a 2,244-issue backlog is roughly six hours of wall clock ^[5]. It is also about 1,100 sandbox-hours of Chromium and Node ^[6]. The post does not give a compute bill.

Issue text is untrusted input from the internet, and the agent reads it while holding a checkout. The write path is off outside the sandbox: closability cannot comment, close an issue, push code or deploy ^[13]. It is also configured to ignore instructions it finds in issue text or repository content ^[14]. A successful injection therefore buys a wrong recommendation in a queue, and maintainers read the evidence behind every result before acting ^[16].

The 1,462 figure is a claim about one backlog. For it to transfer, a repository needs a checkout that builds and runs from scratch inside a sandbox, bugs that reproduce from the issue text alone, and a release history with a canary channel to test the fix against ^[10]. It also needs a backlog with a lot of already-fixed and duplicate reports in it, because those are the cases a research pass can produce hard evidence for. On a tracker full of design disagreements and hardware-specific crashes, I would expect a much lower confidence distribution and more of the work landing back on maintainer reading time.

One number to hold loosely. Taking 2,244, subtracting 1,462 and adding 218 arrivals lands on exactly 1,000 ^[7], which is "below 1,000" only if the closing kept going after the count was taken. Next.js says the 1,462 includes some issues maintainers closed outside this review ^[5]. The 218 arrivals over roughly three weeks work out at about 73 a week, twice the average the same post reports ^[8].