345 tools, 6 signals, 3 hard stops, nothing hand graded, rescored September 13, 2026

How a tool is scored

Every verdict is a pure function of stored GitHub signals. The same row scored twice gives the same answer.

Three hard stops

states that decide the verdict on their own, before a point is scored

State	Verdict	Why
Archived on GitHub	dead, 0/100	The owner has made the repository read only. It cannot accept a patch, so activity is not the question. 9 of the 345 tracked repositories are in this state today.
Disabled by GitHub	dead, 0/100	GitHub itself has taken the repository out of service.
365 days without a push	dead, whatever it scores	Twelve months of silence overrides the score. A project can hold a respectable number on release cadence and maintainer count long after the last commit; the commit is what a dependency actually rests on.

None of the three is a judgement call. Each is a field GitHub reports.

What the verdict is made of

six signals, scored from stored values, so a verdict is recomputable without re-reading GitHub

Signal	Worth	Why
Commit recency	0 to -96	Days since the last push, and the backbone of the whole score rather than one adjustment among six: a push inside a week starts the row at 100, inside a month at 92, a quarter at 72, six months at 55, a year at 32, two years at 12. Past a year the dead verdict is forced outright regardless of everything below.
Commit volume	0 to +6	Commits in the last twelve weeks. Twenty or more earns 6 and five or more earns 3; below that it earns nothing. It is a credit and never a penalty. Silence is already priced by the recency band above, and charging for it twice was the arithmetic error this table used to describe. The GitHub call pages at 100, so a hundred is read as at least a hundred.
Release cadence	+4 to -12	The current release gap measured against the project's own median gap, not against a fixed number. Three times its own cadence is the heaviest penalty here. A project that tagged releases and stopped tagging says more than one that never tagged. Never tagging at all costs two points: it leaves the axis unreadable rather than proving neglect, so it is a small deduction and not one of the heavy ones.
Issue response	+9 to -20	Median time to a first maintainer reply on recent issues, worth +6 to -12, plus the share of sampled issues with no reply at all, worth +3 to -8 once at least eight have been sampled. This is the signal a star count can never carry. Where there are too few recent issues to measure, it scores zero rather than guessing.
Maintainer count	+5 to -8	Distinct people who committed in the last 90 days. Nobody loses 8, one person loses 5. A single committer is a single point of failure however fast they ship.
Licence	0 or -6	No licence file is a reason not to depend on a project regardless of how active it is, so it is scored rather than mentioned. A repository that declares one is not credited for it.

Every point a tool gained or lost is listed on its own record, beside the fact that produced it.

The bands

where the score lands, once every signal above is applied to a base of 100 and the total is capped at 100

Score	Verdict	Why
65 and above	maintained	Recent commits, a release line that is still moving, and someone answering issues.
26 to 64	slowing	Still open, but at least one of the three has gone quiet. This is the band worth reading the signals for rather than taking the word.
25 and below	dead	Or any of the three hard stops above, whatever the score would otherwise have been.

The three numbers here are read from the same file the scorer reads, so the table cannot drift from the rule it describes. Add the Effect column on any tool record to 100 and you get that tool’s score.

The longest silences on the board

ordered by time since the last commit, the clearest reading of what the method is for

The ten dead tools with the longest silence

Smol Developersmol-ai/developer	DeadCLI agents	0/100	2.4y agoApril 7, 2024	too few	12k
AlphaCodiumCodium-ai/AlphaCodium	DeadIDE extensions	2/100	22mo agoNovember 25, 2024	too few	4.0k
SuperAGITransformerOptimus/SuperAGI	DeadOrchestrators	0/100	20mo agoJanuary 22, 2025	too few	18k
Aidecodestoryai/aide	ArchivedIDE extensions	0/100	19mo agoFebruary 25, 2025	too few	2.2k
AgentGPTreworkd/AgentGPT	ArchivedOrchestrators	0/100	17mo agoApril 29, 2025	too few	36k
GPT EngineerAntonOsika/gpt-engineer	ArchivedCLI agents	0/100	16mo agoMay 14, 2025	too few	55k
Devonentropy-research/Devon	DeadCLI agents	2/100	16mo agoMay 26, 2025	too few	3.5k
bytebotbytebot-ai/bytebot	ArchivedRuntime & harness	0/100	12mo agoSeptember 12, 2025	too few	11k
Devikastitionai/devika	DeadCLI agents	22/100	12mo agoSeptember 25, 2025	too few	20k
Plandexplandex-ai/plandex	DeadCLI agents	4/100	11mo agoOctober 3, 2025	too few	16k

The whole dead list

How a tool gets on the board

computed from the catalogue file the nightly reads

Two ways in, and one of them is editorial. 82 of the 345 tracked repositories are named by hand in the catalogue file, because the tools people search for by name have to be on a board about those tools whatever a topic search happens to return that week. For those, the category is set by hand too. Whether Spec Kit is a spec framework or an orchestrator is a judgement, and a keyword rule gets it wrong in exactly the cases where the answer matters.

The other 263 arrive on their own, from 9 GitHub topic searches with star floors between 1,800 and 6,000, categorised by rule rather than by anyone. The floors are high, and they were set against an API budget rather than a taste: the per-tool signal pass costs about nine metered calls, so a 5,000-an-hour budget buys roughly 400 tracked tools a night, and a run that reaches for a thousand stalls on a rate-limit pause and writes nothing.

No individual repository is ever removed by hand. 5 written patterns drop awesome-lists, tutorials, courses and boilerplate from what discovery returns, and they apply to everything or to nothing. There is no way to pay, ask or argue a tool onto this board, and no way to get one taken off it.

Said plainly, because a board that publishes other people’s maintenance record should be the easiest thing here to check: the verdict is untouched by human hands and the population is not entirely. Roughly a quarter of what is scored is here because somebody decided it should be.

What this does not claim

No verdict is hand graded and nothing is a submitted claim. The scorer reads a row of signals, applies the weights above, and writes back a number, a verdict and the list of facts that produced them. That list is on every tool record, so a verdict you disagree with can be argued with on the evidence rather than taken on trust.

The score is recomputable without re-reading GitHub, which matters for the honest version of the complaint every board like this attracts: when a project resumes real activity, the number moves the night after, on its own, with no appeal to file.

A verdict describes a repository’s public activity. It is not a claim about whether the software works, and a finished, stable tool can score dead and still be the right thing to install. What the board removes is the part where you had to guess. The same figures are available as JSON from the open API.