Nature Quest: an on-device open AI that sends you outside and gets out of your way

Eze Prince — Sun, 11 Oct 2026 22:40:12 +0000

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

What I Built

Most "AI for the outdoors" ideas still end with you staring at a screen. Nature Quest is built the other way round: the screen is the shortest part of the experience.

You tap once. An open AI model running on your own phone picks a short mission that fits where you are and how you feel, for example "Five greens" or "Count the voices" (listen for three minutes and count the different bird calls). The card is simple: a title, why this quest, your task, and the time. Then the app says "Your quest is ready. Now put the phone away." and dims itself. You go outside. When you come back it asks what happened, you share a few words and an optional photo, and your journal, streak and achievements grow. Then it tells you that is enough screen for now.

It is not a chatbot. The AI works behind the scenes: Mission, Reality, Return, Reflection, Progress. It is for anyone who wants a nudge outside without another feed to scroll, including people with weak signal, small data plans and mid-range phones.

Demo

Live app (installable PWA, works offline after setup): https://nature-quest-c14be.web.app

Code

Kings-creation / nature-quest

"Offline-first PWA where an on-device open AI picks outdoor quests that get you off your phone"

Nature Quest 🌿

An offline-first PWA that uses an open-weight AI model, running on your own device, to write short real-world missions, then deliberately gets out of your way so you can go outside.

Built for the DEV / Hacktoberfest 2026 "Touch Grass" challenge.

The loop: one tap gets a quest, the screen tells you to put the phone away and rests itself, you go outside you come back and say how it went, and your journal and streak grow. The screen is the shortest part of the experience.

Open AI, no paid APIs

Quests come from a library of 114 hand-checked missions. An open-weight model on the phone picks the one that fits you.

Job	Model	Notes
Smart matching (default, recommended)	`Xenova/all-MiniLM-L6-v2` (Apache-2.0, about 25 MB) via Transformers.js / ONNX Runtime Web, in a Web Worker	Embeds what you type ("tired after work, want something calm"), the time of

…

View on GitHub

The repository was created on October 11, 2026, inside the challenge window (Oct 5 to 11).

How I Built It

The open AI at the core

Smart matching (default). all-MiniLM-L6-v2 (Apache-2.0, about 25 MB) runs in the browser through Transformers.js and ONNX Runtime Web, inside a Web Worker. It reads what you type ("tired after work, want something calm"), the time of day, the season, who you are with, your energy, and a gentle lean toward quests you finished before. It re-orders a library of 114 hand-checked quests by meaning.
It can only re-order. The model never writes or adds a quest, so it cannot ramble or invent something unsafe. Every quest also passes app-level safety rules (no climbing, water, roads, foraging, darkness or strangers).
Optional creative writing. The same provider layer can drive a small on-device writer, or a bigger open model on your own computer, for example gpt-oss:20b through Ollama. It is experimental and off by default.

What went wrong, and why the design changed

I started by having a small language model write every quest on the phone. On my mid-range Android phone (Chrome, CPU only; the WebGPU API existed but no graphics adapter was available) Qwen2.5-0.5B loaded in about 19 seconds, took about 15 seconds to produce a first word, and then wrote around 0.3 tokens per second. A whole quest needs about a hundred, so it never finished. A smaller 135M model was faster but rambled into stories and also never produced a usable quest. So I stopped forcing one model to do every job. Small open models are great at understanding meaning (fast, offline) and poor at long free writing on weak hardware. The final design uses the right model for each job.

The rest of the stack

Offline-first PWA: service worker, IndexedDB, and a sync outbox. Everything runs on the device. Firebase gives optional sign-in; the cloud backup code exists but I did not enable Firestore for this demo, so my progress stays local.
Never stuck: every model runs behind a watchdog with timeouts, a skip button, and an in-app self-test that prints where the time goes.
Honest verification: time outside versus quest length, an optional photo (kept on the phone and checked only for being a real, non-blank image), and the person's own words. Each completion is labelled self-reported, time-checked or photo-attached. The AI never claims to have seen anything.
No double rewards: completion is idempotent, so double taps, reloads and crashes cannot count a quest twice.
68 automated engine tests and 69 browser checks (offline reload, stuck or crashing model, matching, photo evidence).

