Gitropolis

Discover rising AI repositories before they become mainstream.

Gitropolis detects rising AI open-source repositories on GitHub and visualizes the ecosystem as a city.

Motivation

New AI models, tools, and frameworks emerge constantly. By the time they appear on trend platforms or media channels, however, many have already gained significant attention.

Gitropolis began with the following questions:

• What if we could discover rapidly changing AI trends earlier than anyone else and review concise summaries of them?
• What if we could quickly understand the key aspects of recently growing repositories and jump directly to their original GitHub pages?
• Instead of browsing a simple leaderboard or subscribing to a newsletter, what if we could explore changes in the AI open-source ecosystem like a captivating city at night?

Gitropolis aims to answer these questions by combining Radar, which detects rapidly growing repositories at an early stage, with City, which presents the distribution of repositories and technology categories in a spatial environment.

Overview

• Detect repositories based on Star growth velocity and acceleration rather than total Star count

• Visualize repositories as buildings and technology categories as city districts

• Use AI to summarize READMEs, technology stacks, key features, and the reasons behind repository growth

• Track growth trends and the initial detection date for each repository

• Compare detection dates with external content appearances to evaluate early-detection performance

• Provide direct links from repository summaries to the original GitHub repositories

Why Gitropolis?

Radar

Radar discovers repositories whose growth has recently begun to accelerate, rather than focusing only on repositories that are already well known.

Gitropolis looks beyond total star counts. It analyzes growth velocity, acceleration, consistency, and repository activity to detect momentum before widespread attention arrives.

City

City represents repositories as a city rather than a ranked list, revealing how technology trends are distributed and how they change over time.

A list shows which repository ranks the highest. A city shows which technology districts are growing, where new buildings are appearing, and where attention is shifting.

How It Works

1. Collect candidate AI-related repositories from GitHub.

2. Record changes in Stars, Forks, Contributors, Commits, and other metrics at regular intervals.

3. Calculate Star growth velocity and acceleration.

4. Classify repositories that satisfy growth and consistency criteria as Radar candidates.

5. Use AI to analyze and summarize repository READMEs and metadata.

6. Place buildings within the city based on each repository’s technology category and growth metrics.

7. Track when repositories appear in external content and evaluate how early Radar detected them.

City Metaphor

City Element	GitHub Data
Building	Individual GitHub repository
District	Technology categories such as LLM, Agent, RAG, or Vision
Building height	Number of Stars or growth score
Building growth	Recent Star increase and growth velocity
Lighting	Recent commit and contributor activity
Building under construction	A recently created, rapidly growing repository
Landmark	Repositories established as standards in the ecosystem
Declining building	A repository whose activity has decreased over an extended period

Design Inspiration

A special shout-out to Git City, a creative project that turns GitHub profiles and activity into an interactive city. Its imaginative approach to visualizing developer activity inspired Gitropolis’s visual direction.

Gitropolis explores that city metaphor at the repository level: repositories become buildings and AI categories become districts. This makes it possible to explore growth signals, category trends, and shifts in attention across the AI open-source ecosystem.

Target Users

• Developers and indie hackers who want to adopt new AI tools and frameworks early

• Tech YouTubers and newsletter creators who need to discover potential topics before they appear on other channels

• DevRel professionals and technology strategists who track open-source trends

• Researchers who analyze the structure and evolution of the AI ecosystem

Success Metrics

Leading Signal Precision

The percentage of Radar-detected repositories featured on major tech channels or the Hacker News front page within four weeks.

Target: 40% or higher

Average Lead Time

The average difference between the date Radar first detects a repository and the date the repository begins receiving significant coverage through external channels.

Target: 14 days or more

Lead time = External coverage date - Radar’s initial detection date

Tech Stack

The Gitropolis product core uses TypeScript. The local CLI runs on Node.js, and the web application uses Next.js, React, Three.js, and Tailwind CSS. Python is reserved for data exploration and experimental analysis.

The web MVP validates city-v1 at runtime with Zod. JSON Schema generation and runtime validation for the remaining snapshot and report formats will be added as those contracts stabilize.

