15 open-source orchestrators, one table of same-day 2026-09-22 numbers

All of them are the GitHub API values for 2026-09-22, with the fetch day written after each number. Whether you can use them depends on what you want them for: as an order of magnitude and a relative position, one day does not change the conclusion (Orca 75,454 against second-placed 28,168); as an exact figure, no — Orca alone gained 1,700 within that same day. To quote, go back to the 2026-09-22 archive or fetch it yourself today. Checked 2026-10-19.

No. NOASSERTION only means GitHub's automated matching could not tie the LICENSE file to a known term; 3 of the 15 carry it. Looking again at those READMEs on 2026-10-19: the cmux section says it is open source under GPL-3.0-or-later and, in the same passage, that its server software runs under BSL 1.1; Superset says the whole app is in the repository under Elastic License 2.0 and that the single excluded thing is packaging Superset itself as a service you sell to others; the Worktrunk badge says MIT OR Apache-2.0. So read that column either from the README or from the repository's LICENSE file — a failed recognition is not an absent licence.

7 MIT, 5 Apache-2.0, 1 AGPL-3.0 (claude-squad); Worktrunk is MIT or Apache-2.0 as you choose; cmux is GPL-3.0-or-later per its README and Superset is Elastic License 2.0. Past the clause names, those READMEs also say what each clause actually allows and forbids: Superset writes that under ELv2 you can use it, fork it, modify it and self-host it for your team; cmux puts its server software under Business Source License 1.1 — reading, modifying and running it outside production are allowed, while production use or self-hosting needs a commercial licence, and the same section adds that commercial terms may be available to organisations that cannot comply with GPL; on the MIT and Apache-2.0 side the README gives a one-line grant statement and leaves the wording to the LICENSE file it links (emdash and agent-orchestrator are both like that). AGPL is about the source-provision duty when you serve over a network, ELv2 explicitly forbids reselling the product itself as a service, GPL about its propagation terms — none of the three behaves like «just use it» MIT, and running it internally differs from offering it as a service. The full text of each clause stands in the repository's own LICENSE and README. The licence counts were checked on 2026-10-19; the quoted README sentences come from the fetch of 2026-10-19.

What is findable in public is a user's own report, not a benchmark. Orca issue #10769 (filed 2026-07-26, still open on the fetch day) said at the time: in one repository at 297 live worktrees the median git commit went from about 1.5s to 8.9s, peak 21.6s, .git at 1.1G, with the cause pointed at degraded automatic maintenance of the shared object store. The reporter himself later retracted that causality: the top of that same body is now his follow-up, where further measurement disproved the original causal claim, the 301 worktrees were not the measured driver, adding --indexed-objects changed the enumeration cost negligibly, and the ~35s cost came from --reflog having to enumerate 7,330 reflog files, most of them created by Orca-managed fork remotes fetching every branch, one fork alone contributing 2,470 refs and reflog files. The follow-up also says that worktree count is still useful context, that the data does not support a count threshold such as ~100 as a Git-cost predictor, and that the original report stays as investigation history. What still stands is the product question: slow Git operations are invisible in the UI, and workspace and shared-store health has no path from the symptom. The direction given is to narrow managed fork fetches to the exact branch with --no-tags and to keep eligible Orca-spawned commits and fetches from triggering auto-maintenance on the critical path. It is one repository on one day, told by one user; different repository sizes and worktree counts will differ, and it describes Orca alone. To judge whether this reaches you, look at the scale of refs and reflog files in your own repository and at how many branches a managed fork pulls, not at how many worktrees you have. Re-checked 2026-10-19.

The table itself points the other way: 3 pushed before 2026-06-01, among them crystal at ★3,120 whose latest release is 2026-02-26, while tail sculptor at ★232 shipped a release as recently as 2026-09-21 — closer to now than several with more stars. When GitHub was pulled again on 2026-10-19, sculptor stood at ★240 and had shipped sculptor-v0.49.0rc2 that day; the freshly fetched README of crystal says it has been deprecated and replaced by Nimbalyst, and the README of nimbalyst at ★1,935 came back in the same round. Tools are chosen by constraint match (licence, form, your repository size) and by upkeep; stars are a by-product of search popularity.

The 2026-09-22 pull fetched and word-checked 11 full READMEs; for the other 4 (nimbalyst, parallel-code, uzi, terragon-oss) it held API metadata only, so those three cells said «not fetched». In the 2026-10-19 round all 4 READMEs came back and those cells were filled from the sentences of that day, with the fetch day written in the row; the other 11 rows keep their 2026-09-22 anchors. These columns answer one question: does this repository's README contain this sentence? A cell is filled only where a sentence exists, and one repository's wording is never moved onto another — the most expensive mistake in a comparison is putting into a subject's mouth something it never said.