96,636 Stars, 152 Watchers, 115.6M Downloads: What Orca's Release Feed Actually Proves

Orca is a desktop application that runs several coding agents side by side, each in its own git worktree, and lets you steer them from a phone. It is MIT-licensed, backed by Y Combinator, and its repository (stablyai/orca) was created on 17 March 2026. When I pulled the repository metadata on 19 October 2026 it read like this:

Every one of those numbers is real. The interesting part is that they do not describe the same thing, and two of them — stars and downloads — are routinely read as if they did. This is an attempt to read the repository as instrument data rather than as a popularity contest, and to say plainly where the data supports the marketing and where it does not.

The watcher ratio is not a mistake, it is a channel

152 watchers against 96,636 stars is 0.157%. I measured four mature repositories the same way on the same day, and they cluster tightly:

Orca sits at roughly a quarter of the lowest baseline. The tempting reading is “fake stars”. The data does not support that, and the reason is mechanical: a star is one click on a repository you were sent to; a watch is a subscription to a notification stream you have to want. Orca’s distribution is a signed desktop installer plus an in-app changelog plus a Discord and six translated READMEs. Nothing in that funnel asks a user to follow the repository’s issue traffic — and the issue traffic, as the next sections show, is not something a normal user would want in their inbox.

So the watcher ratio measures the shape of the funnel, not the honesty of the stars. What it does tell you is that the repository is a build log, not a community forum. If you judge this project by reading its issue tracker the way you would read a smaller project’s, you will misread it in both directions.

115,651,862 downloads, and why dividing by 977 is the wrong arithmetic

The README carries a downloads badge. The SVG behind it currently renders 107m. GitHub’s own numbers are larger and more precise: I walked all 977 releases and summed download_count across every asset — 21 to 22 binaries per desktop release, covering macOS arm64/x64, Windows, and several Linux formats.

Total: 115,651,862 downloads across 977 releases, 21 March 2026 to 17 October 2026.

The naive divisor is the release count, which yields 118,374 downloads per release. That number is meaningless, and the reason is the most useful thing in this whole audit. Here is the monthly split:

Read the first and last columns together. In April the project shipped 208 releases in 30 days — nearly seven a day — and each one was downloaded 211 times. In September it shipped 24 releases in 30 days and each was downloaded 2.3 million times. Release volume fell by roughly 88% from April to September while downloads per release rose by four orders of magnitude.

Two conclusions follow, and they point in opposite directions from the usual ones:

1. The download number is credible. 2.3 million downloads for a single September build is not the profile of a star-farming operation. Dividing 115.6 million by 977 produces a low number only because 831 of those releases shipped in April–July, before anyone was using the app.
2. The release count is a historical artifact. “977 releases in 210 days” averages to 4.65 per day, but that average describes a summer, not the present. The current cadence is about one release per day, which is what the public changelog shows.

The distribution inside the 977 explains the same thing from another angle. The median release has 368 downloads; the 90th percentile has 64,455; the top 20 releases account for 54.6% of all downloads. 42 releases (4.3%) passed one million. The bottom half of the release list — 488 builds — accounts for 0.04% of all downloads. None of that is suspicious. It is what a counter looks like when a project starts at zero users and ends at millions, and the tags are stamped every day along the way.

One caveat that cannot be resolved from outside: asset downloads include auto-updates, CI jobs, mirrors, and people who install, uninstall, and reinstall. The September figure bounds the install base from below at roughly 2.3 million devices if every device installs every release, and from above at much more if devices update less often than the project ships. It is not a user count. It is the only adoption number the project publishes that is not a one-click gesture, which makes it the most useful one.

The changelog and the release feed disagree by two versions

The README says, in its own words: “we ship daily, so this list is perpetually behind. The changelog is the real feature list.” That is an unusually direct statement of intent, and it is mostly kept: between 11 September (1.4.200) and 15 October (1.4.226) the changelog carries 19 dated entries covering 25 releases.

But the two surfaces do not line up at the top. The changelog’s most recent entries are 1.4.225 on 14 October and 1.4.226 on 15 October. The release feed has no release and no tag for either version. It jumps from v1.4.224 (10 October) to v1.4.227 (16 October) and then v1.4.229 (17 October), which carries 22 assets and, at the time of writing, 919,663 downloads.

I cannot tell from outside whether those two builds were pulled, whether the changelog numbering is decoupled from the release numbering, or whether 1.4.226 was an internal build that got a public write-up. No source explains it. What I can say is that the two version sequences you would use to answer “what is the current version” do not agree, and that a team pinning versions should read /releases rather than the marketing changelog. Version 1.4 alone accounts for 568 of the 977 releases.