The local CLI will remain runnable without Docker. If the hosted web application later requires independently deployable web, API, worker, or database services, those services will be separated with Dockerfiles and Docker Compose.

Getting Started

Environment Variables

Gitropolis can collect public repository data without authentication. To use a higher GitHub API request limit, set a fine-grained personal access token in the GITHUB_TOKEN environment variable:

export GITHUB_TOKEN="your-token"

Never commit the token or include it in Issues, Pull Requests, logs, or command arguments.

Run

Install dependencies and build the CLI:

npm install
npm run build

Initialize local Gitropolis files:

node dist/cli.js init

Collect one or more public repositories:

node dist/cli.js collect browser-use/browser-use

Without GITHUB_TOKEN, the command uses anonymous GitHub API access. When the environment variable is present, it uses token authentication. Snapshots are written under .gitropolis/snapshots/ by default. Use --output to choose a different path:

node dist/cli.js collect browser-use/browser-use \
  --output /tmp/gitropolis-snapshot.json

Discover repositories from a UTC-aligned GH Archive window without keyword filters:

node dist/cli.js discover \
  --from 2026-07-30T00:00:00Z \
  --hours 24 \
  --top 10

The command streams hourly GH Archive files sequentially, aggregates WatchEvent records by repository, enriches the highest-ranked candidates with the GitHub REST collector, and writes candidate-v1 under .gitropolis/candidates/. A 24-hour run may download roughly hundreds of megabytes. The default one-second interval and 60-second per-file timeout can be adjusted with --request-delay-ms and --request-timeout-ms.

Build a daily activity series for up to seven complete UTC days without cutting the repository set to a top-N list:

node dist/cli.js backfill \
  --from 2026-07-27T00:00:00Z \
  --days 7

The raw activity-series-v1 snapshot preserves every observed repository. Add current GitHub metadata only for repositories that meet a configurable daily activity floor. The default Main Radar screening selects repositories with at least five WatchEvent records in any single UTC day:

node dist/cli.js enrich-activity \
  --input .gitropolis/activity/FROM_TO.json \
  --min-daily-watch-events 5

Backfill and discovery validate the stable GH Archive event ID and count an ID at most once across the full command window. New snapshots report raw, unique, duplicate, missing-ID, invalid-ID, and malformed-record totals without storing the original event-ID list. The stream parser also reconstructs bounded multi-line records when a literal newline splits a JSON string, reports those records separately as recovered, and keeps only unrecoverable records as coverage errors.

For higher-recall emerging-keyword research, use a separate Scout pass that keeps repositories with at least three events across the full window and requests only description and topics:

node dist/cli.js enrich-activity \
  --input .gitropolis/activity/FROM_TO.json \
  --min-window-watch-events 3 \
  --metadata-profile screening

The screening profile makes one repository-detail request per selected repository. The classification profile also records README metadata, while the full profile additionally collects language, commit, and contributor activity. Interrupted enrichment can resume from its previous output without requesting successful repositories again.

Derive deterministic Main Radar, Emerging Scout, fast-breakout, and repository lifecycle state from consecutive activity-series files:

node dist/cli.js lifecycle \
  --input .gitropolis/activity/WEEK_1.json \
  --input .gitropolis/activity/WEEK_2.json

The command groups consecutive daily observations into Monday-based UTC weeks. It keeps Main and Scout membership separate from candidate → active → cooling → inactive, records revival as an event, and freezes unsafe state changes when calendar or hourly coverage is incomplete. Record-level warnings remain visible and block negative transitions while still allowing an observed threshold crossing to enter the Radar.

Both long-running commands print progress while preserving partial coverage and successful repository results.

Classify AI relevance and observe keywords from a candidate or enriched activity-series snapshot:

node dist/cli.js analyze \
  --input .gitropolis/candidates/FROM_TO.json

This default path uses the deterministic rules classifier. An explicit model adapter can instead classify every accessible candidate in bounded batches:

node dist/cli.js analyze \
  --input .gitropolis/candidates/FROM_TO.json \
  --model-command /absolute/path/to/json-stdio-adapter \
  --model-provider PROVIDER_ID \
  --model MODEL_ID

