Build a Daily AI Trend Radar with new-term-radar

What new-term-radar does

new-term-radar is a daily monitoring tool for discovering names that are beginning to surge in AI. It is designed to find new models, products, tools, websites, and repositories before they become visible in conventional keyword research platforms.

The project is particularly useful for people creating AI tool pages, directories, newsletters, articles, or products. Instead of waiting for established keyword volume, it watches the earlier public signals left by a new name.

1. A laboratory, developer, or influential account mentions a name on X, or a model enters Hugging Face's trending list.
2. A recently created GitHub repository begins accumulating stars unusually quickly.
3. Directories and competing sites publish new pages, or a recently registered domain begins ranking.
4. Your website receives its first Search Console impressions for the term.
5. Google Trends eventually shows a measurable rise.

Most keyword tools operate near the final stage. new-term-radar reads the first four stages daily and later uses Google Trends to review whether its early leads became genuine search trends.

Key features and signals

X account monitoring

The radar reads the accounts configured in your account list and identifies names they have not used during the previous 60 days. This paid signal requires an AIsa API key. Its usefulness depends heavily on the quality of the laboratories, developers, and commentators you choose to follow.

Hugging Face trending models

The Hugging Face signal detects models newly appearing in the trending top 50. Quantized copies are grouped under their base model name. This signal is free and requires no external credentials.

GitHub breakout repositories

The GitHub detector looks for repositories under 14 days old that average at least 200 stars per day or have gained at least 400 stars since the previous snapshot. It can also produce search variants based on the owner and repository name, such as niko strata.

This signal is free. A GitHub token is not mandatory, although using one raises the GitHub API rate limit.

Sitemap changes

The sitemap reader finds words shared by several new URLs on a site when those words were uncommon in its older URLs. It counts distinct URLs against the site's own baseline, reducing the chance that one long URL creates a false surge.

Before adding a sitemap, read the site's robots.txt and configure a pause that is at least as long as its crawl delay.

Newly ranking sites

The optional new-sites signal searches for domains registered and first indexed within the last 90 days that already rank for at least 20 keywords. It requires AIsa and is intended to run weekly.

The README notes that, as of October 12, 2026, an upstream AIsa validation problem causes this signal to report an error. The remaining report continues to work. Use --skip newsites until the upstream issue is resolved.

Google Search Console

If connected to your own property, the radar detects queries that have produced impressions for your site for the first time. This integration is optional, free, and uses a read-only token stored on your machine.

Name classification and review

A small language model scores whether each candidate is the name of one specific thing or merely a common word. Accepted names appear prominently, while common words are listed separately. Fourteen days later, the review process checks search variants in Google Trends and records the hit rate and number of days the signal was ahead.

How the keyword table works

A new product name can rise quickly without describing the durable task people want to accomplish. For example, a detector's brand name may be temporary, while a generic phrase such as ai image detector represents continuing demand. The optional keyword table connects each new name with the jobs and generic searches behind it.

1. Collect evidence: The radar reads highly liked X posts mentioning the name and, for repositories, the README.
2. Generate phrases: A model proposes ordinary search phrases for the jobs demonstrated in the evidence and includes supporting quotations.
3. Screen phrases: A second model call removes phrases that the named product does not answer closely enough.
4. Estimate volume: Google Ads monthly search volumes are fetched in one batch, and phrases below min_volume are removed.
5. Measure trends: Google Trends is used once to assess each term's shape and again to compare its size with a benchmark keyword, which defaults to gpts.

The resulting decisions are prioritize, watch, or skip. A term is prioritized when it rose within the last 30 days, is still rising, and meets the configured daily-search threshold. Smaller, early, or steadily demanded terms are watched. Fading or small flat terms are skipped.

Each name is analyzed when it first appears and again after the configured recheck period, which defaults to three days. This matters because launch-day posts often describe an announcement rather than showing how people actually use the product.

The project's initial observations found that product names rose before the associated generic terms. Treat the keyword table primarily as a map of the existing demand a new product serves, not as proof that every generic phrase is beginning to surge.

Requirements

