GitHub search built for
developers, not search engines.
Finding the right open-source library is hard. GitHub keyword search returns the most starred results — not the most relevant ones. You end up sifting through abandoned projects, wrong languages, and repos that match three words in your query but miss the point entirely.
RepoRadar takes a plain-English description of what you need and returns a ranked, evidence-backed shortlist. Every score is computed transparently, every result is explained, and you can judge the reasoning yourself.
Keyword search returns starred, not relevant
GitHub ranks by stars. You need fit.
No signal on whether a project is maintained
Stars don't tell you if it was last touched in 2021.
No way to surface underrated gems early
New quality projects get buried behind incumbents.
How a search works
Six stages from your prompt to a ranked shortlist — each one adds signal, strips noise.
Intent extraction
Your plain-English query is enriched by an LLM into a structured set of constraints — language, project type, features, and orthogonal search aspects — so even short prompts produce precise results.
Multi-axis GitHub search
Up to 8 diverse GitHub search queries are generated from the constraints. Each strategy targets a different angle (feature keywords, topic tags, description phrases) to maximise candidate recall without blowing the API budget.
Embedding funnel
Candidates are narrowed with local ONNX embeddings (all-MiniLM-L6-v2, 384-dim, runs in-process). Each repo is scored against every aspect of your query using a conjunctive formula — a repo that misses any axis sinks, regardless of how well it scores on the others.
GraphQL enrichment
The top survivors are batched into a single GitHub GraphQL query that fetches README, manifests, releases, issue health, and contributor data in one round-trip. This evidence is what the scoring engine reads.
Deterministic scoring
Fit, Future, and Underrated scores are computed in code — no LLM black-box. Each component is a weighted sub-score derived from the enriched evidence, so the same repo always produces the same numbers.
LLM explanation
A fast, cheap model writes a 1-sentence rationale for each result — why it fits, what it's missing, what risks exist. The numbers come first; the prose adds colour, not decisions.
Cold searches typically complete in 60–70 seconds. Warm searches (where candidates and enrichment data are cached) are significantly faster.
Scoring criteria
Three scores, each deterministic and code-computed. No LLM decides the numbers.
Measures how closely a repository matches what you described — combining embedding similarity, explicit feature overlap, language match, and constraint satisfaction.
Estimates how likely a repository is to stay useful — based on activity recency, release cadence, issue/PR health, contributor diversity, and star velocity. Risk penalties apply.
Surfaces strong projects that haven't hit mainstream attention yet. A high Fit and Future score with lower popularity and recent growth momentum pushes this score up.
Design principles
The decisions behind the architecture.
Fast by default
Local ONNX embeddings, batched GraphQL, and a cheap LLM for scoring keep the full pipeline under 35 seconds on cold searches.
Explainable scores
Every number is computed in code, not inferred. The same inputs always produce the same score, so you can reason about the ranking.
No black boxes
The LLM is used only for intent enrichment and one-sentence rationales. The ranking itself is deterministic and auditable.
Aspect-aware ranking
Multi-facet queries are decomposed into orthogonal aspects. Missing any single axis tanks the score — so results satisfy all of your criteria, not just the loudest one.
Ready to find what you need?
Describe a repository in plain English and get a ranked, evidence-backed shortlist.