How Crest of Tech measures movement.

A repository becomes visible to Crest of Tech when it has more than 500 stars on GitHub. At 500 or below it is not tracked at all: there is no candidate pool, no “emerging” lane, no reconsideration list. The next daily sweep finds it and evaluates it once.

The relevance check

Passing 500 stars makes a repository eligible, not admitted. Plenty of popular repositories are not technology projects: link collections, roadmaps, interview preparation, cheat sheets, free-book indexes, course material. Admission needs positive evidence of software, read from the search result itself with no extra requests:

• Rejected outright: forks that have not diverged from their parent, empty or disabled repositories, and names or descriptions that match the non-technology patterns above.
• Admitted: at least one strong signal of software, such as a topic that matches a category rule, a package manifest or build configuration, or a classification as software, library, tool or infrastructure.
• Uncertain: one grounded question to a language model, constrained to those four kinds plus “not technology”. It cannot admit anything the pattern list rejected outright, and it produces no score.

Admission runs on change, not daily. Each repository stores a fingerprint of what the gates read; the sweep re-evaluates only when that fingerprint changes.

Leaving the catalog

A repository leaves when it has been below 475 stars for 14 consecutive days. The gap stops a project hovering around 500 from leaving and re-entering every day. Archived repositories are labelled and no longer swept. Nothing is deleted: a dropped repository keeps its row and its full history, and one that climbs back above 500 is re-admitted to the same row with its history intact.

One sweep at 02:00 UTC observes every catalog repository. For each one it writes one row per UTC day: stars and forks. The row is written even when nothing moved, so a quiet project is never mistaken for one with too little history. Scoring runs at 03:30 UTC over those rows; the latest release date is refreshed weekly.

Current state (description, language, licence, topics, last push, last release, archive status) is overwritten on every observation and answers “is this alive?”. Its history is not kept because nothing reads it. Not stored at all: watcher counts (a duplicate of stars), the open-issue history, and contributor lists.

Absence is trusted only from a complete sweep. If any window of the search failed, nothing is dropped on that day.

7, 30 and 90-day change

Stars today minus stars that many days ago. When a day is missing, the last observed value is carried forward; when no reading exists for the baseline day, the change is null.

30-day growth

The 30-day change divided by the star count 30 days ago, with a floor of 500 (the entrance rule) so small denominators cannot inflate it.

Velocity

A 7-day exponential moving average of the daily change, in stars per day. Smoothing keeps one viral afternoon from reading as a trend.

Acceleration

Today’s velocity minus the velocity a week ago, in stars per day per day.

Trajectory

Accelerating when acceleration and velocity are both clearly positive · Growing when velocity is positive and acceleration is near zero · Flat when velocity is near zero · Declining when velocity is clearly negative. “Clearly” and “near zero” are thresholds relative to the repository’s own typical daily change, not fixed numbers: five stars a day means something different at 1,200 stars and at 60,000.

Trending score

Computed within a cohort of peers: the same primary category and the same size band (501–999 · 1,000–2,499 · 2,500–4,999 · 5,000–19,999 · 20,000+). Velocity, acceleration relative to velocity, and 30-day growth are each turned into a robust z-score against the cohort’s median, clamped, and blended with fixed weights. A 700-star project is never ranked against a 60,000-star one. Cohorts too small to compare fall back to the parent category, then to the size band alone. Archived repositories, forks and dropped repositories keep their scores but do not shape a cohort.

Every score is a pure function of the stored history and a versioned configuration. A formula change is a new version, computed alongside the old one and compared before it is switched on, and any served score can be recomputed and checked.

History starts the day a repository is first observed; nothing is backfilled or estimated. Until a value can be computed it is shown as Collecting, with the day it becomes available. Days count from the first catalog-wide snapshot, including that day.

Swipe for all columns →

Daily collection of the current catalog began OCT 2. The dates above follow from it and are the same dates the “Collecting” cells show.

Packages are an adoption layer on the same taxonomy, not a mirror of eight registries: npm, PyPI, crates.io, Maven Central, NuGet, RubyGems, Packagist and Go Modules. Each registry publishes one adoption figure, in its own unit and its own window, and that figure is the one shown.

Swipe for all columns →

Go’s figure is pkg.go.dev’s “imported by”, measured on the module’s most-imported package. A module’s root package often has no importers of its own: the root of client_golang has none, while its /prometheus package is imported by tens of thousands. PyPI publishes no download count, so none is shown for a PyPI package anywhere on the site.