• Python 3.10 or newer.
• Git for cloning the repository.
• An AIsa API key if you want paid signals, name classification, Google Trends review, or the keyword table.
• Optional Google, Resend, and GitHub credentials for Search Console, email delivery, and higher API limits.

The core radar uses only Python's standard library. Additional packages are needed only for optional integrations and development tasks.

Install and configure the radar

1. Clone the repository

git clone https://github.com/zhuyansen/new-term-radar
cd new-term-radar

2. Create your configuration

cp config.example.json config.json

Edit config.json to specify the X accounts, sitemaps, topics, known terms, stop words, and thresholds relevant to your site or publication.

3. Add the optional AIsa key

export AISA_API_KEY=your_key_here

Paid services are routed through AIsa, including X posts, DataForSEO-backed domain and trend data, and the model used to judge candidate names. Without this key, the free Hugging Face, GitHub, sitemap, and Search Console signals can still run. However, the report lists terms unsorted because the name judge is unavailable.

4. Run the daily report

python -m radar daily --out report.md

The first execution establishes snapshots for X vocabulary, repository star counts, and sitemap URLs. Since there is no previous snapshot to compare against, the initial report normally contains only GitHub breakouts, which do not require yesterday's data. From the second run onward, the radar can report changes across all enabled signals.

Configure the important settings

The example configuration documents all supported fields. Focus first on the settings that determine what the radar watches and how aggressively it filters candidates.

• lang: Set the report language to en or zh.
• x_accounts: Add laboratory and blogger handles. Labs tend to announce names first, while selected bloggers show how terms spread through your field.
• sitemaps: Define sitemap locations, optional shard patterns, request pauses, and locale-prefix stripping.
• topics: Assign a name and regular expression to create topic-specific report sections.
• known_terms: Add terms you already cover or never want to review. Matching leads are marked and excluded from later review.
• stop_words: Add common words from your field. The built-in list is tuned for AI models and agent tooling.
• judge: Choose an AIsa chat model and set the minimum name score, which defaults to 0.5.
• breakout: Control repository age, minimum stars, daily star velocity, and change since yesterday.
• review: Set how many days to wait before review and how many leads to process per day.
• usecases: Configure the keyword table, model, benchmark, volume threshold, daily-search threshold, and recheck interval.
• gsc: Set your Search Console property and token file, or leave this object empty to disable the integration.

To turn off the keyword table completely, set its daily count to zero:

{
  "usecases": {
    "per_day": 0
  }
}

You can also disable it for one command with --skip usecases.

Basic usage patterns

Run everything once a day

If you only want one scheduled execution, use the daily command without skipping any signals:

python -m radar daily --out report.md

The command writes the Markdown report and also creates report.json beside it. The JSON file contains the structured data used to build the report and is useful for custom publishing or downstream processing.

Check fast-moving sources several times a day

The repository separates fast source monitoring from the heavier daily process:

python -m radar sources --out sources.md
python -m radar daily --skip x,hf --out report.md

The sources command checks only X and Hugging Face and writes a report only when it finds a new name. Run it every few hours. The daily command can then skip those two live checks while including names retained by sources during the previous 24 hours.

Skip selected modules

The --skip option accepts x, hf, breakout, sitemaps, newsites, gsc, review, judge, and usecases.

python -m radar daily --skip x,newsites,usecases --out report.md

Run the weekly new-sites check immediately

python -m radar daily --new-sites --out report.md

Move persistent state

The radar depends on stored snapshots and its database to determine what changed. Use --state when you want these files in a dedicated directory:

python -m radar daily --state ./radar-state --out report.md

Understand the generated report

The report places likely names first and shows their supporting signals. A GitHub lead may include the repository, current stars, average stars per day, name score, known-term status, search variants, and a short example. Terms judged to be common words appear separately near the bottom.

The review section revisits terms reported on the configured earlier date. It records whether a search variant rose and how many days the radar detected it before the measurable Google Trends increase.

