Spot rising AI terms days before keyword tools do: a hands-on guide to new-term-radar

Google Trends shows you a keyword's curve days or weeks after it starts. new-term-radar reads the places a name appears first - X posts, Hugging Face's trending list, GitHub breakouts, AI directory sitemaps - and tells you about "Strata" or "Seedance" the day it appears, not two weeks later. This tutorial sets up the radar and reads your first daily report.

• Who: zhuyansen’s new-term-radar, MIT licensed; 700+ GitHub stars on its first day, 1,000 within three, over 1,700 by 2026-10-23.
• What: a daily radar over eight signals - X posts, Hugging Face trending, GitHub breakouts, site sitemaps, newly registered domains, Reddit asks, fresh payment links and TrustMRR revenue - plus Search Console and a 14-day Google Trends review.
• Breakout rule: a repo under 14 days old averaging 200+ stars a day, or +400 stars since yesterday.
• Cost: free signals (Hugging Face, GitHub, sitemaps, Search Console) need no key; one AIsa pay-per-call key runs the example config at about $15 a month ($10 for X reads, $5 for the keyword table); GoAnyAPI is optional at about $0.07 a day.
• Run it: git clone https://github.com/zhuyansen/new-term-radar, copy the config, then python -m radar daily --out report.md. Skills via npx skills add zhuyansen/new-term-radar; MCP via uvx --with mcp new-term-radar mcp.

Keyword tools are history books. They show you a search curve once a name has been searched for days or weeks - by which time the AI directories, the newsletters and the opportunistic domains have already published. A new name leaves a trail in a fixed order: a lab or a well-followed account says it on X, a model enters Hugging Face's trending list, one GitHub repo takes off on its own, directories add pages for it, someone registers a domain. new-term-radar reads steps one to four every day and uses Google Trends only to check itself.

The project, by zhuyansen and extracted from the radar running daily behind agentskillshub.top, picked up 700+ GitHub stars on its first day and 1,000 within three (over 1,700 by 2026-10-23), and it is MIT licensed. The striking part for a tool this ambitious: the radar is standard-library Python. No dependency install beyond the key libraries for the optional extras, and the free signals run with no API key at all.

What you’ll need

• Python 3.10 or newer. The core radar uses only the standard library - nothing to pip install for the basic run.
• A terminal and git.
• An AIsa API key (pay per call, no subscriptions) if you want the paid signals: X reads, the name-judge model, the 14-day Trends review and the keyword table. The free signals - Hugging Face, GitHub breakouts, sitemaps, Search Console - work without one.
• Optional: a GoAnyAPI key (about $0.07 a day) for Google Trends related queries and settled one-country curves; a TrustMRR key (free, 6 requests a week) for the revenue signal.

Step 1 — Clone the repo and copy the config

git clone https://github.com/zhuyansen/new-term-radar
cd new-term-radar
cp config.example.json config.json      # then edit: your X accounts, sitemaps, topics

The config is where the radar learns your world. x_accounts holds the lab and blogger handles whose posts get scanned for first-used names; sitemaps lists the AI tool directories and MCP/skill directories whose new pages get watched (the example watches eight tool directories and four skill/MCP directories); topics lets you carve the report into sections by name-and-regex; known_terms lists the names you already cover so they get marked, not re-reported. Keep pause at or above each site’s crawl-delay - the example config makes only a few dozen requests a day.

Step 2 — Run the free signals first

python -m radar daily --out report.md

With no AISA_API_KEY set, the free signals run: Hugging Face’s trending top 50 (new models and Spaces, with quantised copies grouped under the base name), GitHub breakouts (repos under 14 days old averaging 200+ stars a day, or +400 since yesterday), the sitemap diffs, and your own Search Console queries if you wired it up. The first run builds its snapshots - yesterday’s vocabulary and star counts don’t exist yet - so only the GitHub breakouts (which need no yesterday) are reported. From the second run on, every signal reports what changed.

A real sources run from the README shows what the output looks like: qwen image 2.1 | Hugging Face: new at #4 with a name score of 1.00, and ltx 2.5 | Hugging Face: new at #6 at 0.90. The daily report marks each term with a name score, its search variants (people searched “niko strata” from day two, while no second repo carried the name), and which terms you already cover.

Step 3 — Add one pay-per-call API key

export AISA_API_KEY=<your-key>
python -m radar daily --out report.md