Field test: I tried it on my own phone on October 11. The app picked "Stand in the light" for me and labelled it "Picked for you by all-MiniLM-L6-v2", and I started it. I finished "Bench pause" (5 minutes outside, labelled "Time on quest checked") and wrote "This was relaxing" in my journal. I also finished "Lean and look up" and attached a photo, which the app labelled "Photo attached". I finished that one in about a minute, so the journal honestly records 1 minute. That is why the app records time instead of pretending.

Why Does Open Innovation Matter?

It runs with no internet. The place you want this app is a trail or a park, exactly where the signal drops. A closed API cannot go there. A model cached in the browser can.
It costs nothing to run. No keys, no per-quest bill, no credit card to try it.
Your words and photos stay on your phone. No server I control ever sees them.
It is swappable. A tiny matching model on a phone, a bigger open model on a laptop, one app. Open weights let me measure each model on the real device and change the design when one failed.
Where it was worse, honestly: small open models were too slow and too chatty to write whole quests on a mid-range phone. I did not hide that. I redesigned around what small open models do well and kept free writing as an optional mode.

Do AI models still follow instructions when the rules stack up? A control-vs-stress benchmark

Eze Prince — Sun, 11 Oct 2026 07:52:22 +0000

This is a submission for the Kaggle Benchmarking Challenge

What I Benchmarked

Reliability under constraints: when a model must satisfy several rules at once, and the prompt is padded with distractors or conflicting notes, which rules slip?

ModelBench has 16 tasks in 8 control/stress pairs across four families (constraints, structured output, distractors, compound tasks). A control is a plain task; its stress version adds extra constraints, conflicting instructions or irrelevant facts. Every answer is scored by deterministic code (JSON parsing, word limits, exact values, forbidden words), never by an AI judge. A task's score is the share of its checks passed. Infrastructure errors are never counted against a model.

Models Tested

Five models on Kaggle, one run each: gpt-oss-20b, Gemini 3.7 Flash, Claude Sonnet 5.5, Gemma 4 31B and DeepSeek-R1.

Findings

1. A huge spread on identical prompts. gpt-oss-20b scored 96.7%, Gemini 3.7 Flash 94%, Claude Sonnet 5.5 84%, Gemma 4 31B 68% and DeepSeek-R1 16%.

2. Score did not follow cost. On Kaggle's score-vs-cost chart, gpt-oss-20b sits in the "efficient" corner, while DeepSeek-R1 is among the most expensive points with the lowest score.

3. Strong models still slip on format discipline. In an earlier manual pilot, Claude Sonnet 5.5 passed all 8 original tasks, but on a harder set it gave a correct multi-step answer (24.19) while showing its working, even though the prompt said "reply with only the number". Gemini 3.6 Flash passed 7 of 8 harder tasks and dropped a task from a list after a distractor said sprint planning had moved (one run, so only a hypothesis).

4. What surprised me. Claude scored 100% on the first 8 tasks in my manual pilot but 84% on all 16 on Kaggle. I haven't diagnosed why. The 8 added tasks are harder, but one run per model is a weak basis for a conclusion.

My Benchmark

https://www.kaggle.com/benchmarks/ezeprincejr/modelbench-reliability-under-constraints

Limitations

Only 16 tasks and one run per model, so small differences are not reliable. Scoring is equal-weight and provisional. Eight of the tasks were written after a two-model pilot, so they are not blind. A JSON reply wrapped in a code fence counts as a format failure. I did not diagnose why DeepSeek-R1 scored so low (it could be a real format problem or my scoring being too strict). I have not split scores into control vs stress per model. Next I'd add repeated runs, more models and a per-task failure analysis.

Prototype dashboard (optional)

I also built a companion dashboard as an installable web app: https://modelbench-ai-c14be.web.app

It is only a prototype. The official, authoritative results are the ones on the Kaggle leaderboard above. The dashboard shows an "awaiting results" screen until results are loaded into it, and a labelled demo-data mode for previewing the layout.

INVORA PRO business management and POS system... now with APIs...

Eze Prince — Thu, 08 Oct 2026 10:16:54 +0000

DEV Community: Eze Prince