This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.
What I Built
Work and commuting take up roughly 7 AM to 7 PM of my day. By the time I’m home, planning an outdoor adventure feels like another task.
But fifteen minutes outside? That feels possible.
I built OneLap for that gap: after work, before scrolling.
OneLap uses an open-weight model to turn a small window of time into one outdoor observation mission. Choose 10, 15, or 20 minutes, a familiar setting, daylight or evening, and something that interests you: sounds, textures, light, or simply discovering something.
Read the short instruction, select “I'm heading out,” and put the phone away.
When you return, save one observation. You can also say whether the task was useful, too difficult, or not for you. Completing, stopping, and skipping are all valid outcomes.
There is no GPS tracking, compulsory photograph, timer, streak, leaderboard, or feed. The app does not pretend to verify that you went outside.
The goal is to make the screen the shortest part of the experience.
An ordinary moment worth noticing
One observation I saved and synchronized to Atlas was:
I thought all DTC blue buses were electric. But when I walked past one, I heard what sounded like a diesel engine. That surprised me and made me question my assumption.
The sound alone does not establish the bus’s fuel type. What interested me was the gap between what I expected and what I noticed.
That is the kind of moment I want OneLap to encourage. You do not need a mountain trail or an impressive photograph. Something familiar can become interesting when you pay attention.
A next activity can build on that curiosity: notice one sound during a familiar lap and describe its rhythm or tone before deciding what caused it.
Demo
No video, download, or installation is required.
- Sign in with Google.
- Choose your time, setting, conditions, and observation focus.
- Review the hosted-model disclosure and create your outing.
- Read the mission, then pocket your phone.
- Return and save an observation locally.
- Optionally synchronize your journal to access it from another device.
The demo has a small, shared inference allowance. New mission generation becomes unavailable when its approved spending or request limit is reached.
Journal-based AI reflection is implemented and has been tested separately, but remains disabled in the last verified public-demo configuration. Synchronizing a note does not automatically send it to Qwen.
The bus note is my own reported observation, not a captured model response. The documented end-to-end integration checks used fictional observations; a formal physical-phone outdoor workflow test remains pending.
Code
OneLap
After work, before scrolling.
One short outdoor observation mission. Read it, put the phone away, and bring back one thing you noticed.
Open the live demo · Fine-tuning results · Setup guide · Build plan
Built for the Hacktoberfest Open-Source AI Challenge — Touch Grass.
Why OneLap?
Work and commuting can fill the stretch from 7 AM to 7 PM. A big adventure is not always realistic. Fifteen minutes outside might be.
OneLap makes that small window easier to use: choose a familiar setting and something to notice, get one brief mission, then leave the app behind.
It is not a route planner, fitness tracker, or conversation to keep open while walking. There is no GPS tracking, compulsory photograph, timer, streak, leaderboard, or feed.
The goal is to make the screen the shortest part of the experience.
Try it
Visit onelap-4s17.onrender.com in your phone or desktop browser. No…
The repository includes the application, synthetic training corpus, evaluation tooling, automated tests, Docker configuration, and documented experiment results.
How I Built It
The AI core is Qwen3.5-4B, accessed and fine-tuned through Thinking Machines’ Tinker.
The application uses:
- React, TypeScript, and Vite for the browser interface.
- FastAPI and Pydantic for the API and structured-response validation.
- IndexedDB for local missions and observations.
- MongoDB Atlas for account-scoped journals, authentication sessions, and durable spending counters.
- Google sign-in for verified identity and journal isolation.
- Docker and Render for a single deployment serving the frontend and backend.
Initial generation sends generic selections to Tinker—not GPS coordinates or journal history. The backend validates the response before displaying it. A rejected response produces an error, not a fabricated substitute mission.
Fine-tuning for one specific job
Generating outdoor ideas is easy. Consistently producing one brief, structured, phone-free task is more specific.
I trained one rank-16 LoRA adapter through Tinker using 100 synthetic supervised examples over three epochs.
The corpus covers initial missions and follow-ups that adapt to observation feedback. Scenario families were split before their variants were written. Base and adapter evaluation used unchanged prompts, application checks, and decoding.
| Measurement | Base Qwen | Fine-tuned adapter |
|---|---|---|
| Development application acceptance | 16/20 — 80% | 20/20 — 100% |
| Held-out application acceptance | 20/30 — 66.7% | 29/30 — 96.7% |
| Held-out JSON/schema validity | 24/30 — 80% | 30/30 — 100% |
That is a 30-percentage-point improvement in held-out application acceptance, not a claim of 96.7% overall accuracy.
The dataset is small and synthetic, its variants are correlated, and independent human semantic review is pending.
One remaining failure was revealing: the adapter said “without recording it,” but the conservative keyword filter rejected the recording-related wording. I kept the failure in the results rather than changing the check after seeing it.
The deployed configuration selects the trained adapter. The full pilot report explains the method, remaining failure, costs, and limitations.
Personalization without background analysis
When enabled, the separate follow-up flow lets you select one completed, synced observation and optionally two earlier notes.
After explicit sharing approval, the server retrieves those account-owned records from Atlas. Qwen should reflect on what was actually reported and propose another activity while preserving the original duration, setting, conditions, and focus.
The suggestion is yours to accept or discard. Journal notes do not automatically retrain the model, and ordinary mission generation does not silently include your history.
Saved missions and observations are local-first. A verified signed-in tab can remain usable offline, but a fresh session check and new inference require connectivity. This is not local inference.
Why Does Open Innovation Matter?
A closed API could generate an outdoor prompt too. What open weights gave me was the ability to adapt the underlying model for this particular experience and compare that adaptation against its base model.
Instead of relying only on a longer prompt, I trained a small adapter and measured a narrowly defined improvement using unchanged application checks.
Tinker made that experiment practical without managing training hardware.
The model provider is also separate from the application’s validation, storage, consent, and spending rules. That leaves room for another compatible runtime later, although local inference is not implemented today.
Open weights do not automatically make hosted requests private or free. OneLap’s model inputs currently go to Tinker. Its privacy choices come from collecting less: no precise location, no photos or audio, local-first notes, and explicit sharing.
For me, the point of AI here is not another conversation that never ends.
It is one small reason to go outside—and then getting out of the way.
My Agent Session
No public agent-session replay is included. The build plan and experiment report document the development process and measured results.
Prize Categories
- Best Use of Tinker: Task-specific Qwen LoRA fine-tuning, with held-out application acceptance improving from 20/30 to 29/30 in a matched baseline comparison.
- Best Use of Render: A deployed Docker web service hosting OneLap’s frontend and backend.
- Best Use of MongoDB Atlas: Account-scoped journal storage and durable spending counters that survive application restarts.
Top comments (0)