Who actually writes this code

15,007 commits is a lot for seven months. The contributor list is where the shape of the project becomes visible:

604 contributors, and four accounts hold four-fifths of the history. That is not unusual for a startup’s product repository — it is a company, not a volunteer project — but it does mean the contributor count in the sidebar overstates how many people could meaningfully review a change.

The commit trailers answer the next question, which is who — or what — is doing the typing. In the 100 most recent commits, 13 carry at least one AI co-author trailer, and those 13 commits contain 47 such lines: 43 naming a Claude model (Claude, Claude Opus 5, Claude Opus 5.5, all at noreply@anthropic.com) and 4 naming Orca Worker <orca-worker@localhost>. Widening to the 300 most recent commits: 30 commits (10%) carry an AI trailer, and the messages contain 117 such lines — 112 naming Claude, 5 naming Orca Worker. The line count exceeds the commit count because a squashed commit bundles several agent sessions, and each session appends its own trailer; one commit in the sample carries ten.

That is a floor, not a ceiling. A trailer is optional, and 87% of recent commits carry none. But it is consistent with the repository’s own instructions, which are written for agents rather than for humans. AGENTS.md is 13,806 bytes of engineering policy, and CLAUDE.md is 11 bytes: @AGENTS.md. The file governs the merge path in language that only makes sense if software performs merges:

“Pending, failed, cancelled, or missing required checks block agent merges even when repository settings allow them. gh pr merge --auto is not proof that CI passed: GitHub may merge immediately when checks are optional. Never use --admin or disable protection to bypass a failed check.”

and

“An explicit user instruction to make an emergency exception overrides this default; otherwise fix the failure or wait. Use --match-head-commit to prevent merging a different commit after validation.”

This is the part I would show to anyone who dismisses agent-built software outright. A team that lets an agent merge its own work should write exactly this: check identity, not just the job name; re-verify when the head changes; never use --admin; pin the commit. AGENTS.md also carries the kind of platform knowledge that is usually lost in a wiki — Windows CommandLineToArgvW argument mangling, MSYS rewriting /c, the glibc 2.31 floor, wsl.exe expanding $name under --.

What it does not say is how many humans review a pull request. There is no required-approval count anywhere in it. The Enterprise page says “Every agent change lands in a worktree and a pull request, so it is reviewed the same way as human code” — which describes the mechanism, not a reviewer quorum. If human approval is your adoption criterion, you have to ask; the public material does not answer it.

11,876 branches is the other tell. A branch-per-agent worktree workflow leaves exactly that residue.

The queue: 64 merges a day, twelve days to close

GitHub’s search API gives the split that the sidebar hides:

13,955 merges in 217 days is 64 merges per day, including weekends. 2,532 issues opened in the last 30 days is 84 a day. This is a project operating at a rhythm that a human triage process cannot follow, and the repository does not pretend otherwise — it just publishes the queue.

For a reader deciding whether to trust it, the honest measure is not the size of the queue but how long an item sits in it. From a sample of 100 recently closed issues, 41 were issues rather than pull requests; of those, the median time to close was 287 hours — about 12 days, the 90th percentile 1,327 hours (55 days), and only 6 of 41 closed within 24 hours. Seven of the 41 were filed by bot accounts. A 12-day median is not abandonment, and it is not a support desk either. If your adoption depends on a bug being acknowledged quickly, this is the number that should govern your decision, not 96,636 stars.

Hacker News offered no counter-signal: Algolia queries for the project name, the product phrase, and the company returned no thread above one point. A project at this scale with effectively no HN discussion means its traffic did not come from the usual launch channels — a desktop app that spreads through a download page, a Discord, and word of mouth, not through a comment thread.

What you can verify yourself, and what you cannot

The repository is unusually generous with verifiable claims, which makes it easy to separate marketing from mechanics.

Verifiable, with commands the project documents:

• pnpm tc, pnpm test, oxlint, pnpm run check:code-quality:changed — typecheck, tests, and the changed-lines gate.
• ORCA_REAL_CLAUDE_CLI_TEST=1 pnpm test src/main/claude/claude-structured-real-cli.test.ts … — runs the structured-session tests against a real Claude login. This is the rare test that proves the integration instead of mocking it.
• .github/workflows/pr.yml — the aggregate PR checks passed job (ID verify) that AGENTS.md requires before a merge. You can read whether the gate is real, and how it fails.
• /releases and /graphs/contributors — every number in this article.
• LICENSE — MIT, no dual-licence trap.