Everything the paid side needs goes through one key: X posts, Google Trends and domain data, and the models that judge names and propose keyword phrases. With the example config - 35 X accounts read three times a day plus the keyword table for 5 names a day - the README prices a month at about $15: $10 for the X reads, $5 for the keyword table. Read fewer accounts, or read them once a day, and the cost drops in proportion. The two halves can also run separately:

python -m radar sources --out sources.md           # X and Hugging Face only, every few hours
python -m radar daily --skip x,hf --out report.md  # everything else, once a day

sources writes a report only when there is a new name; daily --skip x,hf lists what sources kept in the last 24 hours. Flags: --skip takes any of x,hf,breakout,sitemaps,newsites,gsc,review,judge,usecases; --mail sends the report through Resend; --state DIR moves the database and snapshots.

Step 4 — Read the report like a keyword desk

The daily report’s core is the candidate-terms table: the term, the signals that caught it, a name score, and example evidence. From a real 2026-10-12 run: gridcraft, a GitHub breakout at 3,178 stars gaining 626 a day, name score 0.95; artex, 3,353 stars at 825 a day, score 0.85. A small model scores every term - the name of one specific thing, or a common word? - and common words get parked at the bottom.

Then comes the keyword table, the part built for people who make pages: each new name is read once more, and the model writes the generic keyword an ordinary person would type for each job people do with it - “ai image detector” behind “SynthID Detector” - screens the phrases, sizes them against Google Ads volumes and Trends curves, checks room on page one, and gives a decision: prioritize (rose in 30 days, still up, enough searches), watch, or skip. A prioritize whose page one is crowded becomes watch ↓.

The 14-day review closes the loop: each lead is re-checked in Google Trends against its own baseline, and the report shows hit rates and days-ahead per signal. The one seeded check - Strata, reported 2026-09-25 - came back a hit, three days ahead of its Trends rise.

Step 5 — Automate it on a schedule or inside your agent

The repo ships .github/workflows/radar.yml, which runs sources every 8 hours and daily once a day, keeps state in the Actions cache, and writes each report to the run summary. It is off until you opt in: fork the repo (a private fork is fine), remove config.json from .gitignore and commit it (it holds no secrets), add the AISA_API_KEY secret, and set the repository variable RADAR_ENABLED to true.

For agents, there are three Agent Skills in skills/ - the full run, the listening half, and the keyword-research half - installed with:

npx skills add zhuyansen/new-term-radar

Or expose it as an MCP server. With uv there is nothing to install first - point your client at uvx --with mcp new-term-radar mcp (the plugin brings this server along; without uv, pip install "new-term-radar[mcp]" gives you the new-term-radar-mcp command). The tools are recent_leads (free, instant), keyword_table (about $0.05 a name), and run_radar (a full paid run - “the schedule belongs in cron or Actions”). The same two queries exist on the command line: python -m radar keywords "name" … and python -m radar leads.

What you built

A daily keyword radar with the same shape as the one behind agentskillshub.top: free signals that catch surging names on Hugging Face and GitHub with no key, one pay-per-call key that adds X reads and the judgement layer, a report that scores every term as name-or-common-word, and a keyword table that turns names into sized, page-one-checked decisions. The report also writes report.json beside the Markdown, so the whole pipeline is scriptable.

Honest limitations

• The new-sites signal is broken right now. As of 2026-10-12, AIsa’s validation rejects the filter format DataForSEO requires, so the signal reports an error (it worked until 2026-10-06). The rest of the report is unaffected; use --skip newsites until the upstream fix lands.
• The revenue signal is research-only. TrustMRR’s API terms forbid republishing its data and building public SEO pages from it - use the leads for your own research, don’t publish the list. The same rule holds for Reddit posts the asks signal reads: quote them, don’t republish them.
• Hit rates per signal are not proven yet. The 14-day review needs 14 days per lead and had only begun; treat any signal as unproven until your own numbers accumulate. The first pass was also fooled by Google Trends’ unsettled last two days - every reader now drops those two days and a rise must last two days to count.
• The X signal is only as good as your account list. It won’t see a name none of your accounts says. And some sources are deliberately out of reach: Facebook groups (Meta closed the API in April 2024), App Store/Google Play/Trustpilot reviews (async tasks AIsa doesn’t run), and There’s An AI For That’s request board (behind a Cloudflare challenge the radar refuses to bypass).
• Pure model releases are its weak spot. For Claude Haiku 5.5 or Nano Banana 2.1 the evidence was announcements and benchmarks, and the proposed generic phrases were weak (“ai coding assistant”). It works best on products and repos that do one job.