Registries are never compared on raw downloads. A month of npm downloads, a quarter of crates.io downloads and a lifetime of NuGet downloads are different quantities. “Most adopted” ranks each package by its percentile within its own registry, shown as a band: “Top 1% on npm”.

Every number says where it came from

Observed

Published by the registry. A genuine zero is shown as 0.

Derived

Calculated by Crest of Tech from observations: growth, and the percentile within a registry.

Collecting

The registry publishes the figure, but there is not enough history yet. Shown as “Collecting history”.

Not published

The registry does not publish the figure at all. Shown as “Not published by PyPI” (or the registry concerned) and never as a zero, a sample or an estimate.

Growth is derived, never stored

Growth over 7 days, 30 days, 90 days or a year is the latest observation of the registry’s own figure against the observation nearest the start of the period, which must fall within a tenth of the period (at least a day). Without one, the period is still collecting. It is always shown with its period: “+25.0% · 30d”. A start of zero has no ratio, so the absolute change is shown instead.

Refresh, and how history is kept

Every package is re-read on one of three tiers, set within its own registry:

• Tier A, daily: the top 5% of its registry, the fastest movers (the top 5% by trending), or the headline package of a repository with 50,000 stars or more.
• Tier B, weekly: released within the last year, or in the top half of its registry.
• Tier C, monthly, or sooner when its linked repository publishes a release.
• npm is read differently: download counts are read daily for every package, in bulk, and metadata and dependencies are refreshed weekly in tier A, fortnightly in B and monthly in C.

History is compressed as it ages: one observation a day for 90 days, one a week up to two years, then one a month. Charts therefore sit on a time axis, and a line joins two points only when they are as close as that schedule keeps them.

What enters the catalog

A package enters for one of two reasons, and the catalog records which:

• Its own metadata points to a repository in the Crest catalog (more than 500 stars), and it has released in the last three years. At most ten packages enter this way per repository. Where the registry publishes a download figure, it must also show minimal real use (1,000 npm downloads a month, 1,000 crates.io downloads in 90 days, 10,000 all-time on NuGet, RubyGems and Packagist), and a Go module entering this way needs 10 importers on its most-imported package. That keeps out repackaged copies whose metadata names the upstream repository.
• It clears its registry’s adoption bar, in that registry’s own unit: on npm, the high-impact list or 4 million downloads in 30 days; on PyPI, the top-pypi-packages list of the 15,000 most downloaded projects, which decides entry only and is never shown as a figure; 250,000 crates.io downloads in 90 days; 10 million all-time downloads on NuGet; on Packagist 1 million plus 10,000 a month; Go modules whose most-imported package is imported by 1,000 others.
• Linked only, for now: Maven Central publishes no downloads, and RubyGems is linked-only by decision, so artifacts and gems enter only when they are published from a repository in the Crest catalog.

Deprecated, yanked and placeholder packages never enter. These entry rules are approved and versioned (currently entry@1.1, which added the minimal-use floor for linked packages): changing a bar means publishing a new version.

Whether the catalog is being kept (packages by entry reason and refresh tier, history coverage, the last successful run of each job, failures, and the requests and errors each registry returned) is published on the Registry health page.

Sources and attribution

• Each registry’s own public API, for metadata, versions and the adoption figure.
• Repository-link candidates come from deps.dev (Open Source Insights, Google), licensed CC BY 4.0. Each candidate is verified against the package’s own metadata before it is linked.
• The PyPI entry list is top-pypi-packages by Hugo van Kemenade, data licensed CC BY 4.0. It is used only to decide which PyPI projects enter; its download counts are not stored or shown.
• The npm entry list is npm-high-impact by Titus Wormer (MIT).

One taxonomy files everything: repositories, packages and news use the same categories, so “what is happening in AI agents” has one answer across all three. It has three levels and never more: domains (such as AI & Machine Learning), categories within them (AI Agents) and subcategories within those (Coding Agents). Today it is version 2: 30 domains, 18 categories and 3 subcategories.

Membership, not just a primary

An item can belong to several categories. A repository is a member of every category it is assigned to with enough confidence (up to six), and of everything above them: a coding agent counts in Coding Agents, in AI Agents and in AI & Machine Learning. A category counts each member once, however many of its assignments fall beneath it, so its page lists every member, not only the items filed there first.

