Golden Hour Catcher

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Golden Hour Walk tells you exactly when to leave the house to catch the best light of the day.

You give it your location (or press "Use my location"), a date, and whether you want a morning or evening walk. You also say how long you want to walk and how far the spot is. It works out when golden hour starts and ends, when the sun rises or sets, and when you need to leave. Then it writes a short, friendly plan, like "Leave at 5:40 PM so you reach the water as golden hour starts."

Most people don't skip a walk because they hate walking. They skip it because there's no reason to go now. Golden hour gives you one: a specific window, a specific time to leave, and a sky that won't look like that again until tomorrow. It's for anyone who spends their day at a screen and wants a small, concrete nudge to go outside.

Demo

[https://golden-hourcatcher-i3r8p32e8-jeris-projects-4cc75d2b.vercel.app/]

Code

[https://github.com/Jeri20/GoldenHour_catcher/tree/main]

The whole app is one index.html file with no backend, so it deploys as a static site.

How I Built It

The core idea is simple: code does the facts, the model does the words.

The facts (no AI involved). All the sun times come from a solar calculation that runs in the browser. I started from Python's astral, which uses the NOAA solar algorithm, but a static page can't run Python. So I ported the same method to JavaScript. Golden hour uses the same definition astral does: the sun between 4° below and 6° above the horizon. Leave time is just golden hour start minus your travel time.

The words (open-weight model). The wording comes from an open-weight model running inside the visitor's browser using WebLLM and WebGPU. The default is Qwen 2.5 1.5B, and Llama 3.2 1B and 3B are in a dropdown. The model never calculates anything. It receives a short list of facts ("Leave home at: 5:40 PM, Golden hour starts: 5:55 PM...") and turns them into two sentences. I used two worked examples in the prompt, because small models follow the style much better when they see it.

The guardrail. A small model can still slip and write a time that sounds plausible but is wrong. So every clock time in its reply is checked against the times the code calculated

If the model quotes a time that isn't in the facts, the reply is thrown away and a plain template plan is shown instead. The page tells the user which one they got. If the browser has no WebGPU, the app skips the model and still shows the exact times with the plain plan, so it never ends up broken.

The model never sees a clock. It sees a list of facts, and if it quotes a time that isn't on that list, its reply is rejected.

Why Does Open Innovation Matter?

Open weights are what let me run the model in the visitor's browser.

No server, no API key, no bill. The whole thing is a static file. With a closed API I'd need a backend to hide a key, and I'd be paying for every plan someone generates. Here, one person or ten thousand costs me the same: nothing.
Your location stays on your device. The sun calculation and the model both run locally. Your coordinates aren't sent to a language-model API. The browser only downloads the model files.
I could pick the model to fit the job. The task is "turn five facts into two friendly sentences," which a 1B to 3B model can do. Because the weights are open, I could try several small models and offer them as a dropdown, instead of being tied to one provider's model.

The honest trade-off is that small models make mistakes. That is why the code owns the facts and the guardrail checks the output. Open models are good enough when you give them a narrow job and verify the result.