[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fqx0cqacat9c9":3},{"code":4,"message":5,"data":6,"timestamp":37},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":16,"summary_md":17,"topic":18,"github_topics":21,"license":33,"homepage":34,"updated_at":35,"history":36},"zhuyansen\u002Fnew-term-radar",23,"Daily radar for new AI terms: names of new models, products and repos, caught on X, Hugging Face, GitHub and sitemaps before keyword tools list them.","Python",1775,545,137,13,[],"Daily radar that surfaces new AI names from X, Hugging Face, GitHub and sitemaps before keyword research tools index them.","## The problem\n\nIf you run an AI tool site, a directory or a newsletter, the value of a new name is front-loaded: the day a model or repo appears is when a page about it can rank. The usual tooling — Google Trends, keyword planners — is backward-looking by design; it confirms demand after directories and competitors have already moved in. new-term-radar tries to shorten that gap by scanning the places a name appears first and reporting it the same day, with Google Trends used afterward only as a scorecard.\n\n## What's different\n\nKeyword tools are built on search-volume history. This project inverts the pipeline: it treats a young GitHub repo gaining stars fast, a model entering Hugging Face trending, or new shared words across a directory's fresh URLs as the signal itself, and treats search data as validation. The notable piece is the keyword table: for each new name it derives the generic task-oriented phrase people would actually type, checks volume, and adds a page-one competition check, so you get a decision (`prioritize` \u002F `watch` \u002F `skip`) rather than a raw term list. A second differentiator is delivery surface — CLI, three Agent Skills and an MCP server — so the report can be consumed by an agent workflow, not just a dashboard. Its own 14-day Trends backtest is a reasonable honesty signal, though it is self-reported.\n\n## Who it's for\n\nPeople who monetize being early on AI terms: SEO operators on AI tool directories, newsletter writers, and small product teams watching for naming opportunities. It is a poor fit if you need historical search-volume analytics, broad market research, or anything enterprise-grade; it is also a poor fit if you are not prepared to spend money per run on third-party API keys.\n\n## Cost of adoption\n\nPython 3.10+, installable from PyPI (`pip install new-term-radar` appears in the README's quick start). Several signals require an AIsa key, and the README's own example configuration comes to roughly $15\u002Fmonth; GitHub, Hugging Face and sitemap signals are free, and Search Console needs your own Google token. The README is unusually detailed about costs and methodology, which is a good sign, but it is also the main source of claims — there are no third-party benchmarks. License is MIT. The project is days old, so expect API drift and breaking changes.\n\n## Verdict\n\nThe idea is sound and the execution is more thoughtful than most SEO scrapers: the name-versus-generic-keyword distinction and the page-one check are the parts that would actually save time. The project is brand new, not established — about 12 days old — and the star velocity it advertises (700+ on day one, 1,000 within three) sits alongside a fast-rising Python board position rather than any long track record or Hacker News discussion. That pattern is consistent with a launch spike; whether the daily reports stay useful after the novelty fades is the open question. Worth a trial run if you already pay for keyword data and want earlier leads, not worth restructuring a workflow around yet.",{"slug":19,"name":20},"data","Data",[22,23,24,25,26,27,28,29,30,31,32],"agent-skills","ai","aisa","claude-code","claude-skills","google-trends","keyword-research","mcp","mcp-server","seo","trends","MIT",null,"2026-10-25T02:06:00Z",[],1792912721]