The strongest assignment is the item’s primary category. It is shown first, and it sets the peers a repository is compared with for its trending percentile.

Confidence, and what “tentative” means

Every assignment carries a confidence between 0 and 1. Rules come first (GitHub topics, keywords in the name and description, dependencies); a language model is asked only about what the rules could not settle, may choose only existing categories, and on its own never reaches the trusted band. Three bands follow:

• Trusted, 0.75 or more. Listed, counted, and used for a category’s momentum, such as the stars its members gained this week.
• Tentative, 0.5 to 0.75. Listed and counted, and marked “tentative” on the item’s page, but left out of momentum. It is a reasonable match that a stronger signal has not yet confirmed.
• Below 0.5: not a member. An item whose best assignment falls here stays uncategorized and is held for review. Nothing is forced into a category to make the coverage look complete. (Below 0.35 an assignment is not kept at all.)

The share of each dataset in each band is published on the Categories page.

News has two dimensions

A news event has a topic, which is where it sits in this taxonomy, and an event type, which is what happened: Launch, Update, Funding, Acquisition, IPO, Partnership, Earnings, Leadership, Layoffs, Shutdown, Security, Outage, Research, Regulation or Engineering. An event can carry up to three topics, primary first, at the same confidence bands. A category’s news lists every event with any of its topics in that category or beneath it, and the two dimensions filter independently.

How the taxonomy grows

Once a week, a discovery job reads the data for concepts the taxonomy does not have yet: the GitHub topics on catalog repositories and the technologies named in news events. Languages, platforms, company names, promotional tags and anything already mapped are ignored. A concept qualifies with about 50 repositories, or 30 repositories and 10 news events in 90 days.

• A qualifying concept is watched. One that holds the bar for three consecutive weekly runs is proposed as a new subcategory, with a suggested parent: the category that already holds at least half of its repositories.
• A concept that sits 80% inside one existing subcategory is flagged as another name for it rather than proposed as a new category.
• A proposal is invisible on the site until a person publishes it.

A person decides, and every change is on record

Nothing automated publishes. A person publishes a proposal, and only a person renames, moves, merges or retires a category, or overrides an item’s categories (an override outranks every automatic source and survives reclassification). Each structural change creates a new taxonomy version and an audit entry recording who made it and why; the list is public on the Categories page. When two categories are merged, the old name becomes an alias and its address redirects permanently to the category it joined, so existing links keep working.

News on Crest of Tech is a list of events, not articles. One real occurrence (a launch, a funding round, an acquisition, a breach, a ruling) is one event, however many sources reported it, and it gets one row, one classification and one summary, with every source listed on it. The aim is the important technology and digital-business events only. General news is excluded: politics without a technology angle, sports, entertainment, deals and gift guides, product reviews, general markets, and opinion that reports no event.

The sources are a fixed, curated list of official company and engineering blogs, technology and business-of-technology publications, and community link sites. It is not a crawler, and adding a source is a data change, not code. The live count is on the home page.

Deduplication comes first

Every new article is attached to an existing event, or starts one, before anything that costs money runs. The rules are deterministic, strongest first: the same canonical link; a community submission pointing at an article already held; or a near-identical headline within 48 hours (two release posts that differ only in a version number stay separate events). Only a narrow ambiguous band is put to a language model, as one yes-or-no question. An article belongs to exactly one event, and grouping never merges or deletes an article. So six sources reporting one acquisition cost one classification and one summary, not six of each.

One cheap classification

Each event then gets one inexpensive AI call that reads its material once and returns five things: up to three topics, primary first (existing categories from the same taxonomy as repositories and packages, or none; it may not invent one, see Categories); the event type (Launch, Update, Funding, Acquisition, IPO, Partnership, Earnings, Leadership, Layoffs, Shutdown, Security, Outage, Research, Regulation or Engineering, or none); the companies and technologies involved, kept only when the name appears in the event’s own material; the country, only when the material names it; and whether the event is about technology or its business at all. An event that fails that relevance check is excluded, never shown, and never pays for a summary.

A second check for the same story in other words

Different outlets word one story differently, so headlines alone miss most of the overlap. Once an event’s companies and technologies are known, it is compared with events published in the last 48 hours that come from another source, involve the same company or technology and overlap in headline. A language model answers one yes-or-no question for each of the closest few. If it is the same event, the new report joins the existing event and no summary is paid for it. The hourly pass runs the same check again.

