Pocket Trail: an open-weight model writes you a walk, then tells you to close the tab

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

What I Built

Most "get outside" apps want you to stay inside them. Pocket Trail does the opposite.

You tell it how long you have and what kind of walk you want: wander, wildlife, plants, quiet or brisk. It checks today's weather, daylight and moon phase, and an open-weight model writes a one-page trail card. The card has a title, three or four physical steps, three things to notice, what to bring, and a turn-back time. You can print it, copy it as text, or start walk mode, which shows only one countdown and the current step.

The first thing on the page is not a button. It is a clock counting how long you have been on the screen, with a goal of 90 seconds. If you linger, it turns red. The success metric is how fast you stop using the app.

Other features:

• Daylight bar: a drawn arc from sunrise to sunset with your walk highlighted, so you can see how much light you have.
• Notice checklist: tick things off as you spot them, and the count goes into your log.
• Outings log: outings, day streak, minutes outside, and your average screen time before leaving. It stays in your own browser.

It is for anyone who has said "I should go for a walk" and then spent twenty minutes picking the perfect route.

Demo

Short video of Pocket Trail running with Gemma 3 1B on my machine (the card footer shows which model wrote each card):

Code

ypunit757-prog / pocket-trail

Pocket Trail

An open-weight model writes you a one-page walk card (print it or copy it), then gets out of your way The app times its own screen use and aims to be done in under 90 seconds.

Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.

How it works

• Context in code, not in the model: weather, sunset, moon phase and season come from Open-Meteo (free, no key) and plain Python.
• Gemma 3 1B (open weights) runs on the same Render service through Ollama and writes the card as JSON.
• Guardrails in code: thunderstorms or under 35 min of daylight return "Not today" and no card. The turn-back time is capped 20 min before sunset. Model output is validated and step times are rescaled to your time budget.
• Offline rules fallback: if the model is unreachable, a deterministic generator still returns a card, and the card…

View on GitHub

Run it yourself:

pip install -r requirements.txt
ollama pull gemma3:1b && ollama serve   # optional: without it you get an offline fallback
uvicorn app.main:app --reload

How I Built It

• Gemma 3 1B (open weights) runs locally through Ollama and writes the card as JSON.
• FastAPI serves one API route and one static page, with no front-end framework and no build step.
• Open-Meteo supplies weather and sunset. Moon phase and season are computed in Python.

The design choice I care most about: the model only writes the prose. Code decides everything that could hurt you.

• A thunderstorm nearby, or less than 35 minutes of daylight left, returns "Not today" and no card at all.
• The turn-back time is computed in code and capped 20 minutes before sunset.
• Gear advice (rain shell, hat, warm layer) comes from the weather numbers, not the model.
• Step times are rescaled so they add up to the real walk length.
• If the model is unreachable, a deterministic offline generator still returns a card, and the footer says which one wrote it.

What I learned from a 1B model. My first Gemma cards failed my own validation. The model returned steps like {"do": 1, "min": 10}, numbers where instructions should be. I fixed it by putting a worked example in the prompt and allowing one retry. Later it described crisp autumn air on a hot day, and a moonlit sky at noon, so I added a "Feels" word to the prompt and code checks that reject cold-weather wording when it is warm and any moon mention in a daytime card.

Here is a card Gemma wrote while I was testing:

Autumnal Echoes: The sunlight filters through the thinning leaves, painting the forest floor in gold.

1. Walk slowly towards a small, moss-covered stream.
2. Listen closely; you hear the faint chirping of robin chicks.
3. Observe a busy ant colony marching across a fallen log.

It is not perfect (robin chicks in October is a spring detail), and that is the point. A small model makes small slips, so the code owns timing, safety and gear, and the model owns the wording.

Why Does Open Innovation Matter?

1. No API key, no meter. The model runs on my own laptop, so there is no key to leak and no usage bill behind a free tool.
2. My location stays with me. Generation happens locally. The only thing that leaves is a latitude and longitude sent to the public Open-Meteo weather API, and I do not store it.
3. I can change how it behaves. The model is one environment variable (LLM_MODEL), and any OpenAI-compatible server works. I could swap in another open model or fine-tune one on local trail knowledge without asking anyone.
4. I could see the failures. Because I run the model myself, I read its raw output when it went wrong and fixed the prompt and the guardrails, which a closed API that hides retries would not have let me do as easily.
5. The honest downside: a 1B model is less inventive than a frontier one. For a card with a 25-word limit per item, that trade is fine.

Prize Categories

• Best Use of Gemma: Gemma 3 1B runs locally through Ollama and writes every card in the demo video.