new-term-radar watches the days before a new AI name starts ranking

It reads the days before the curve, not the curve itself

The central claim in the README is about timing rather than about data. A new name leaves a trail in a specific order: a lab or a well-followed account says it on X and a model enters the Hugging Face trending list, then one GitHub repo takes off on its own, then directories and competitors add pages for it and someone registers a domain, then your own site gets its first search impressions, and only then does Google Trends show the curve, days or weeks later. Keyword tools read that last step. This radar reads the first four every day and uses the trends data only to check itself fourteen days later. The example it was built around is a repository called Strata, created on 2026-09-24, which had 7,700 stars nine days later, with people searching for it by name from the 26th while no second repo carried the name and no keyword tool listed it.

Six kinds of early signal, each with a different key and a different bill

The signal table is the practical centre of the project, and the cost column matters as much as the catches column. The X signal catches names that the accounts on your list used for the first time in sixty days, and it needs an AIsa key at $0.003 per account per run. The Hugging Face signal catches models and Spaces new to the trending top fifty, needs nothing and is free. The GitHub breakout signal catches a repo under fourteen days old averaging 200 or more stars a day, or up 400 since yesterday, and needs nothing beyond an optional token for a higher rate limit. Sitemap watching catches words that several new URLs share, and New sites catches domains registered and first indexed in the last ninety days that already rank for twenty or more keywords, at about $0.13 per query, weekly. The Ask signal reads what people request on Reddit, and the Revenue signal pulls verified revenue figures from TrustMRR, six free requests a week, while the Ask signal is billed weekly.

The keyword table is the actual product

Everything else feeds a single table, and the README is blunt about why. A name is half of what you need. The example given is that SynthID Detector has a short life as a keyword and belongs to Google, whereas the job it does, phrased as an ai image detector, is what people keep searching and what nobody owns. Each day the radar reads the new names once more and writes one table with both the name keywords and the generic ones, with columns for estimated searches per day, when the term started rising, its peak against a comparison, the last seven days against the seven before, what it is doing now, a page-one check, and a decision. A real run from 2026-10-12 is shown with photocraft and claude haiku 5.5 as names to prioritise, ai image detector as a generic term to watch, and photoshop alternative as one to skip.

How a keyword row is built, in five steps

The README describes the pipeline that produces the table, and the file it lives in, `radar/usecases.py`. The first step is evidence, the most-liked posts that mention the name from an X advanced search, and for a repository its README. The second is phrases, where a model reads the evidence and writes the keyword an ordinary person would type for each job it sees people doing, with a quote that backs it. A phrase built on another product's name is kept and marked, on the grounds that demand often hangs on the incumbent and whether to use someone's brand is your call. The third step is screening, where a second call scores how well the name answers each phrase, marks brands and drops the loosely related ones. The fourth is volume, from Google Ads monthly searches in one batch, dropping anything under the minimum volume threshold. The fifth is two trends reads per row.

A name judge and a page-one check decide what happens next

Two checks sit on top of the table. The page-one check asks whether there is room on the first page of results for the term, which is what turns a keyword into a decision. The name judge is a small model that scores every term on one question, whether it is the name of one specific thing or a common word, and it costs a fraction of a cent per run. A GoAnyAPI key is optional and, when present, the radar also pulls Google Trends related queries for the name, which is how it found ai photo detector, google ai detector and ai detector for SynthID Detector. Those rows carry a marker, and queries that hold the name become its long-tails, while queries that are themselves the names of other rising things are kept as leads in their own right. The keyword table is listed at about $0.18 a day for five names, or $0.30 with GoAnyAPI.

Four ways to drive it, and a standard library core

The project can be used from the command line, through three Agent Skills, through an MCP server, or through the `pains` command that 0.4 added. The packaging makes the split explicit. The project manifest defines two console scripts, one for the main tool and one for the MCP server, and the optional dependency groups are mail and mcp, so you only install the MCP extra if you want the server. The dependency situation is worth calling out because it is unusual for a tool in this category. The requirements file states that the radar itself needs only the Python standard library, 3.10 or later, with markdown needed only for the mail option and the mcp package only for the MCP server. The code lives in a `radar` directory so it runs from a clone, and the installed package is named new_term_radar because PyPI already has an unrelated project that owns the name radar. The two console scripts the manifest registers are the entry points you would actually call.

new-term-radar = "new_term_radar.__main__:main"
new-term-radar-mcp = "new_term_radar.mcp_server:main"

What a working configuration costs per month

The cost section is unusually concrete, and it is the number to plan against. The README says the prices are what AIsa charged in October 2026, and that with the example config, thirty five X accounts read three times a day plus the keyword table for five names a day, a month costs about $15, which is $10 for the X reads and $5 for the keyword table. Read fewer accounts, or read them once a day, and the cost drops in proportion. On top of that, the Trends check on leads is listed at $0.0012 per search variant, the New sites query at about $0.13 per query weekly, the Ask signal at about $0.12 a week, and the Revenue signal at six free requests a week. That structure means the dominant cost is the breadth of the X account list, not the number of names found, which is a useful thing to know before you build a configuration.

A young project with no releases and a beta classifier

The repository is not archived, and the last push was on 2026-10-14, which is recent. The project version in the manifest is 0.4.0, the classifier calls it Development Status 4 - Beta, and the repository has no GitHub releases at all, so the version history is visible in the package metadata and in the README's notes on what 0.3 and 0.4 added rather than in a release feed. The licence is MIT, the author is listed as Jason Zhu, and the keyword list in the manifest overlaps with the topics of the project itself, seo, keyword-research, google-trends, ai, mcp, mcp-server and agent-skills. The top level of the repository shows the shape of the thing: a `radar` package, a `skills` directory, a `scripts` directory, a `docs` directory, a `tests` directory, a `config.example.json` to copy, and a `server.json` for the MCP server. There is also a.claude-plugin directory, so the Agent Skills are packaged for a specific agent tool rather than being a generic convention.

Editorial conclusion

new-term-radar suits someone who publishes pages, posts or directories about new AI tools and needs the two week head start that search volume data cannot give. It does not suit a team without a budget for API keys, because the X reads, the keyword table and the Trends check all cost money, and the README puts a working configuration at about $15 a month. It also does not suit anyone who wants a scheduled service, since the project ships as a command line tool, an MCP server and Agent Skills rather than a daemon. Before you run it, copy config.example.json, add the keys for the signals you want, and read the signal table so you know which rows are free and which are billed per query.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. zhuyansen/new-term-radar on GitHub