Pakshi Padosi — a 60-second Hinglish card of the birds that are actually outside your door this week (GBIF Gemma 4)

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass Pakshi Padosi ("bird neighbour") is a small web app that answers one question in Hinglish: which birds are actually around me this week, and how do I recognise them with my own eyes? You give it a town (or press GPS) and how many minutes you have. In about a second it shows the data: how many bird records exist within 25–50 km of you for this time of year — from GBIF, which means eBird and iNaturalist observations logged by real people — and which six species you should look for: three padosi that are always here, three mehmaan that are migrating in right now. Then Gemma 4 writes each bird a 60-second Hinglish card: size compared to a sparrow or a myna, the two most diagnostic field marks, where to stand, what it sounds like, and a one-line hook you'll actually remember ("Kaala bird jiski laal pooch thartharati hai" — Black Redstart). Then it tells you to put the phone in your pocket. That is the whole design: The screen is the shortest part. Read the card once (or print it — the print stylesheet strips the UI), then walk. No camera, no mic, no live identification. The app does nothing useful while you are outside, on purpose. Come back, tick, done. The Bahar tab is a six-box checklist plus one optional line of notes. Gemma turns the ticks into a two-line diary entry, and you can export the diary as Markdown or an eBird-style CSV. The diary lives only in your browser; your location goes to the open APIs that need it and nowhere else. Grounded, not generated. Gemma never chooses the birds. The species list, the resident/visitor status, the record counts, the hotspots and the sunrise window all come from data; the model only writes the descriptions, and every card shows the numbers behind it ("24 records · 8 within 25 km"). Who it's for: people like me in small towns — I'm in Raebareli, Uttar Pradesh, a city of about 200,000 with no birding club that I know of and no field guide in the language people actually speak here. Anyone who has heard a bird on the way to work and wondered what it was, and whose comfortable language is Hinglish rather than field-guide English. It works for any place GBIF has data for — Delhi, Mumbai, Chennai and Bharatpur all give sensible cards — but it was built on Raebareli's data. Live: https://pakshi-padosi.onrender.com/ — free Render instance, so the first load can take ~30 s while it wakes up. The Raebareli card is instant; type your own town and Gemma writes the card bird by bird, usually inside 90 seconds. Home The card Back from the walk What the card said for Thursday morning in Raebareli: window 6:10–6:50 AM (first hour after sunrise), 60 species recorded within 50 km this season, and "Indira Gandhi Smarak Vanaspati Udyan (3.1 km) sabse paas hai" — a park three kilometres from my house that I had never once thought of as a birding place. The app found it by clustering where other people's October records actually came from. And the walk? I haven't done it. I spent the mornings this week fixing the things below instead of standing next to a pond, and I'm not going to invent a field report in a post whose whole argument is that the app should never pretend. What was tested: the live server, on a phone-sized browser, repeatedly — the Raebareli card in about 10 seconds, other towns filling in bird by bird from 35 seconds, and the data side checked against five cities. The app's job ends at the gate. Mine starts there, and that part is still owed. https://github.com/Yuser00123/pakshi-padosi — MIT. Python 3.12, Gradio 6 on FastAPI, one render.yaml. Runs locally with LLM_PROVIDER=mock and no keys at all, or against Ollama with LLM_BASE_URL=http://localhost:11434/v1. Data first, model second. GBIF's occurrence API is free and needs no key. For a point, I facet bird records by species within 25 km → 50 km → 100 km until there are at least a thousand records for the ±1-month season window (Raebareli needed 50 km: 1,177 seasonal records, 60 species, almost all from eBird). Four more faceted queries give each species' records per season, and that becomes a status: a resident keeps a fair share of its records in every season; a winter visitor vanishes in the monsoon. That classifier bit me twice, and fixing it was the most interesting hour of the build. First, a resident White-browed Wagtail came out as a "winter visitor" because it had one monsoon record out of 26 — so small samples now need a clean zero in the off-season. Second, when I tried Bharatpur, home of Keoladeo, 25 of 60 species were "winter visitors", including the Painted Stork that breeds there. The data wasn't lying; the birders only go in winter. So every species is now compared against all bird records in the same circle, season by season — an effort correction. Bharatpur went from 25 false visitors to 1 (a real one, the Lesser Whitethroat). Raebareli's card ends up with three true winter visitors — White Wagtail, Black Redstart, Common Sandpiper — and three genuine neighbours. Hotspots are not a lookup table: the app pulls 300 recent seasonal records with coordinates, buckets them on a 2 km grid and names each bucket by its most common locality string. The window comes from Open-Meteo (sunrise, rain, AQI → "first hour after sunrise; smog — short walk"), with plain NOAA sunrise maths as the fallback. Hindi names are the honest weak spot: GBIF has no Hindi vernaculars, and Wikidata's Hindi labels are often English typed in Devanagari ("ऱेद-वत्त्लेद लप्विङ्") or wrong (it calls the Common Sandpiper a kind of lapwing). So a curated list of folk names comes first, Wikidata second, and the card says "Hindi naam pakka nahi" when neither is trustworthy. Lying about a bird's name to look complete is exactly what this app must not do. Gemma 4 (gemma-4-31b-it, open weights, through the Gemini API's free tier) writes only what needs writing. It gets our six species with their status and record counts as input and returns strict JSON per bird; the card's header lines are templates filled from the data, so there is nothing to hallucinate there. Three things I learned about it: Through the OpenAI-compatible endpoint it reasons inline inside <thought>…</thought> tags before answering. The client strips them (streaming-safe) and retries when the thinking eats the whole token budget. My first version asked for the whole card in one call. It worked — and took 194 seconds on the live server, and a single 500 lost everything. Now each bird is its own small call, six run in parallel, and the page fills in bird by bird (first one in ~35 s). A bird that still fails after its budget is shown with just its name and status from the data, plus a "press again" note: the finished ones are cached, so the second press only writes the missing ones. The endpoint throws intermittent 500s in batches. So the descriptions Gemma wrote for Raebareli's six birds during the first live runs ship with the repo as a seed cache — the demo town's card is instant and survives a bad API hour. Everything else is generated live, and GET /cache dumps what the instance has written if you want to grow the seed. (One field mark in that seed was corrected by hand after checking a guide; the file says which.) Render runs it from a Blueprint (render.yaml, free plan, /health check). Free hosts share outbound IPs, and both Open-Meteo and OSM's Nominatim refused that IP within the first hour — fine from my laptop, "map par nahi mila" in production. So geocoding falls back to Photon and then to a built-in table of Indian cities, the default town needs no geocoder at all, and the weather falls back to computed sunrise with a visible note ("mausam service abhi busy"). None of that is glamorous; all of it is what makes the card show up on a phone at 6 AM. Tooling: Gradio 6 with BrowserState for the diary, a print stylesheet, PWA manifest, Playwright for the screenshots, six offline tests with recorded fixtures (LLM_PROVIDER=mock). I paired with an AI coding agent for most of the typing; the design, the data decisions and the Hindi name curation are mine, and so are the mistakes. Nothing in this app is mine except the glue, and that is the point. The bird list is thousands of people's morning walks, logged into eBird and iNaturalist and published through GBIF under open licences. The map is OpenStreetMap. The weather is Open-Meteo. The Hindi names are Wikidata, with my corrections going back as the next edit. The language model is open weights — swap LLM_BASE_URL to Ollama and the same Hinglish bird cards come out of a laptop in Raebareli with no account anywhere, which is where I want this to end up: a district school running it on one old machine. Open data is also what lets the app be honest. A closed "AI bird guide" says "you may see a Black Redstart"; this one says "9 records in this window, 3 within 25 km, zero in the monsoon" — and when the data is thin it says that too, in the same font size. When the classifier mislabelled a wagtail I could see exactly which 26 records did it and fix the rule in ten lines; when Wikidata's Hindi was wrong I could see it was a bot transliteration and route around it. You cannot debug a black box with a field guide in your other hand. And open models change who gets to be for whom. Field guides for India are written in English for people who already own binoculars. A 31-billion-parameter model that anyone can run, fed a species list from a public API, will patiently write "Maina se thoda chhota, cheeks par red patch" for a town of 200,000 that no publisher will ever target. That is not a smaller version of the English product. It is a different product, and only open pieces make it buildable in three evenings by one person. (skipped) Best Use of Gemma — gemma-4-31b-it writes every bird description and diary entry from a data-grounded prompt; the write-up documents thought-stripping, per-bird parallel calls, the retry budget and the seed cache that made a slow free-tier endpoint usable on a phone. Best Use of Render — deployed from render.yaml on the free plan with a health check, plus the production lessons about shared-IP refusals and the fallbacks that fixed them. Built in Raebareli, Uttar Pradesh, 6–8 October 2026, mostly after dark.