OpenWeight Radar
Tracking newly released open-weight AI models you can run locally, with a scheduled news feed.
How this was measured: Classification logic is locked by a 40-fixture regression gate; source health reported separately.
- INGEST
- zamanlanmış toplayıcı
- kaynak listesi
- CLASSIFY
- sınıflandırma40 fixture
- STORE
- veri tabanı
- SITE
- statik sayfalar
Problem
Open-weight model releases arrive from many sources, in inconsistent naming and metadata. A simple scraper produces a feed where the same model appears three times and a category is guessed by keyword.
The real risk is silent misclassification: the feed looks fine while half the models sit in the wrong tab.
Constraints
- Ingest runs on a schedule (GitHub Actions), so failures must be visible without a server to watch.
- Classification must be deterministic enough to regression-test.
- Source health (which upstream is broken) must not be confused with feed quality.
Architecture decisions
Classification locked by fixtures
40 fixtures pin the classifier: a change that moves a model between categories fails the build.
Cost: Every rule change needs fixture updates.
Source health reported separately
A broken upstream is shown as a source health issue, not silently dropped from the feed.
Cost: More surface in the UI.
Scheduled ingest, no server
GitHub Actions runs the ingest; the site stays static and cheap.
Cost: No real-time updates; schedule latency.
Proof
- Test files27
- Source files154
- Classification fixtures40
- StatusLive
Known limits
- Classification is heuristic; unusual releases can still land in the wrong category until a fixture is added.
- Coverage limited to sources the ingest knows about.
What I learned
For a feed, the useful test is not "does it render" but "does this model land in the same tab tomorrow". Fixtures turned a subjective classification into a build failure.