One summary per relevant event

A second call writes the brief, once per event and from all of its coverage: a short summary, two to five key facts, and why it matters. It is marked as AI-written wherever it appears. The model may repeat any number, date, version or multiplier that is in that material and may not introduce one. Every figure in every field is checked against the sources; a single unsupported figure discards the whole brief, and the event is published without a summary. No summary is fine. An invented figure is not. An event is summarised again only when its coverage grows by at least two more independent sources within 72 hours, and never more than twice. If the AI is unavailable, events are published marked “Unclassified” rather than held back, and are classified when it returns.

Cadence

• Every 15 minutes, each source is fetched (a conditional request, so an unchanged feed costs nothing).
• Immediately after a fetch, what arrived is grouped into events, classified, checked, summarised and published, and ranked so it can appear under “Most important” at once.
• Hourly, events the first pass could not join are merged (now with the extracted companies and technologies as shared evidence, and by the check above), source coverage is refreshed, and events whose coverage grew are re-summarised within the limits above.
• Daily, rankings are refreshed, company and technology names are re-checked against the material, the related Crest repositories and packages are recomputed, and excluded events past the 90-day horizon are removed.

Ranking and coverage

An event’s score adds five parts, each stored on its own so any rank can be explained: recency (decaying over roughly 36 hours), source quality, coverage, the confidence of its primary topic, and the importance of the companies and technologies it names. Coverage counts distinct sources, so three follow-ups from one outlet count once. “Most covered” sorts by distinct sources; “Emerging” by sources per hour since the first report, an event being picked up right now. The AI sets no score. News has no trajectory: an event does not accumulate a counter the way a repository accumulates stars.

Related repositories and packages

The repositories and packages shown on an event are matched by rule, never by AI: a repository linked in the coverage; a named technology that is a tracked repository or package, with evidence such as an official home or a company the event names; or a named company’s own project for a technology the event is about.

What is kept: the copyright boundary

Crest of Tech does not republish articles. For each article it keeps the title, the canonical link, the source, the author where given, the dates, and an excerpt of at most 300 characters and at most a fifth of the text, preferring the description the publisher put in its own feed. Article bodies are not kept: they are read in memory to classify and summarise, then discarded, and the read API never serves one. The summary is Crest’s own text about the event, and every event page ends with links to the original reports.

A technology is something a developer chooses, adopts or builds on, with a name of its own: a language, runtime, framework, library, protocol, standard, product, hosted service or model. Each one has a page that brings together its repositories, packages and news.

The catalog is curated, not inferred

Measured on the whole dataset, automatic discovery is not accurate enough to publish: plain words such as “uuid” or “sandbox” look like technologies, while real ones hide behind aliases (“golang”, “nextjs”, “postgresql”). So the catalog is a reviewed, versioned list. Each entry declares its name, kind, company, aliases, official repositories, its own packages and its categories. A concept or a domain (“machine learning”, “database”) is a category, not a technology. A release of software (“etcd v3.7”) rolls up to the software. A model generation with its own identity (GPT-6) is its own technology with a parent (GPT). An alias that is also an ordinary word is matched only as a whole repository topic, never in free text without a qualifier.

Additions are approved, never automatic. A daily candidate report, deterministic, with no model and no external request, lists names Crest’s own data suggests: repository topics with independent signs that they name a technology, popular packages no technology covers, and names in the news. Each comes with its evidence. It lists only candidates that are new or whose evidence changed, so a quiet day is an empty report, and it marks a name in several news events within 48 hours as urgent (a model launch), so its page can exist while it matters. A candidate is added only when it is approved into the catalog; nothing on the candidate report is published.

Every link says why it exists

Swipe for all columns →

“Is” and “ecosystem” packages are never added together. React’s page lists react and react-dom as React, and the thousands of libraries that depend on them as its ecosystem: two numbers, each with its own meaning. Links are rebuilt from scratch every day from the catalog and the data.

Momentum: 5 signals, never estimated

Official repository stars

Star growth of its official repositories over 30 days, as a ratio. Needs daily repository snapshots 30 days apart.

Member repository stars

Star growth of its member repositories over 30 days, as a ratio. Same history requirement.

Package adoption

