What belongs on the radar
Tools, GitHub repos, models, papers, frameworks, packages, agents, MCP servers, local AI utilities, and practical AI projects. Company news, funding, partnerships, and policy changes live on /news/.
Trust model
Methodology
RepoRadar is an evidence-linked AI discovery radar. It ranks useful AI tools, repos, models, papers, frameworks, releases, and practical AI projects while keeping popularity, evidence, risk, and editorial verdicts visible and separate.
How items are found
Source-backed public channels: GitHub, Hugging Face, arXiv, Hacker News, PyPI, official blogs, changelogs, package pages, model cards, papers, and docs. Source defaults include cadence and freshness expectations.
Scoring firewalls
Sponsors cannot buy organic ranking, score changes, risk-label changes, verdict changes, or removal of criticism. Tips, ads, and newsletter growth never influence score, tier, rank, or visibility.
Risk and caution
Risk means inherent user-impacting hazard, not novelty. Caution flags cover not hands-on tested, setup difficulty, unclear pricing, weak docs, new or experimental, weak AI relevance, and manual review needed.
Current scoring formula
The public score follows the current implementation in radar_pipeline/public_site.py: usefulness 35%, novelty 18%, momentum 14%, maturity 10%, open-source/build quality 7%, evidence 6%, commercial/workflow potential 6%, setup ease 4%. Popularity is tracked separately from usefulness. Sponsored status, newsletter growth, tips, ads, and support links never affect score, tier, rank, risk, caution, verdict, audience, difficulty, or popularity.
How often facts are re-checked
Repository facts — stars, latest release, last push, archive status, and the momentum and maintenance labels derived from them — are observed on a stated cadence, and every value carries the timestamp of the check that produced it. Nothing is ever shown as more recently verified than it actually was.
- Daily, within 24 hours: every Gold item, anything whose repository was pushed in the last 7 days, anything added to the radar in the last 7 days.
- Weekly, within 7 days: everything else — quieter Silver and Bronze repositories with no activity for over a week, and archived projects.
An item on the weekly cadence shows an older “checked” date on its own page, which is the honest answer rather than a hidden one. A repository that becomes Gold, or that receives a push, returns to the daily cadence on the next collection; dropping to the weekly cadence requires three consecutive weeks outside the rule, so a brief quiet spell does not change how an item is treated.
Tier calibration
- Gold score ≥ 7.5 when eligible, or top eligible signal with score ≥ 7.0
- Silver score ≥ 6.5 and useful enough to browse
- Bronze useful, niche, early, or watchlist-worthy signals
- Low Signal weak, noisy, low-transparency, low-value, or weak-AI-relevance items
Gold eligibility gates
Gold requires medium or high confidence, usable/official/cross-verified evidence or better, clear public descriptions, no excluded category, no weak or unclear AI relevance, and no fallback, triage-only, weak-evidence, low-signal, or low-transparency flags.
Evidence levels
- Mentionedseen in a community, social, or directory source
- Officialsupported by official docs, changelog, model card, paper, package page, or company post
- Usablehas a usable demo, package, API, code, model, or dataset
- Verified / Testedclaims were checked more deeply or a hands-on test was actually performed and logged
What gets flagged as risk
RepoRadar flags sensitive data access, local file or document access, browser or session or cookie access, OAuth or workspace or account access, email or calendar or message sending, shell or terminal or code execution, deployment or external-system modification, autonomous action, regulated-domain claims, provenance or watermark removal, scraping or surveillance or deepfake or voice cloning or NSFW or cheating surfaces, and unknown binaries or admin installs.
Caution labels are separate from risk. They cover not hands-on tested, setup difficulty, unclear pricing, weak docs, new or experimental, weak AI relevance, and manual review needed.
Source health and review queues
The pipeline tracks operational health fields such as items seen, accepted, held back or dead-lettered, source failures, rate limits, zero-item anomalies, and review queues. Those health signals are for trust and debugging; they do not create paid placement or automatic boosts.
Published data, versions and retention
The data behind every page is published as JSON so anyone can check it. The stable entry points are:
- /data/v1/manifest.json — the release manifest: build identity, counts, coverage, and the URLs below.
- /data/v1/schema.json — JSON Schemas for items, changes, snapshots, history and the manifest.
- /data/v1/changes/stream.json — the change stream, split into bounded shards listed in its index.
- /data/v1/snapshots/index.json and /data/v2/snapshots/index.json — one daily snapshot of every tracked item.
- /data/v1/history/index.json — per-item history built from those daily snapshots.
- /data/v1/observations/index.json — the source observations that individual facts point back to.
Format versions
Daily snapshots dated before 2026-10-02 are single files under /data/v1/snapshots/<date>.json. From 2026-10-02 onward each day is written as /data/v2/snapshots/<date>/index.json plus numbered parts; each row inside a part keeps the v1 row schema, only the container changed. The day index lists part_count and each part's row count and sha256, and readers in this pipeline refuse a day whose parts do not match, so a partial download cannot be mistaken for items disappearing. Earlier days were not converted: the v1 snapshot index keeps listing them, and the v2 index lists the sharded days.
Retention
A published daily snapshot is never rewritten. A release check compares every past-day snapshot and change archive with the previous release and refuses the release if any of them was changed or deleted. There is no pruning policy for these dated files today; if one is ever introduced it will be published on this page before any data is removed. Days on which no snapshot was captured are not back-filled with invented data; they are listed as gaps in snapshot_missing_dates in the manifest.
Size limits
The hosting platform rejects any single file over 25 MiB, so releases fail if any file exceeds 20 MiB, and snapshot parts are sized against a 4 MiB target. That operational limit is why snapshots and the change stream are split into parts.
Found a data error? Use the correction route.
Editorial independence
Sponsors cannot buy organic ranking, score changes, risk-label changes, verdict changes, or removal of criticism. Financial support does not buy ranking, coverage, score changes, risk-label changes, verdict changes, visibility, popularity, or editorial treatment.