The adapter receives a single JSON request on standard input and returns one strict JSON response on standard output. Only the stable repository ID, description, and topics are sent; README content is never sent to the model. Successful ai-related and review decisions are enriched with README keyword observations afterward. Raw README content is not stored in the cache or output.

Model decisions default to a metadata-hash cache under .gitropolis/cache/ai-relevance-v1.json. Use --model-cache, --model-batch-size, --model-invocation-budget, and --model-max-retries to control the run. A retry consumes the invocation budget, successful partial responses are saved immediately, and a later run resumes only unresolved or changed repositories. Gitropolis does not bundle or select a model provider; the adapter owns provider authentication and cost.

Join an enriched activity snapshot, its topic analysis, and a lifecycle that covers the same window into the first renderer-ready city dataset:

node dist/cli.js build-city \
  --activity .gitropolis/activity/WEEK-enriched.json \
  --analysis .gitropolis/observations/WEEK.json \
  --lifecycle .gitropolis/lifecycle/PERIOD.json

The command writes city-v1 to .gitropolis/city/city.json. It preserves all eligible AI-related repositories and exposes TOP 5/10/25/50/100 only as renderer options. Provisional keyword rules place known broad themes into seven districts; unmatched AI repositories stay visible in frontier.

Run the Web MVP

The first interactive city lives in apps/web. Install its dependencies and start the local Next.js server:

cd apps/web
npm install
npm run dev

Open http://localhost:3000. The city supports orbit and zoom controls, district visibility filters, TOP 5/10/25/50/100 highlighting, repository selection, GitHub links, and an accessible /list view. Repository details use the current GitHub description and a deterministic Why Gitropolis noticed it summary of observed signals; they do not claim to explain why a repository became popular. Facade windows represent commits in the latest 30 days, with an explicit neutral fallback when that aggregate is unavailable.

The checked-in apps/web/public/data/city.json is the verified complete 2026-08-03 through 2026-08-10 UTC snapshot: 80 AI-related repositories from 181 selected candidates. Of those candidates, 177 were fully profiled and four were unavailable. The raw GH Archive window covers 168/168 hours, while metadata coverage remains partial and is labeled separately. The dataset is not padded or trimmed after AI classification. To inspect a newly generated city, replace the sample after running build-city:

cp .gitropolis/city/city.json apps/web/public/data/city.json

The web app validates the replacement as city-v1 before rendering it. The checked-in scale test renders buildings and facade windows as district-level Three.js instances. On the validation machine at a 1280×720 viewport and a 1.75 renderer pixel-ratio cap, the visible foreground sample held 60 FPS with a 16.7 ms median frame and 17.6 ms p95 while rendering all 80 buildings in 38 draw calls. Performance numbers are hardware- and browser-specific measurements, not a universal guarantee.

Roadmap

• Candidate GitHub repository collection pipeline
• GH Archive WatchEvent daily activity-series storage
• Star snapshot deltas and acceleration
• Radar scoring based on growth velocity and acceleration
• Filtering of abnormal one-time Star spikes
• Explainable MVP AI repository classification and keyword observation
• Renderer-ready city-v1 data contract
• AI-generated repository summarization
• First interactive Three.js city MVP
• Repository detail pages
• Links from city and list views to original GitHub repositories
• Trend analysis by technology district
• Tracking of appearances in external content
• Evaluation of early-detection accuracy
• User watchlists and notifications

Contributing

Bug reports, feature suggestions, documentation improvements, and code contributions are welcome.

We are especially interested in experiments and suggestions for improving the Radar score, growth-signal detection, and evaluation methodology.

For contribution guidelines and the Pull Request process, please see CONTRIBUTING.md.

License

Gitropolis is licensed under the GNU Affero General Public License v3.0 only (AGPL-3.0-only).

You may use, modify, distribute, and host this software under the terms of the license. If you modify Gitropolis and make the modified version available to users over a network, you must provide those users with access to the corresponding source code as required by the AGPL-3.0.

See the LICENSE file for the full license text.

Disclaimer

Gitropolis’s Radar scores and AI-generated summaries are provided as reference information to support technology discovery.

Gitropolis does not guarantee the quality, security, long-term maintainability, or suitability for real-world adoption of any featured repository.