This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

This idea started with me waiting. On Monday I opened my coding agent and typed, word for word: "yo yk how we were waiting for hacktober dev.to week 3 topic. why were we waiting?" I had been refreshing the challenge page for the new theme, and before that the Week 2 page for results, and before that the petrol price board. I spend a silly amount of my week checking pages for one sentence that isn't there yet.

Wait For It is a web page where you type what you're waiting for in plain words, add a link if you have one, and then stop checking. It looks for you, rarely and on purpose:

• You write "the Week 2 winners are announced" with the challenge link, or "پاکستان میں پٹرول کی قیمت بدل جائے" (tell me when the petrol price changes in Pakistan) with no link at all.
• Gemma 4, an open-weight model, reads the page (or the past week's Google results) and answers two questions: has it happened, and when should I look next?
• When it has happened, or the date moved, you get a browser notification and a short voice note, in English or Urdu.
• The rest of the time it stays quiet. A watch for something a month away gets looked at once a week, not every hour.

Who gets to be lazier: anyone waiting on a page that will change once. Students waiting for results, people waiting for a price to drop, developers waiting for a release, and me, waiting for this challenge's own results. The effort it saves is the refreshing and the second-guessing, which for me is many small checks a day.

Demo

The live page is at https://waitforit.onrender.com (free Render instance, so the first load can take up to a minute while it wakes up). Notifications need you to click "Turn on notifications" once.

What a first check looks like. I typed "Linux 7.4 is released" and the kernel.org link, and Gemma's first look came back in about 5 seconds:

The real watches I left running overnight, including two that answer in Urdu. Each card shows what Gemma found, when it will look again, and the expected date it pulled from the page:

Code

Plain Node (no framework), about 900 lines. MIT licensed.

How I Built It

The architecture is deliberately boring, because the interesting part is the decision in the middle:

• A free pinger (cron-job.org) calls /api/tick every 30 minutes with a secret key. That wakes the free Render server, which runs only the watches whose next check is due, and goes back to sleep. Nothing has to stay on, including my PC.
• For a watch with a link, the server fetches the page, strips menus, footers and hidden HTML, and hashes the text. If the hash matches last time, nothing could have changed, so Gemma isn't asked at all.
• For a watch without a link, it asks SerpApi for the past week's Google results instead. Gemma turns the person's sentence into a short query once, when the watch is created, because searching the literal Urdu sentence found nothing.
• Gemma 4 (26B A4B, the open-weight mixture-of-experts model, hosted on Google AI Studio) gets the request, today's date, what it told the person last time, and the page. It replies with JSON: a status (happened, changed, delayed or nothing), a short summary in the person's language, the earliest and latest likely dates, how many hours until it should look again, and a quote.
• MongoDB Atlas holds the watches, their last 50 checks, the browser push subscriptions, the voice notes and the daily counters.
• ElevenLabs turns the summary into a voice note (Flash v2.5 handles Urdu) only when something happened or was delayed, never for "nothing".

The model never gets the last word

The first version trusted Gemma's status. That is exactly what keyword alerts get wrong in the other direction: they trust the page. So now Gemma has to show its work. For any news it must copy a few words from the page, and code checks that those words are really there before anyone is told:

// A quote that skips words ("India were champions... beat New Zealand") counts if every piece is there.
export function quoted(quote, text) {
  const norm = (s) => String(s).toLowerCase().normalize('NFKC').replace(/\p{M}/gu, '').replace(/[^\p{L}\p{N}]+/gu, ' ').trim();
  const t = norm(text);
  const pieces = String(quote).split(/\.{3}|…/).map(norm).filter(Boolean);
  // Long enough to mean something: two words, or a number like a version ("158.0").
  const enough = (q) => q.includes(' ') && (q.length >= 6 || (q.length >= 4 && /\d/.test(q)));
  if (!pieces.length || !pieces.every(enough)) return false;
  return pieces.every((q) => ` ${t} `.includes(` ${q} `) || (q.length >= 12 && t.replace(/ /g, '').includes(q.replace(/ /g, ''))));
}

If the quote isn't on the page, the status is downgraded to "nothing", the check is saved with the rejected quote for me to look at, and no notification or voice note goes out. The same idea runs through the rest of the code:

• Gemma picks when to look next, but code clamps it to between 30 minutes and 7 days, and forces a look at least every 6 hours once the earliest likely date is within 3 days. In the eval Gemma once asked to sleep for 720 hours (the 2027 Cricket World Cup); the code cut that to a week.
• Gemma can say a watch is done, but for anything that happens again ("tell me when the price changes"), code ignores that and keeps watching. I added this after the petrol watch found a two-day-old price cut on its first look and switched itself off.
• File links Gemma wants to save have to be copied from the page's real link list; anything it invents is dropped.
• The page fetcher refuses private and local addresses, so nobody can point it at the server's own network.

What one check costs

Every key has a hard daily cap stored in the database (so a restart doesn't reset it), because I am a student on free tiers and a loop or a crawler shouldn't be able to spend anything:

On top of that: at most 5 watches per person, 60 in total, 10 new watches per IP per day, and every watch ends after 45 days. I'll delete the keys when judging is over.

What I Measured

A watcher is only as good as its "has it happened?" call, so I built a test set before writing this post. I picked 36 real pages on October 21, wrote a question for each, and labelled every answer by reading the page itself, separately from Gemma:

• 15 release pages (kernel.org, python.org, nodejs.org, go.dev, the Rust blog, Deno's GitHub releases, Firefox release notes), mostly in pairs on the same page: "Linux 7.3 is released" (yes) and "Linux 7.4 is released" (not yet).
• 21 Wikipedia pages for events: the 2026 World Cup final (happened), the 2030 World Cup (not yet), GTA 6 (scheduled for November 19), the Nobel Peace Prize winner (announced) and its ceremony (December 10, not yet), and so on.
• 19 have happened and 17 haven't. The "not yet" pages are the hard ones, because they are full of words like released, announced and champion.

Each page is saved once, so every run reads the same text, and node eval/run.mjs runs the real check (the same checkWatch the server uses, including the quote check) next to a keyword rule that fires when a done-sounding word is on the page. That rule is what a "tell me when this page changes" alert effectively does.

Split by kind of page, the keyword rule is bad everywhere, and Gemma's only miss is on Wikipedia:

The second thing I wanted to know is whether Gemma is actually lazy in a useful way. This is what it chose for "when should I look next?" on the same pages, before the code clamps it:

That is the behaviour I hoped for: it looks rarely when the date is far and the page gives one, and daily when it has no idea.

What went wrong

All of these are real, and most of them changed the code:

• The one miss is Artemis II. The page says it launched on April 1, 2026 and landed April 11. Gemma read "launch date April 1, 2026" as a plan and said it hadn't happened, even though today's date (October 21) was in the prompt. Dates in the past written like schedules are still a weak spot.
• My first full run scored 19 of 36, and 16 of those failures were mine: the free tier limits tokens per minute, and long pages (8,000 to 14,000 tokens each) hit it after two calls. The app now waits as long as Google's error says and carries on, which means a run takes about a minute per page.
• One label was wrong, and it was my fault. I marked "Firefox 158 is out" as not yet because my search pattern missed it; Gemma said it was out, and 158.0 and 158.0.1 are both on the page. I fixed the label and added Firefox 159 as the "not yet" case.
• The quote check was too strict twice: it refused "158.0" (too short) and a quote with "..." joining two sentences from the T20 World Cup page. Both were true. Version numbers and quotes with gaps now count when every piece is on the page.
• Before that, Gemma sometimes returned an empty answer. It thinks before it answers, and with my original 900-token limit the thinking used up the whole budget. I raised it to 2,048 and retry empty or cut-off replies.
• Wikipedia pages were wasting the 14,000-character budget on menus, language lists and HTML snippets hidden inside attributes. The text extractor now skips nav, footers, comments and quoted attributes, and the Artemis II page went from mostly menu to the mission facts in the first 1,000 characters.
• The local version was quietly broken until I tested it for this post. Ollama gives a model a 4,096-token context by default, so on a 10,000-token page local Gemma only ever saw the first 2,051 tokens and mostly answered with nothing. The Ollama call now asks for 12,288 tokens; 20,480 was too big for my 6 GB GPU and pushed half the model onto the CPU.
• The petrol watch switched itself off after its first look, because a recent price cut looked like "it happened". Things that repeat now never end.

What it can't do

• Pages that only render with JavaScript, or sit behind a login, come back nearly empty. University portals are the obvious example. A headless browser would fix it, at a cost I haven't paid yet.
• It reads the first 14,000 characters of a page. If the news is at the bottom of a very long page, it won't see it.
• No-link watches depend on Google having the news in the past week, and on 8 searches a day for the whole site.
• The free server sleeps, so a check can run up to 30 minutes late. For exam results that's fine; for concert tickets it isn't.
• Notifications need the browser to have been allowed once, and iPhones only show web push for sites added to the home screen.
• The test set is 36 pages picked by one person on one day. It shows the idea works and where it breaks; it isn't a benchmark.

Why Does Open Innovation Matter?

For this project it matters for three concrete reasons, not as a slogan.

The first is that the pages people wait on are often private. A results page you are logged into, a supplier's price list, a hospital's appointment page: I don't want any of those going to a company's API just to ask "has it changed?". Because Gemma's weights are open, the same code switches to a model running on your own machine with one setting. Set OLLAMA_URL and Wait For It uses gemma4:e4b-it-qat through Ollama instead of AI Studio, and the page never leaves your PC. I checked this on my own 6 GB GTX 1660 Super with six of the eval pages: local Gemma got 5 right and failed one (the long Firefox release-notes page, where it ran out of time before producing an answer). It is slow, 42 to 124 seconds a page against about 4 seconds hosted, but a watcher that looks once a day can afford to be slow.

The second is cost and control over time. A watcher runs for weeks. With a closed API, the price, the rate limits or the model itself can change halfway through a watch, and I would find out when it broke. With open weights I can pin the exact model the eval was run on, and if the hosted free tier goes away, the fallback is a download, not a rewrite.

The third is that I could build on other open work instead of starting from zero. The Gemma calling code is adapted from my earlier open-source project, scamcheck (credited in the README); edge-tts and Remotion, both open source, made the video; and Ollama makes "run it yourself" a single command. Open models are also what let me look inside the failure: when Gemma returned empty answers, the API showed me the thinking tokens, and that is how I found the budget problem.

The Lazy Payoff

I am using it for the things I'm actually waiting for. These are the five watches running on the live site right now, all started on October 22 at about 2:45 AM my time:

How much refreshing that replaces depends on how anxious you are, so here is the comparison against someone who checks three times a day, using the schedule rules above and assuming the dates on the pages hold:

And for every one of those looks where the page hasn't changed, Gemma isn't even asked. That is the whole point: the only looks these pages need from now on are Gemma's, and I can close the tabs.

Prize Categories

• Best Use of Gemma: Gemma 4 (26B A4B on AI Studio, or E4B locally through Ollama) is the judge of every check: has it happened, what changed, when to look next, and the quote that proves it, in English or Urdu. Measured on 36 hand-labelled pages: 35 right, 0 false alarms.
• Best Use of SerpApi: watches without a link ("tell me when the petrol price changes") search the past week of Google results through SerpApi, with a query Gemma writes once from the person's own sentence, capped at 8 searches a day.
• Best Use of ElevenLabs: when something happens or is delayed, the summary becomes a short voice note with Flash v2.5, including in Urdu, through a key restricted to text-to-speech with its own credit limit.
• Best Use of MongoDB: Atlas stores every watch with its last 50 checks, push subscriptions, voice notes and the daily spending counters that survive restarts, behind an IP list that only allows the Render servers.
• Best Use of Render: a free Render web service is the whole backend; a 30-minute ping wakes it to run only the watches that are due, so nothing stays on between checks.

The code, the eval set and the results file are in the repo. I built this with Claude Code as my coding agent, and it helped draft this post; every number in it comes from the eval output in the repo or from the live site.