DEV Community: Divyansh Saharan

OneLap: I Fine-Tuned Qwen to Help Me Touch Grass

Divyansh Saharan — Sun, 11 Oct 2026 18:20:10 +0000

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

👉 Try OneLap in your browser

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

DivyanshSaharan / OneLap

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…

View on GitHub

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.

GuardMate: 'Leave it with the guard' shouldn't need another phone call

Divyansh Saharan — Sun, 04 Oct 2026 19:30:35 +0000

What I Built

My friend and I physically go to the office. I live at home, but he is from far away, so he stays in a PG—a paying guest accommodation.

He also orders quite a few things online.

That combination creates a surprisingly repetitive problem: a courier arrives while he is at work, finds his room locked, and calls to ask where to leave the parcel.

Usually, his answer is the same: hand it to security at the guard room near the entrance.

But he cannot always take that call. Sometimes, the parcel ends up being returned. On weekends, he might actually be in his room, so repeating the same instruction regardless of his availability would not solve the problem either.

I built GuardMate, a personal AI delivery assistant around his routine.

It uses saved PG directions, guard-room instructions, weekly availability and a daily override to guide a courier through a delivery conversation. Each courier gets a separate session, so one parcel’s confirmations and approvals cannot accidentally carry over to another.

The challenge was not making an AI say “guard room.” It was teaching the system when not to say it:

Is the parcel prepaid?
Is security actually available to receive it?
Does this delivery require payment, an OTP or a signature?
Is the courier proposing somewhere the resident has not approved?

GuardMate can provide directions, remember confirmed facts and request a resident decision. It does not treat a courier’s suggestion as permission.

Demo

Watch the GuardMate product demo — MP4

Listen to the call recording — MP3

Use GitHub’s download control if playback is unavailable. The recording is shared with all speakers’ permission.

There is no public deployment. The application runs locally, and the cellular experiment uses Windows Phone Link with an Android phone.

In one consenting fictional courier call on a vivo T2x 5G running Android 15, we demonstrated the complete path:

Caller audio → local Whisper → hosted Qwen → permission checks → local Piper → caller

The caller confirmed hearing the full greeting and three checked replies.

The most useful moment was a failure: the final speech transcript was ambiguous. Qwen proposed recording a delivery outcome, but GuardMate’s application checks rejected the unsupported completion and asked for clarification instead.

No parcel actually changed hands, and no completed delivery was recorded.

That test used manual answering and transcript review. Automatic conversation after manual answering is now implemented with offline regression coverage, but it has not yet been demonstrated on a live call. Automatic answering and hangup are not implemented.

Read the actual live-call test report.

Code

GuardMate on GitHub

The repository includes setup instructions, the delivery dataset, training and evaluation tools, test reports, and the demo recordings.

How I Built It

The dashboard uses React, TypeScript and Vite. The backend uses FastAPI and Pydantic, with SQLite for resident settings, conversation history and approvals.

At the AI core is the open-weight Qwen3.5-4B, accessed through Tinker.

This is not a single-message classifier. The planner receives conversation history, saved instructions, current availability, confirmed parcel facts and resident-decision state. It returns a structured action plan.

GuardMate then checks that plan before executing it.

For example, an alternative handoff location requires an explicit, expiring resident approval. A courier cannot authorize it by claiming to be the owner. Changes to resident instructions invalidate stale decisions. Delivery outcomes remain labelled courier-reported, not independently verified receipt.

For voice, whisper.cpp performs local transcription and Piper generates speech locally. Capture and playback happen in separate phases to avoid deliberately recording the assistant’s own reply.

Fine-tuning Qwen with Tinker

I used Tinker for a real delivery-specific LoRA training pilot, not just inference.

The pilot used:

15 owner-reviewed fictional training scenarios.
40 structured planner targets.
LoRA rank 16 and batch size 4.
Three epochs, producing 30 optimizer updates.

The targets teach the next planning action—not just a list of phrases to repeat.

I then ran a fresh, matched comparison between base and tuned Qwen on six development scenarios:

Metric	Base	Tuned
Strict planner agreement	7/13 — 53.85%	8/13 — 61.54%
Checked scenario success	5/6	5/6
Median text-model/policy latency	2.133 s	3.113 s

Fine-tuning produced one additional correctly matched planner turn: a 7.69-percentage-point improvement on this small rubric.

The limits matter. Checked scenario success did not improve, and median latency worsened. These are fictional, exposed development cases—not evidence of real-world accuracy or generalization.

The recorded live call used base Qwen; the tuned model was evaluated separately. Completing training did not automatically promote the checkpoint.

Read the training recipe, matched results and remaining errors.

Why Does Open Innovation Matter?

For GuardMate, openness means being able to work on the pieces that fail.

During the call test, Whisper sometimes recognized “parcel” as “passion” or “option.” Because the speech pipeline is local and inspectable, I can investigate capture timing and compare installed speech models without replacing the entire application or uploading raw audio to a cloud speech API.

Open-weight Qwen also gave me a model I could adapt to this narrow task through Tinker, then compare against its base version under the same application checks.

That combination gives me three useful kinds of control:

Data control: routine speech processing stays local.
Model control: I can fine-tune the planner and evaluate a specific checkpoint.
Behavior control: permission-sensitive actions remain inspectable application logic rather than an instruction buried inside a prompt.

Closed services can offer fine-tuning too. My reason for choosing this approach was the replaceable open components and the ability to inspect and change the system—not a claim that every closed model would perform worse.

There is also an important privacy boundary: GuardMate is not fully offline. Recognized text, previous messages and saved resident context go to Tinker for planning. Local speech avoids hosted audio processing, not all hosted data sharing.

The prototype still needs better transcription and a real handover test with my friend. I have not claimed that it has reduced returned parcels yet.

The goal is small and personal: help him receive his deliveries without repeatedly interrupting his workday.

Prize Categories

Best Use of Tinker

GuardMate uses Tinker to fine-tune open-weight Qwen for delivery-conversation planning and evaluate it against a fresh, matched baseline.

The measured improvement is in strict planner agreement: 53.85% → 61.54%. The small sample, unchanged checked delivery behavior and slower median latency are reported alongside that gain.