This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
What I Built
At 4:00 PM in Kharghar, I gave a local model a deceptively small job: stop offering me choices and choose one real place I could walk to and return from in 30 minutes. The map pipeline found CIDCO Park seven minutes south, the timing code kept the outing inside daylight, and the interface reduced everything to one ticket. That test became Log Off.
Log Off turns four quick choices into one reason to close the laptop. You choose your mood, how much time you have, your energy, and whether you are alone. It then:
- finds real nearby outdoor places from OpenStreetMap;
- checks walking time, current weather, sunrise, and sunset;
- asks a local Gemma 4 model for one small activity at a place that actually fits; and
- shows one ticket with where to go, what to do, when to leave, and when to be back.
The model does not decide distances or invent the schedule. Code owns those facts. The goal is to make the screen the shortest part of the experience.
Demo
Log Off runs locally on a laptop, so there is no hosted demo. Setup and run instructions are in the README. Here is the complete screen flow:
1. Pick what you need from the break. Four compact choices give the planner enough context without turning the break into another questionnaire.
2. Take one ticket and leave the screen. The result gives one real place, one activity, and the leave-by and back-by times calculated by code.
Code
Log Off
Log Off turns a few preferences into one short reason to leave the screen. Pick a mood, the time available, your energy, and whether you are alone. The app finds a real nearby place, works out a safe walking window around daylight and weather, and asks a local Gemma 4 model for one small activity to do there.
The result is a single outing ticket with where to go, when to leave, when to be back, and a task that needs no phone, purchase, or equipment.
Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.
Screenshots
How it works
Log Off keeps facts and generation separate:
- Find facts. A typed area or browser location is rounded to three decimal places before the app requests nearby places from OpenStreetMap and daylight and weather data from Open-Meteo.
- Build a shortlist. Python code calculates walking time and…
FastAPI, TypeScript, Vite, local Gemma 4 through Ollama, and 104 backend tests.
Repository: github.com/rahultapase/log-off
How I Built It
Log Off has three deliberate layers: facts, generation, and validation.
1. Facts before AI. A FastAPI backend uses OpenStreetMap for geocoding and nearby places, then Open-Meteo for weather, sunrise, and sunset. Python code rounds outbound coordinates, calculates walking time and compass direction, merges duplicate map entries, and filters out anything that cannot fit the selected time budget.
That produces a numbered shortlist of real places. It also decides whether the outing can happen now or should move to just after sunrise. Gemma never calculates any of this.
2. A local Gemma task writer. Gemma 4 E2B runs locally through Ollama. It receives mood, energy, company, weather, and the numbered shortlist, but no coordinates. Its job is narrow: select one candidate ID and return a short, equipment-free activity as structured JSON.
I found that the model was much more useful after code supplied a task style for each mood and energy combination. The first prompt often returned variations of "relax in the park." The final prompt asks for a concrete, finishable observation, investigation, movement, or social task.
3. A factual guardrail. Every model response passes through a validator that checks:
- valid JSON and schema;
- a place ID from the supplied shortlist;
- an activity duration that fits after the round-trip walk;
- invented place or street names;
- forbidden distances and clock times; and
- extra safety constraints for darkness and rain.
A rejected response gets one repair attempt. If Ollama is unavailable or both attempts fail, a built-in deterministic activity keeps the ticket usable. The explanation visible to the user is also generated from code facts, not from Gemma's free-text reasoning.
4. I measured it. For the main evaluation, I ran 24 combinations of mood, time, company, and energy at 4:00 PM:
| Result with Gemma 4 E2B | Measured value |
|---|---|
| Valid on the first attempt | 23 of 24 |
| Fixed on the single retry | 1 of 24 |
| Deterministic fallback used | 0 of 24 |
| Invented-place runs | 0 of 24 |
| Median model-call latency | 2.8 seconds |
| Maximum model-call latency | 3.2 seconds |
The most useful failure was not a hallucination. For a social, with-others, low-energy request, Gemma suggested: "Start a simple card game like Uno." It passed the factual validator but needed equipment, despite the prompt. The validator can prove that an answer fits known facts; it cannot yet prove that the idea is good. That distinction is now an explicit limitation instead of a hidden one.
5. I swapped the model. With the same 12 preference sets, gemma3:1b passed 0 of 12 answers on the first attempt. Eleven were repaired and one fell back safely. Gemma 4 was much more reliable, but the open setup let me measure that difference inside the real application.
6. I kept the final screen quiet. The browser interface is TypeScript and Vite. It uses a daylight arc, accessible controls, visible focus states, reduced-motion support, and one final screen designed to be left behind.
Why Does Open Innovation Matter?
The model does not need my location. Gemma runs on my laptop through Ollama, so no location is sent to a model provider, no model API key is needed, and inference has no per-request fee. I can inspect the full prompt, constrain its role, keep evaluation results locally, and replace the model without redesigning the app.
I could test model sizes on the real task. The Gemma 3 and Gemma 4 comparison used the same planner, validator, preference sets, and hardware. I could choose based on measured reliability instead of a general benchmark or pricing page.
Open data keeps generation grounded. OpenStreetMap provides inspectable place IDs and geometry, while Open-Meteo provides weather and daylight data under an open licence. Together they let the model write around facts instead of pretending to know the user's surroundings.
Open does not automatically mean offline. Place and weather lookups still need the internet. It does mean I can draw a clear privacy boundary: rounded coordinates go to open-data services, while Gemma stays local and never sees them. It also means the failure handling is mine to test, explain, and improve.
Limitations
- The 24-run evaluation is a focused application test, not a general model benchmark.
- The validator checks facts and safety rules, not taste. The Uno suggestion passed.
- Weather describes current conditions even when an after-dark outing moves to tomorrow morning.
- Place and weather lookups need internet access, even though model inference is local.
What's next
Take Log Off on a real outing, add an equipment-language validator rule, use forecast data for next-morning plans, and compare more small local models on the same evaluation set.
Prize Categories
- Best Use of Gemma: Gemma 4 E2B writes the activity locally, and Gemma 3 1B provides the measured comparison.
Top comments (0)