Growth of its own packages’ adoption over about 30 days, computed per registry in that registry’s own unit, then averaged as ratios. Registries are never summed, and a registry that publishes no adoption figure (PyPI, Maven Central) contributes nothing.

Open models

Growth of its official models’ downloads on Hugging Face over 30 days, over the models Crest observed 30 days apart (see Models). Derivatives do not count toward it. A technology with no official model has no such signal.

News

Events that mention it in the last 30 days against the 30 days before, on a logarithmic scale, once there are at least 3 events across the two windows.

The signals have different units, so they are never added. Each one is ranked as a percentile among the technologies that have it (ties share their rank), and momentum is the mean of a technology’s percentiles, on a scale of 0 to 100. It is published only when at least 2 signals have history. A signal without enough history is null, not zero, and is left out rather than estimated; a technology with fewer shows each signal on its own and no single number. Every page shows each signal separately, with its value and percentile, so a score can always be taken apart.

A daily snapshot records each technology’s counts and signals, so its history can be charted. It is an observation of the aggregate, recomputable from the repositories, packages and events it summarises. How much of the catalog each link and signal reaches is published on the Registry health page.

Versions

The catalog and the momentum formula each carry a version, both currently tech@1: the catalog version names the reviewed list, the scoring version the formula above. A rule is changed by publishing a new version, never in place, and the technology pages state the versions they show.

Models are open AI models published on Hugging Face: language, vision, speech and embedding models whose weights anyone can download. Closed models are not on the Hub; their technology pages rest on news. The Hub’s public API is read once a day, with no credential.

What enters the catalog

A model enters under a reviewed, versioned entry rule (currently model@1), by either of two routes, and the catalog records which:

• Adoption: at least 100,000 downloads in the last 30 days, as the Hub counts them.
• Trending: in the Hub’s top 200 trending, with at least 100 likes, so a new generation is admitted in its first days, before downloads accumulate.
• Never: test and CI fixtures (internal testing accounts, tiny random models), however often they are downloaded: they are machinery, not adoption.

A model that no longer meets the rule keeps its page and its history, marked as no longer in the catalog; a model the Hub stops serving is marked dropped. Neither is deleted, and neither is counted in any list or momentum.

Downloads and growth

The figure shown is the Hub’s own rolling 30-day download count. The Hub publishes no history of it, so growth over 7 or 30 days is derived from Crest’s own daily observations a period apart (within three days). Until two such observations exist the growth reads “Collecting”, never zero and never estimated. Likes, licence, gated access and the parameter count are shown as the Hub gives them, or “Not reported”.

Official models and derivatives

A technology declares the Hugging Face prefixes of its official models in the reviewed catalog (Gemma’s official models are published as google/gemma*). A derivative is a model that declares one of those official models as its base model on the Hub: a quantization, a fine-tune, an adapter or a merge. Derivatives are credited only through the base model they declare, never by their name, so a re-upload named after a family that declares nothing is not counted. Derivatives are counted within the catalog, not across the whole Hub.

The models momentum signal

For a technology with official models, the signal is the 30-day growth of those models’ downloads, over the models Crest observed 30 days apart. Like every signal it is ranked as a percentile among the technologies that have it (see Technologies). It is available once daily observations reach back 30 days; until then it reads “Collecting”, and for a technology with no official model it does not apply. How complete and fresh the model catalog is, is published on the Registry health page.

The language model explains. It may classify a news event (topics, event type, companies, technologies, country and relevance), summarise an event from its sources, classify an ambiguous repository into an existing category, settle whether two articles report the same event, and repeat a figure that appears in its source material.

It never measures. It may not invent a number, date or measurement; determine a trajectory, a trending score or any ranking input beyond a confidence-carrying classification; alter a historical value; create, publish, rename, merge or retire a category; or admit a repository the deterministic rules rejected.

This is enforced in four places, none of them a convention:

• Database. The AI worker connects with a role that has no permission to write metric, score, rank or rollup tables. A violation is a permission error, not a wrong number in a chart.
• Code. The AI and scoring modules may not import each other; the build fails if they do.
• Output. Every response is parsed against a schema with allow-lists. Values outside them are discarded and logged, never coerced.
• Numbers. The figure check described above, on every field of every event summary.

Every call is logged with its model, prompt version, input hash, tokens and cost, and the same input is never paid for twice.