Claims you cannot verify from public material:

• “Prompts and code go straight to the providers you configure. Orca does not inspect or store them.” The client is open source; a packaged binary is not the client you can read, and the mobile relay under cloud/ is a server you do not control.
• “AICPA SOC 2 Readiness”. That phrase claims readiness, not a completed audit. There is no Type I or Type II report referenced anywhere on the page. If a security questionnaire asks for evidence, “readiness” is not evidence, and the page itself does not pretend it is.
• Enterprise governance — central enforcement of approved models, SSO, SIEM streaming, retention controls — is not described. The page offers a conversation (“Get in touch”), and there is no pricing page at all: /pricing returns 404.
• Whether any human approved a given merged commit.

Telemetry is the best-documented part of the product, and it is worth quoting because it is specific: events are keyed to a random local ID; no account, no email, no IP, no file contents, prompts, terminal output, repo names, branch names, paths, or commit messages. It says exactly what it sends: app lifecycle, repo/workspace creation events (method, never the repo), agent kind and launch origin, coarse error categories, and whitelisted settings toggles — all fixed enums, version strings, or the local ID. It goes to PostHog Cloud, US region, and can be switched off by DO_NOT_TRACK=1, ORCA_TELEMETRY_DISABLED=1, or a Settings toggle. The one soft spot is stated plainly rather than hidden: “Retention: PostHog Cloud’s plan-level default per their pricing page. We do not set a custom retention window.” If you need a contractual retention period, that sentence is your problem to solve, and at least they wrote it down.

What the numbers support

96,636 stars, 2.3 million downloads per September build, 604 contributors, MIT, and a test suite you can run — those are the marks of a real, fast-moving product, and the repository publishes enough for a sceptic to confirm most of it without trusting anyone’s blog post, including this one.

The distortions run the other way from the usual accusation. The download count is not inflated by bots; it is deflated by the divisor people apply to it, because 831 of the 977 releases predate the audience. The star count is not farmed; it is simply a worse signal than the watcher count, which tells you that almost nobody follows this repo’s daily output because they do not need to — they run the app.

What a reader should actually take away is narrower and more useful. A repository that merges 64 pull requests a day, closes issues in twelve days, ships under agent-written merge rules, and leaves 11,876 branches behind is an engineering organisation’s exhaust, published in public. Read it as evidence of velocity and of process discipline — the AGENTS.md merge gate is genuinely good practice — and not as evidence about how it will behave on your machine, in your network, or under your compliance regime. For that, you need the two things the repository cannot give you: a security review you run yourself, and a conversation with the vendor about the questions its Enterprise page leaves open.

FAQ

Is Orca open source? Yes — MIT, the full desktop client, plus the mobile pairing relay under cloud/. It is also a commercial product: Y Combinator–backed, with an Enterprise offering and no public price list.

Why does Orca have 96,636 stars but only 152 watchers? Because stars arrive through a download page and watchers require opting into a notification stream for a repository whose issue traffic runs at 84 new items a day. The ratio is 0.157%, against 0.555–0.641% for four mature repos measured the same day.

Are the 115.6 million downloads real? They are real numbers reported by GitHub’s API, summed across 977 releases. They are not 115.6 million users. In September each release averaged 2.3 million downloads; the honest reading is an install base in the low millions, with auto-updates counted once per update cycle.

Is the code written by AI? Partly. In the 300 most recent commits, 30 (10%) carry an AI co-author trailer — 112 lines naming Claude, 5 naming the project’s own Orca Worker. Trailers are optional, so that is a floor. Four accounts hold 79.5% of all commits.

Does it send my code or prompts anywhere? Per its telemetry docs: no file contents, prompts, agent output, repo names, branch names, paths, or commit messages; usage events are keyed to a random local ID and sent to PostHog Cloud US. You can disable it with DO_NOT_TRACK=1 or ORCA_TELEMETRY_DISABLED=1. The prompt/code path itself runs to the model provider you configure — which you cannot verify from public material, only review.

Is it SOC 2 certified? The Enterprise page says “AICPA SOC 2 Readiness”. Readiness is not a completed audit, and no Type I or Type II report is referenced.

Should I pin a version? Yes, and read /releases rather than the changelog: version 1.4 alone accounts for 568 releases, and the two most recent changelog entries (1.4.225, 1.4.226) have no corresponding release or tag.