Should I vibe code
Alerts you the minute a new frontier AI model goes live
A watcher that has cried wolf twice is a watcher you have muted — which is the same as not having one.
?
Their verdict, the The Call price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
This is a cron job that hits four /v1/models endpoints, diffs the response against last time, and pings you when the set changes. There is no user but you, nothing is published, nothing is sent to a stranger, and the worst outcome is that you find out about a model release from the same timeline as everyone else. Build it. Just be clear-eyed about which part is actually the product: the poller is an hour and the trustworthiness is the rest of your life. Model lists churn constantly for reasons that are not launches — dated snapshot aliases, preview renames, region-gated rollouts, endpoints that briefly return a model that is not callable yet — and a watcher that has woken you twice for `-preview-2` is a watcher you have muted. The paid tiers are not selling detection either; they are selling an escalation path, which is Twilio plus quiet hours plus per-model routing plus somebody caring at the weekend.
What actually breaks
not "if". the specific failures.
- Signal-to-noise, which is the whole product. A model list that gains `gpt-x-2026-08-04` and loses `gpt-x-2026-07-11` has not launched anything, and the naive diff cannot tell
- Coverage, because the announcement and the API do not arrive together — some models are on a blog post for two days before the endpoint answers, and some sit in the list under a codename before anyone writes about them
- The API keys you are storing to do the polling, which are billing-attached credentials sitting in a cron environment for a feature that only needs to read a model list
- Region and account gating, where the model exists for a tier you are not on, so your watcher is silent while your timeline is not
- The silent-failure mode, which for a monitor is the important one: an expired key, a 403 or a changed response shape leaves you with a watcher that has been reporting "no news" for six weeks
- The free-tier hosting, because a scheduler that sleeps after fifteen minutes of inactivity is not a scheduler
- The delivery channel, once you want it to actually wake you — SMS, quiet hours, per-model routing and escalation is where the sitting turns into a weekend
Is that you?
the verdict is a default, not a law
- It is for you, it posts to a Slack or Discord webhook, and being an hour late costs nothing
- You are diffing structured model lists rather than scraping marketing pages
- The API keys it uses are scoped to their own project with a spend cap, and rotating them is one command
- You would be equally happy with a daily digest, which removes the entire alerting problem
- You are going to sell the alerts, at which point someone else's launch-day depends on your cron job
- It texts or calls other people, because unsolicited automated SMS and voice calls are a body of law you did not sign up for
- The poller holds a production API key with your organisation's full spend behind it
- You need it to be right on the first sweep — being second by twenty minutes is the normal outcome and it has to be acceptable
If you build it anyway
the checklist, then the prompt that enforces it
- Use a dedicated project and a dedicated key per provider, read-scoped where the provider allows it, with a hard spend cap. A key that only lists models should never be able to spend money.
- Diff on a normalised model identity — strip dated suffixes and known alias patterns — and keep the raw response so you can improve the normalisation without losing history.
- Classify before you alert. New family, new snapshot of a known family, rename, and disappearance are four different events and only one of them deserves a phone call.
- Add a heartbeat: the watcher reports that it ran, and you get told when it stops. A monitor that fails silently is worse than none, because you believe it.
- Store every sweep, not just the changes. The interesting question a week later is always "when did this first appear", and only the history answers it.
- Back the API poll with a page or feed watcher for the providers that announce before they ship. changedetection.io does this part well and you do not need to write it.
- Rate-limit yourself and honour 429s with backoff. Polling four providers every sixty seconds forever is the kind of traffic that gets a key blocked.
- Keep alerting one webhook away from swappable. Slack today, ntfy tomorrow, Twilio only if you genuinely want to be woken.
I want a watcher that tells me when a new AI model appears. Keep it small, and treat
false alarms as the primary bug rather than a nuisance.
1. Start with credentials: one dedicated API key per provider, in its own project,
with a spend cap, read scope where offered, loaded from the environment. Never
commit a key and never log a response header.
2. Poll the providers' model-list endpoints and persist every raw sweep with a
timestamp before comparing anything. The history is the asset; the diff is
derived and can be recomputed.
3. Normalise model identity before diffing — strip dated snapshot suffixes and known
preview or alias patterns. Keep the rules as data I can edit, not buried logic.
4. Classify each change as new-family, new-snapshot, rename or removal. Only
new-family may be noisy by default. If I ask to alert on every diff, tell me
plainly what that does to my willingness to read the alerts.
5. Alert once per event with a dedupe key, and never re-alert for the same key even
if the list flaps. Assume it will flap.
6. Add a heartbeat recording each successful sweep, plus an alert if none has
happened in an hour. A watcher failing silently is the failure I actually care
about — write that check before any dashboard.
7. Treat provider errors separately: 401 means the key died, 403 means account
gating, 429 means back off. None of them may look like "no new models".
8. Delivery goes through one swappable interface, webhook first. Do not wire up SMS
or phone calls unless I ask, and if I do, warn me that automated calls and texts
to anyone other than me are regulated.
9. Run it on something with a real scheduler, and say so if you are about to suggest
a free tier that sleeps.
10. Out of scope: a web UI, accounts, anything resembling a public service. This
watches for me. The 2am phone call with quiet hours and per-model routing is
what the $19.99 tier is actually selling.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
If what you want is a phone call. The free tier already covers the honest DIY case — email and browser notifications about fifteen minutes behind — so the $12 and $19.99 tiers are buying escalation: SMS, automated voice, per-model routing and quiet hours, run by someone who is awake at the weekend. Rolling that yourself means Twilio, a quiet-hours schedule, dedupe that survives flapping, and a monitor for your monitor. If a Slack ping at some point during the morning is fine, build it and keep the twenty dollars.
There is barely anything to exit. Point the webhook somewhere else or delete the repository — but before you do, rotate the provider API keys the cron job was holding, because they are the only thing here with any value. The sweep history is worth keeping as a JSON file if you have accumulated any; it is the part you cannot regenerate, and it is genuinely useful for answering when a model first showed up.
Open-source database of AI models, providers and pricing, published as an API — the data layer a DIY watcher can diff against instead of polling everyone directly.
Self-hosted page-change monitoring with notifications, which covers the announcement pages and docs that no API will tell you about.
Questions
Isn't this just a cron job and a diff?
Yes, and that is why the verdict is SHIP IT. The thing worth knowing before you start is that the cron job and the diff are the easy 10%. Model lists churn for reasons that are not launches, so the work is in deciding which changes deserve your attention — and every hour you spend on that is an hour spent on exactly what the paid product sells.
Why does polling need API keys at all?
Because most providers' model-list endpoints are authenticated, and what you get back depends on your account tier and region. That means your watcher holds keys with billing attached in a cron environment, for a job that only needs to read a list. Give it its own project, its own keys and a spend cap, and the one genuinely sensitive thing on this page stops being sensitive.
Can I just watch the announcement blogs instead?
You need both, and they fail in opposite directions. The API tells you when something is callable, which is sometimes days after the blog post, and sometimes days before anyone writes anything. Run changedetection.io against the announcement pages and a poller against the model endpoints, then treat the first of the two to fire as the signal.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice