REA hit 83,000 GitHub stars in 44 hours. We measured the curve

On 9 October 2026 github.com/morluto/rea showed 36,003 stars, measured at 13:10 UTC. Two days later, on 11 October at 09:41 UTC, it showed 83,089. That is 47,086 stars in 44.5 hours, an average of 1,058 an hour. We read the tool and rebuilt the curve. Two findings came out of it and they belong in separate columns: the software is real, MIT-licensed and well built, while the popularity is not real.

What REA puts on the table

REA stands for Reverse Engineer Anything and ships as an MCP server, as a CLI called rea, and as a skill pack. It gives an agent the tools to understand software it does not own: a native binary, an Electron application, an Android APK, firmware, a network capture, a running process. The list of supported agent clients lives in the code, in SupportedClients.ts, and names Claude Code, Codex, Cursor, Gemini CLI, Windsurf, Devin, OpenCode, GitHub Copilot CLI, VS Code and Grok. The package asks for Node ^22.19.0, ^24.11.0 or >=26.0.0.

The native track depends on proprietary disassemblers, the JavaScript and Electron analysis does not. For us the second half is the interesting one, because it runs on a plain Linux host with nothing extra installed.

Rebuilding the curve

The star count is a headline, so we measured where the timestamps are per item instead. GET /repos/OWNER/REPO/forks?sort=newest&per_page=100 returns 100 forks with timestamps per request, and GitHub throttles unauthenticated callers at 60 requests an hour. The span inside a page is the current rate, the page number together with its dates is the curve. We pulled eleven pages.

The repository's own baseline sits on the later pages. Pages 166 to 179 hold everything before 7 October: about 1,390 forks over 86 days, roughly 16 a day. Pages 1 to 165 hold 16,500 forks over 3.69 days, roughly 4,470 a day. That is 280 times the repository's own baseline.

A genuine push from a global readership follows waking hours and fades after a day or two. At 03:00, 06:00 and 09:00 UTC our numbers read 310, 302 and 367 forks an hour. Three flat days through the night is a machine.

The companion metrics do not move with it. Against 83,089 stars stand 269 watchers, which is 0.32 per cent, and 82 contributors, which is 0.10 per cent. For scale: a repository that many people merely bookmarked lands near two per cent watchers. Of the repository's last 100 events, 77 were WatchEvents, and those 100 events fit into 2 minutes 57 seconds. Hacker News carries four posts about the repository URL with 4, 3, 2 and 1 points and two comments in total. None of the 83,000 stars came from there.

The npm package tells the same story in a different unit. Thirty-one versions, the first on 12 July 2026, then a gap of two and a half months, then eleven releases in eight days including three major versions in four days.

The comparison against registry reality is tight. The official MCP filesystem package, @modelcontextprotocol/server-filesystem, has a fraction of these stars and pulled 447,296 downloads in the past week, against REA's 73,651. zod stands at 44,000 stars and 341,697,718 downloads in the same week, playwright at 97,000 stars and 112,438,501. Stars measure attention, downloads measure use. For the window 3 to 9 October the registry reports 39,279 downloads, the rolling week now 73,651. At 12:45 UTC the badge service showed roughly 90,000 stars for the repository, rounded, against 83,089 at 09:41 UTC. That is about 2,300 stars an hour. The curve is not fading, it is still accelerating. On the author's side: the account morluto held 162 public repositories on 9 October and 252 on 11 October. Its fifteen newest are forks without exception, several named after rea, all of them awesome-lists that exist to list the project. The repository topics also claim an integration with an agent tool called dsh. That word appears zero times in the source of version 6.1.0 and in the shipped npm package 6.4.0. A topic is catalogue advertising.

The check in five requests

1. GET /repos/{owner}/{repo} for stars, forks, watchers, created date and licence.
2. GET /repos/{owner}/{repo}/contributors?per_page=1, where the Link header names the contributor count.
3. GET /repos/{owner}/{repo}/events?per_page=100 for the mix of event types and the span they cover.
4. GET /repos/{owner}/{repo}/forks?sort=newest on the first page and on a deep page, for baseline against current rate.
5. Hacker News search for the repository URL, plus registry downloads and the author account's attention history.

Two traps in this procedure

The finding we nearly reported was not a finding. The fork list returns user: null for every page when called without a token, including the page holding the organic entries from July. Reading that as deleted throwaway accounts would have piled one fabrication on another. The second trap sits in the control: our comparison repository was supposed to disprove the null and returned zero rows. A control that returns nothing proves nothing. Its result only means something once it returns rows.

Our reading of the event senders' accounts changed since the first pass. On 9 October the newest fork owners looked like throwaway accounts. On 11 October, eight senders we sampled had been created between 2011 and 2024 and carried real names. That does not clear anything, it moves the mechanism: bought engagement through aged accounts is the more expensive and more persistent variant.

Separating evidence

Where we would have used it

Three candidates from our own estate were up for it: the host carrying our transport frontend, the host carrying the ERP build, and the pilot machine for the mail archive. On the frontend host run Node 22.22 and a supported client, so the technical conditions would be met. We have run our own MCP lane ourselves since the summer, and the lessons from that are in three lessons for a production-grade MCP server. That host holds only programs whose source we write ourselves. On the ERP host npm and npx are missing, so the documented installation path simply does not run there, and the black box in that corner is Java bytecode: for that, javap plus a decompiler such as Vineflower is the standard tool, offline and without a new entry point. The archive pilot machine contains our own software.

The two genuine black boxes in the house are a proprietary Java ERP and a commercial mail archive. Taking those apart is not a tooling question. In the EU the interoperability exception of Article 6 of Directive 2009/24/EC applies: reproducing the code and translating its form is allowed only where the information is not otherwise available, only by someone with a right to use a copy, only on the parts necessary for the purpose, and only to achieve interoperability. Article 8 voids contractual terms that undercut that exception, licences do it in practice anyway, and in the United States circumventing technical protection measures falls under Section 1201 of the Copyright Act. That decision belongs to our legal team, not to a setup command. The supply chain adds to it: the instructions read npx rea-agents@latest, and the setup rewrites the configuration files of other agents. On a host carrying a production system, that is a decision you make against a team that demonstrably manufactures its own reach.

What we take away

Three ideas, no code: every statement an agent makes carries evidence, limitation and provenance. A registration in somebody else's configuration runs plan-first, with a backup and a diagnostic before the write. A skill describes the capabilities of the pinned version, so the instructions match the release that is installed.

Further reading

• Repository morluto/rea, rea.tools, npm package rea-agents
• GitHub REST API: list forks for a repository
• Ask Hacker News about the repository URL
• Star history service
• Downloads per package at npm, npm downloads endpoint
• Star badge used as a measurement point
• Directive 2009/24/EC, Article 6 decompilation, Article 8
• Section 1201 of the US Copyright Act
• Decompiler Vineflower, the javap tool, Hopper