Want to touch grass but run out of options? Let Mochi the Explorer guide you to your next favourite spot!

Paola Ruffo — Sun, 11 Oct 2026 17:50:03 +0000

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

What I Built

Mochi the Explorer is a cute wee pixel mascot who helps you rediscover the city or town you already live in.

The inspiration came from two weeks spent trying to organise something new and fun with my friends in the city we've lived in for the past 10 years: none of us could come up with anything that felt even remotely exciting, and so off we went to our usual pub, defeated once again.

Sounds familiar? Cue Mochi to the rescue! All you have to do is tell Mochi where you live, what mood you're in, how much time you have and what time of day you're planning to head out and she'll plan the perfect outing for you! Mochi the Explorer will suggest between one and six stops (depending on how much time you have) and then encourage you to 'Go touch grass!' by showing you the location(s) she suggested on OpenStreeMap.

DURATIONS = {
    "30min":         {"radius_m": 1500,  "stops": 1},
    "1-2hrs":        {"radius_m": 4000,  "stops": 1},
    "half_day":      {"radius_m": 10000, "stops": 2},
    "full_day":      {"radius_m": 20000, "stops": 4},
    "multiple_days": {"radius_m": 40000, "stops": 6},
}

You only need to spend a couple of minutes on screen before being ready to put your shoes on and leave for an adventure! The goal is to suggest spots that fit your mood, but that you are less likely to have heard of or been to. In fact, Mochi deliberately avoids big chains and the most obvious picks, favouring indie shops, cafes and unusual experiences instead (try the unusual tag if you don't believe me 😉). The results change between requests, so even locals who feel they've seen it all will find something they haven't tried yet.

Let Mochi find your next favourite spot in town! ✨

Demo

Mochi the Explorer is available here:

mochitheexplorer.onrender.com

You can also watch a 'lil demo here:

A wee heads up: the backend runs on Render’s free tier and sleeps when idle, so the first request can take about a minute to wake up. But don't despair! Mochi will keep you entertained while you wait:

Code

The GitHub repo is available here:

cobaltspiral / mochi-the-explorer

🩷 Mochi the Explorer is a cute wee pixel mascot who helps you rediscover the city or town you already live in.

Mochi the Explorer 🩷

Mochi the Explorer is a cute wee pixel mascot who helps you rediscover the city or town you already live in.

The inspiration came from two weeks spent trying to organise something new and fun with my friends in the city we've lived in for the past 10 years none of us could come up with anything that felt even remotely exciting, and so off we went to our usual pub, defeated once again.

Sounds familiar? Cue Mochi to the rescue! All you have to do is tell Mochi where you live, what mood you're in how much time you have and what time of day you're planning to head out and she'll plan the perfect outing for you Mochi the Explorer will suggest between one and six stops (depending on how much time you have) and then encourage you to 'Go touch grass!' by showing…

View on GitHub

How I Built It

The open pieces making up Mochi the Explorer are:

Gemma 4, who picks and describes Mochi’s recommendations. The deployed demo uses gemma-4-26b-a4b-it on Google AI Studio’s free tier. While developing the project locally, I ran gemma4:e2b through Ollama with the same code.
The geographic data is from OpenStreetMap. In particular, Nominatim turns a place name into coordinates, while Overpass finds real places (parks, galleries, cafes, bookshops...) around them.
For the frontend, I used React + Vite, NES.css for the pixel graphics, and Leaflet for map visualisation.
I used Gumdrop Studio to design the sprite, Mochi.
Mochi is deployed on Render's free tier.

The design

I designed a fixed pipeline rather than a free-roaming agent. This is primarily because (small) AI models are not always reliable at deciding which tools to call, so my Python code runs the steps in a fixed order: (1) find the geocode, (2) find relevant places, (3) ask Gemma to _choose _the most suitable spot(s), _explain _ why it's a good choice, and give fun and cheerful tips to the user.

Making a small model trustworthy

Gemma is not allowed to come up with place names by itself. Each relevant candidate gets an ID (P1, P2...), Gemma answers with IDs, and my code looks up the real name and coordinates. This way, there is no risk of inventing a place that doesn't actually exist because an unknown ID is simply dropped. Its picks are also checked in code: duplicate tags are removed so a three-stop trip isn’t three of the same category, and missing stops are topped up from the candidate list.

Making the results less obvious

OpenStreetMap doesn’t record popularity, so I ranked places in tiers this way: independent places first, well-documented landmarks next, and chains last. Within a tier the choice is random, and each stop in a multi-stop trip comes from a different OpenStreetMap tag. The search widens its radius only when it finds less than three spots per tag (e.g., in the case of a really small town or a tag that's too specific for that area).

Problems that kept me up at night and how I solved them

Turning off thinking 💭

The Gemma 4 models I chose think by default. My first test took 13 to 16 seconds and returned over 1,600 characters of reasoning for a one-sentence answer. Ollama has a think: false switch that worked while developing locally. However, on Google’s hosted API, the OpenAI-compatible route ignored every setting I tried, until I tried the native endpoint with a minimal thinking level ("thinkingConfig": {"thinkingLevel": "MINIMAL"},), which cut the same test to 1.2 seconds.

Learning to be kind to the Overpass servers 🙏

I learned the hard way that public Overpass servers can be flaky. I kept getting timeouts and empty results, so I added retries, mirror servers, a private Overpass endpoint and an in-memory cache to avoid overwhelming Overpass.

My hometown was suddenly in the middle of nowhere 😱

At some point, I decided to test Mochi with my hometown, which is a relatively big city in Italy with loads of cosy spots to choose from. To my surprise, Mochi kept widening the search and coming up with places in towns nearby, but nothing in my hometown. After checking the coordinates, I discovered that Salerno, Italy, geocoded to the province rather than the actual city, which means Nominatim was returning the centre of the province 60 km from the city rather than its actual centre. I fixed it by telling Mochi to choose the first result that is tagged as a real settlement in OpenStreetMap (SETTLEMENT_TYPES = {"city", "town", "village", "municipality", "suburb", "hamlet", "borough"}).

Gemma freestyling 🎤

Gemma’s final message to the user kept making false claims (e.g., “a trio of pubs” when there was one bookshop), so I stopped asking it for that sentence. Mochi’s closing message is now a template filled with the real first stop’s name. The model keeps the part it handles reliably, and code handles the rest:

MESSAGES_ONE_STOP = [
    "I found {phrase} for you: head to {name}! Put your phone away and enjoy it.",
    "How about {name}? It's {phrase} waiting for you. Phone in your pocket, off you go!",
    "Your next stop is {name}. Leave the screen behind and go and see it!",
]
MESSAGES_MANY_STOPS = [
    "I found {phrase} for you. Start with {name}! Put your phone away and enjoy it.",
    "Here's {phrase} for today, starting at {name}. Phone in your pocket, off you go!",
    "Time for {phrase}! Begin at {name}, then follow the map. Leave the screen behind!",
]

No events (for now), soz 🫤

The first iteration of Mochi the Explorer included SerpApi’s Google results to suggest actual events happening in the area at the time specified by the user. However, structured events appeared too unreliable to be worth keeping, with listicles being suggested instead of actual events (e.g., "10 things to do in Edinburgh this weekend"), while other events suggested were completely invented. Given the time constraints, I decided it wasn't sensible to try and include events, but I might add this as a feature in Mochi the Explorer 2.0!

Why Does Open Innovation Matter?

I'm new to coding in general, but especially a newbie when it comes to open source AI models. This was the first time I consciously engaged with the open source world. Here's a few reasons why I think open innovation matters for my project:

Open data I could rank myself. A closed maps API sorts by popularity, which is exactly what I didn't want Mochi to suggest to a local who's likely already familiar with the most popular spots in town. With OpenStreetMap, I control the ranking, so I could push chains down, randomise within tiers and spread picks across categories. That’s the idea at the core of the project, and a closed API wouldn’t have allowed me to make it justice.
Control over how the model behaves. Being able to turn thinking off locally and validate the model’s output against my own data made a small model dependable enough to ship.
It's free!!! 💰 Using Ollama locally, OpenStreetMap, and Render and Google AI Studio free tiers means the whole app costs nothing to run (and to use!).
Trade-offs. In the deployed demo, Google hosts the model, so the city, mood and time of day go to Google rather than staying on infrastructure I control. With this setup, total privacy can only be achieved for the local setup. It’s a trade-off I made so the demo could be public and free.
Swappable models. The whole LLM layer consists of three environment variables and a small function. I developed against local Ollama, then deployed against Google’s hosted Gemma without touching the app. Bigger or smaller model, local or hosted, it’s all a matter of a config change.

Touching grass with Mochi

After being inside the whole week to work on Mochi the Explorer, I decided it was only fair I got to enjoy the fruits of my labour, so I put my touching grass future in Mochi's hands. She suggested two stops for my full-day cosy outing in Edinburgh:

However, not even Mochi could do anything against my ADHD, so I ended up leaving the house too late to make it to any of the places suggested in time. But alas, reader, do not despair! I ended up having an adventure regardless, courtesy of Mochi:

on my way to the cafè Mochi suggested I met Nelly, a 7-month old puppy.
I bought a whimsical, beautifully illustrated (and quite huge) book about star signs from a charity shop that I'm going to use for my collages (more touching grass, am I right?)
I finally got a coffee from a cafè I'd never tried before (not a chain!!!) and enjoyed a two-hour walk with my dog in the autumn sun.

What can I say? Sometimes Mochi works in unexpected ways.

Let her guide you to your next IRL adventure 🌟

Prize Categories 🏆

Best use of Render: Mochi is deployed entirely on Render: the FastAPI backend runs as a web service and the React frontend as a static site, both connected to the same GitHub repo and redeploying on every push. The whole app runs on Render's free tier, and the secrets (model key, private map endpoint) live in Render's environment variables, away from the code.
Best Use of Gemma: Gemma 4 is what makes Mochi work. It reads the candidate places and picks the ones that fit the person's mood, time and time of day, and writes the "why" and "tip" for each stop. I ran gemma4:e2b locally through Ollama while building, and deployed with gemma-4-26b-a4b-it on Google AI Studio. Making it usable took real work: I found that Gemma 4 thinks by default (13 to 16 seconds for a one-sentence answer), switched thinking off in Ollama, and found a minimal thinking level on Google's native endpoint that cut the same test to 1.2 seconds. I also built guardrails around it, which is why it answers with IDs, and my code turns them into real places, which means it can't invent one.

DEV Community: Paola Ruffo