A variant counts as having risen when its post-report peak exceeds its earlier baseline by both two times and ten points. This variant-based approach helps with names that already have an unrelated meaning. A broad word may have too much historical demand to qualify, while a precise creator-plus-product query can reveal the new trend.

Add Google Search Console

Install the optional authentication dependency and run the included authorization script:

pip install google-auth-oauthlib
python scripts/gsc_auth.py gsc_client.json

The script opens a browser once and writes gsc_token.json. The input file must be an OAuth client of type Desktop app, created in a Google Cloud project where the Search Console API is enabled.

Then configure the property:

{
  "gsc": {
    "site": "sc-domain:your-site.com"
  }
}

The token is read-only, remains on your machine, and is already covered by the repository's .gitignore.

Send reports by email

The --mail option sends the report through Resend. Set the required environment variables:

export RESEND_API_KEY=your_resend_key
export EMAIL_FROM=radar@your-verified-domain.com
export RADAR_EMAIL_TO=you@example.com,editor@example.com

Install the Markdown package if you want an HTML email version:

pip install markdown
python -m radar daily --out report.md --mail

Automate it with GitHub Actions

The included .github/workflows/radar.yml workflow runs sources every eight hours and daily once per day. It stores state in the Actions cache and writes reports into the workflow run summary. The workflow remains disabled until you explicitly opt in.

1. Fork the repository. A private fork is acceptable.
2. Remove config.json from .gitignore and commit the configuration. The file should not contain secrets.
3. Add the AISA_API_KEY repository secret.
4. If needed, add RESEND_API_KEY, EMAIL_FROM, RADAR_EMAIL_TO, and GSC_TOKEN_JSON.
5. Create the repository variable RADAR_ENABLED and set it to true.

Preserving the state cache is essential because comparisons depend on historical snapshots. Without persisted state, repeated runs behave more like first runs.

Advanced tuning tips

Choose X accounts deliberately

The X detector cannot discover a term that none of the configured accounts mentions. Include organizations that announce products and trusted commentators through whom important terms spread. Reading fewer accounts or reducing the run frequency also lowers paid API usage proportionally.

Adapt stop words outside AI tooling

The built-in cleaning and stop-word behavior is tuned for AI models and agents. If you apply the radar to another field, extend stop_words with ordinary vocabulary from that domain so common terms do not overwhelm the report.

Tune breakout thresholds to your niche

The defaults target unusually fast GitHub growth. A smaller ecosystem may require lower min_stars, velocity_min, or delta_min values. A very active ecosystem may need higher thresholds to keep the report focused.

Use known terms to reduce repeated work

Add terms for which you already have pages, along with terms you never intend to cover, to known_terms. A candidate containing one of these entries, or contained by one, is marked and excluded from future review.

Do not trust the newest Trends points

Google Trends data for the most recent two days is unsettled and can create false jumps. The implementation drops those two days and requires a rise to last at least two days. Avoid changing this behavior unless you have another way to handle incomplete data.

Validate demand before publishing

The radar is an early-warning system, not a complete keyword research replacement. Google Ads volumes can lag by roughly two months, and Trends is unreliable for terms with only a few hundred monthly searches. Where estimates are available in the optional keyword table, treat them as directional. Check current search results, relevance, ownership risks, and demand before building a page.

Measure your own signal quality

The project does not claim established hit rates for every source. Its review system needs at least 14 days for each lead to mature. Use the accumulated review section to judge which signals work for your account list, topic, and market rather than assuming every candidate will become a trend.

Run the test suite

For development, install the test and Markdown dependencies, then run the tests:

pip install pytest markdown
python -m pytest -q tests

The tests cover name extraction, scoring, storage, and report generation without making network requests.

Conclusion

new-term-radar turns early public activity into a repeatable daily discovery workflow. Its free signals can monitor Hugging Face, GitHub, sitemaps, and your Search Console data, while AIsa enables X monitoring, name classification, trend review, domain research, and the keyword table.

Start with a carefully selected source list, run the tool long enough to build snapshots, and review its results after 14 days. The most valuable output is not merely a list of fashionable names, but evidence showing which sources consistently identify relevant terms before conventional keyword tools do.