DEV Community: Aditya D

Resume Button: a gentler restart for unfinished work

Aditya D — Thu, 22 Oct 2026 05:17:06 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

Resume Button helps developers return to unfinished projects without piecing together their last session from scattered notes, code, and test logs.

Before a break, click Save my place, leave a short note, and select the relevant files or logs. A local Qwen model helps turn that context into a resume card containing:

Your goal and completed work.
The blocker that remains.
Approaches you already tried.
Your recorded next idea, or a clearly labelled AI suggestion.

When you return, open the card and pick up from there. Evidence quotes link to the exact saved source lines, and SQLite preserves cards and source copies between sessions. History, Markdown export, a focus session, and backup restore support the same workflow.

For Slow and Steady, the chore I wanted to reduce is reconstructing context before doing useful work. You can take a break with a place to restart waiting for you. Actual human time saved has not been measured.

Demo

The demo uses a fictional trip planner called Weekend Atlas. Typing “Lisbon” sometimes shows results for “Lis” because an older response arrives last. A debounce reduced requests but did not solve the bug. The card generated with the real local Qwen model preserves both the failed attempt and the author's next idea: track the latest request ID and ignore older responses.

18-second walkthrough: saved card, source inspection, capture, backups, focus, and mobile layout.
Full 102-second recording: actual model generation, cancellation and retry, export, history, and restore.

The app runs locally; the recordings show its workflow without requiring the model download.

Code

Source code, setup instructions, and tests on GitHub.

The application is MIT licensed. The repository includes tests, model setup scripts, documentation, and the fictional demo context.

Run it on Windows with Node.js 22.13 or newer:

git clone https://github.com/AdityaAneNenu/resume-button.git
cd resume-button
npm ci
npm run setup:model
npm run build
npm run local:production

Open http://127.0.0.1:4173. Setup downloads about 1.1 GB of verified runtime/model files; generation works offline afterward.

How I Built It

The core AI components are Qwen2.5-1.5B-Instruct, an Apache 2.0 open-weight model, and llama.cpp, an MIT-licensed inference runtime. The bundled Windows setup uses the official Q4_K_M GGUF weights and CPU inference, with pinned downloads and SHA-256 checks. An existing local Ollama service is also supported.

React and Vite provide the interface, Express serves the local API, SQLite stores cards and source snapshots, and Zod validates inputs and model output.

The main challenge was keeping a useful recap faithful to unfinished work. The model selects numbered source lines rather than writing quotes. The server resolves those IDs into saved text and rejects invalid selections or classifications that contradict explicit labels. Labels such as Completed:, Blocked:, and Tried: take precedence, and a recorded next idea stays the author's idea. Recaps are assembled from the selected evidence.

If no next idea is recorded, Qwen can propose a suggestion with supporting sources. A matching source makes that suggestion inspectable; it does not guarantee it is correct.

flowchart LR
    N[Notes and selected sources] --> U[React interface]
    U --> A[Local Express API]
    A --> Q[Qwen through llama.cpp]
    Q --> V[Validate evidence IDs and labels]
    V --> D[(Local SQLite)]
    D --> C[Resume card and source viewer]

Recovery matters too. Cancelling generation preserves the capture draft and source selections. Restoring a backup validates its evidence and adds independent copies in a transaction.

Validation included 30 unit/API tests, three browser flows, a TypeScript/production build, formatting checks, and a separate real Qwen run. The real run confirmed cancellation saved no card, retry succeeded, and backup restore added copies. Five sources took 92.1 seconds to generate on this machine. That is inference latency, not a human time-savings result. The small model can miss details in unlabeled prose; guided notes are more reliable.

Two useful community references were From TCP to Express: Understanding Request Lifecycles and Cancellation by @silentwatcher_95, on propagating cancellation, and Preserve First: Recovery Design for Local Creative Data by @qnbs, on preserving existing work during recovery.

Why Does Open Innovation Matter?

These open components make the intended workflow possible: after setup, Resume Button can generate cards offline, without a cloud account or per-card API fee. Notes and selected source text stay on the computer. A hosted closed API would require sending that context to a provider and depending on its availability and pricing.

Open weights and a replaceable inference endpoint also let someone try another local model. The application's MIT license makes the prompts, evidence rules, storage, and recovery code available to inspect and adapt.

Local inference has tradeoffs: the initial download is about 1.1 GB, CPU generation can be slow, and saved data is plaintext. For a tool built around unfinished work, being able to keep running with local context and a model you control is valuable.

AI disclosure: Codex assisted with implementation, verification, and this write-up.

I Built a $6 Menu Translator Cafes Actually Want (Gemma Local, $0 API Cost)

Aditya D — Tue, 13 Oct 2026 06:55:22 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

DineLingo — a local-first menu translator a real restaurant would pay for.

Type a dish in Hinglish like Masala Dosa - crisp rice crepe, aloo masala → get a tourist-ready line + allergen + veg flag, QR-ready for table tents:

Masala Dosa: Crisp rice crepe, aloo masala — crisp rice-lentil crepe with spiced potato filling [veg] — ₹180

Who pays: single-location restaurants with tourist footfall and no English menu. Pitch: “₹499 / $6 one-time for 30 dishes + QR. No monthly SaaS, your recipes never leave your laptop.” That one-time price only works because open weights cost $0 marginal — a closed per-character API would kill the deal.

Problem it solves: owners lose foreign customers daily to “what is Chole Bhature?” Generic translate apps mangle dish names, need internet, and send recipes to a server they don’t control.

Demo

Local demo (2 min, no GPU, zero downloads for phrasebook mode):

pip install -r requirements.txt
python demo.py   # offline CLI — 5 dishes
python app.py    # Gradio UI on http://localhost:7860

Try: Masala Dosa → Spanish → Dosa masala crujiente con relleno de papa especiada (vegetariano, contiene gluten) — Rs180

Video/screenshots: run python app.py, screenshot the Gradio UI + python demo.py output and attach to this post. Live link pending — local-first by design, deploy optional on Render.

Code

AdityaAneNenu / dinelingo

🍽️ DineLingo — Local-First Menu Translator (HF26 Week 2: Side Hustle)

Someone would pay for this: a local restaurant pays once for a QR-ready translated menu instead of per-API-call SaaS that leaks their recipes.

Repo: https://github.com/AdityaAneNenu/dinelingo

Stack: 100% open-source AI — Google Gemma open weights via Hugging Face Transformers. No closed APIs. Demo runs offline with zero downloads.

Why this wins Week 2

Real payer: single-location restaurant (tourist footfall, no English menu).
Why open > closed: $0 marginal cost per translation, works offline during outages, menu data never leaves laptop, owner can edit phrasebook + fine-tune Gemma later.
Partner track: Best Use of Gemma (google/gemma-2-2b-it, local via transformers).

Quickstart (2 min, no GPU, no downloads)

pip install -r requirements.txt
python app.py
# open http://localhost:7860

Upgrade to real Gemma-local (optional, still free)

Accept license at https://huggingface.co/google/gemma-2-2b-it
HF_TOKEN=hf_xxx in .env (see .env.example)
Restart — engine flips from phrasebook-demo →…

View on GitHub

Full repo: https://github.com/AdityaAneNenu/dinelingo

app.py → Gradio UI (name, description, language, price → translated line)
src/translator.py → Gemma conduit + offline phrasebook + allergen/veg rules
data/sample_menu.csv → 5-dish demo menu
demo.py → CLI demo for screenshots
requirements.txt → torch(cpu), transformers, accelerate, gradio

How I Built It

Open-source AI is the core, not a wrapper:

Open-weight model: google/gemma-2-2b-it via Hugging Face transformers with device_map=auto, bfloat16 on CUDA / float32 on CPU. Lazy-loaded in try_load_gemma() only when HF_TOKEN is set (accept license at https://huggingface.co/google/gemma-2-2b-it).
Local inference: no closed APIs, no server calls in local mode. phrasebook-demo engine runs fully offline on day one; flips to gemma-local automatically when token + torch present.
Owner-editable phrasebook: 12 Hinglish → English glosses (paneer tikka, chole bhature, etc.) — this is the fine-tune seed the owner controls.
Deterministic safety: allergen + veg flags in code (ALLERGEN_HINTS, detect_veg) so judges see safety beyond LLM vibes.
UI: Gradio 6.x, 4 inputs, examples preloaded, provenance line shows Engine: phrasebook-demo|gemma-local | Veg | Allergens.

Why Does Open Innovation Matter?

Cost makes the business work: closed translation API = per-char billing. 30 dishes × re-translates = monthly bleed. Gemma-local = $0 marginal → ₹499 one-time is profitable.
Privacy closes the sale: recipes stay on the owner’s laptop. Real objection: “I don’t want my menu on someone’s server.”
Niche beats generic: generic APIs output “chickpea bread” for Chole Bhature. My phrasebook + future Gemma fine-tune nails house dishes.
Offline survives reality: power/internet cuts kill cloud SaaS. Local still translates and sells.

Open is what makes this a side hustle instead of a SaaS resell.

My Agent Session

Built with a coding agent — session transcript available on request. Remove this line if you save via DevRelay: {% agent_session YOUR_SESSION_ID %}

My First User

TODO — do this for bonus points (see FIRST_USER.md in repo):

Shop: [name/area] — Reaction: “[quote]” — Paid ₹499? [yes/would-pay/no] — Next ask: “[e.g. add photos + Hindi]”

Script: walk in off-peak, translate 5 dishes live on laptop, ask “If I gave you all 30 + QR for ₹499 one-time, would you take it?” Photo owner + menu with permission.

If you haven’t landed one yet, delete this section before publishing — but judges give bonus for it, so go get one cafe today.

Prize Categories

Best Use of Gemma ($200) — running google/gemma-2-2b-it locally via Hugging Face Transformers as the translation core.

Touch Grass Garden: an offline garden planner with a local LLM that gets you outside 🌱

Aditya D — Thu, 08 Oct 2026 08:32:12 +0000

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

Touch Grass Garden: an offline garden planner with a local LLM that gets you outside 🌱

TL;DR: Tell it your city, and it tells you exactly what to start, sow, transplant, or plant this week. A 1 GB open-weight model runs entirely on my laptop and writes the weekly briefing. No API keys, no cloud, and no internet connection required. The screen is the shortest part of the experience: check the plan, close the laptop, and go touch grass. 🌱

🔗 Repository: https://github.com/AdityaAneNenu/touchgrass-garden

⚖️ License: MIT

🤖 Model: Qwen2.5-1.5B-Instruct, Apache-2.0

What I Built

Touch Grass Garden is an offline garden planner designed to get people away from their screens and into the real world.

Instead of constantly searching the internet for gardening advice, you give the CLI your city and it calculates what you should be doing in your garden this week.

The project has two layers:

1. Deterministic Gardening Planner

The core planner uses only Python's standard library and bundled JSON data.

It includes:

Average frost dates for 50 US metros
Planting rules for 30 crops
Frost-date-based calculations
Planting windows
Automatic year rollover
Priority ordering for tasks

Every gardening action is calculated from actual planting rules.

For example:

Tomatoes: start indoors 6 weeks before the last frost.

A task becomes due when its target date falls within ±10 days of today.

This means the core planner works even with zero AI and zero internet access.

2. Local AI Garden Coach

After the deterministic planner calculates the gardening tasks, Qwen2.5-1.5B-Instruct turns those verified facts into a short weekly briefing.

The model runs locally using:

llama-cpp-python
GGUF Q4_K_M quantization
CPU-only inference

The model does not decide which crops should be planted or change any planting dates.

Instead:

User's City
     ↓
Frost Dates + Crop Rules
     ↓
Deterministic Gardening Planner
     ↓
Verified Gardening Tasks
     ↓
Local Qwen2.5-1.5B
     ↓
Weekly Briefing

This separation keeps the important gardening calculations deterministic while still using AI to make the information more useful and engaging.

The project provides seven main commands:

plan — Generate a gardening plan without AI
brief — Generate an AI-powered weekly briefing
ask — Ask the local garden coach a question
chat — Start an interactive gardening conversation
config — Configure your city or custom frost dates
cities — List supported cities
doctor — Check installation and model configuration

The planner also supports:

--json
--ics

for exporting plans as structured JSON or calendar events with day-before reminders.

The idea behind the project is simple:

1. Run the planner.
2. Check what needs to be done.
3. Close the laptop.
4. Go outside.
5. Actually garden.

The screen should help you get outside — not become the activity itself.

Real Local Output

This was tested on my 8 GB RAM, GPU-less Windows laptop.

> touchgrass brief denver --date 2026-03-15

DO THIS WEEK (9 jobs, in priority order):

+ Start indoors Peppers                                Mar 10 (5 day(s) ago)
+ Start indoors Tomatoes                               Mar 24 (in 9 days)
...

WEEKLY BRIEFING (local Qwen2.5-1.5B, running on this machine)

...model-generated encouragement and priority list...

[qwen2.5-1.5b-instruct-q4_k_m.gguf loaded in 7.3s,
 generated at 6.8 tok/s, offline]

It also works for fall gardening. For example, an October plan for Portland can correctly identify tasks such as planting tulips and garlic.

The complete unedited command demonstrations are available in DEMO.md.

Demo

Repository

https://github.com/AdityaAneNenu/touchgrass-garden

Command Demo

> touchgrass brief denver --date 2026-03-15

DO THIS WEEK (9 jobs, in priority order):

+ Start indoors Peppers
+ Start indoors Tomatoes
...

WEEKLY BRIEFING (local Qwen2.5-1.5B, running on this machine)

...model-generated briefing...

[qwen2.5-1.5b-instruct-q4_k_m.gguf loaded in 7.3s,
 generated at 6.8 tok/s, offline]

📸 Project screenshot / short demo video:

[ADD YOUR SCREENSHOT OR SHORT DEMO VIDEO HERE]

Full Demonstration

The complete output for the project's commands is available in:

DEMO.md

Code

The complete source code is available on GitHub:

https://github.com/AdityaAneNenu/touchgrass-garden

The repository contains:

Source code
Gardening data
CLI implementation
AI integration
Model download scripts
Tests
Documentation
Demo transcripts
CI configuration

The project is released under the MIT License.

The Qwen model weights used by the project are released under the Apache-2.0 license.

How I Built It

I built Touch Grass Garden using Python with a deliberate separation between deterministic logic and generative AI.

Technology Stack

Component	Technology
Language	Python
CLI	Python CLI
Gardening logic	Python standard library
Gardening data	Bundled JSON
AI model	Qwen2.5-1.5B-Instruct
Model format	GGUF Q4_K_M
Local inference	`llama-cpp-python`
Runtime	CPU-only
Testing	Automated Python test suite
CI	GitHub Actions
License	MIT

Deterministic Core

The deterministic layer contains the actual gardening logic.

It takes:

City
+
Frost Dates
+
Crop Rules
+
Current Date

and produces:

Planting Tasks
+
Task Dates
+
Priority
+
Season

Because this layer is deterministic, the application does not depend on an AI model for the correctness of the gardening schedule.

The model cannot accidentally invent a planting date because the dates are calculated before the model is called.

Local AI Layer

The local LLM receives the deterministic gardening plan as grounded context.

A fixed system prompt defines the behavior of Sprout, the garden coach.

The model then generates:

Weekly gardening briefings
Explanations
Answers to follow-up questions
Encouragement to complete outdoor tasks

The output is limited so that the briefing stays short and actionable.

The model runs completely locally.

There is no:

API key
Cloud inference
Remote server
External gardening API

required for normal operation.

Model

The project uses:

Qwen2.5-1.5B-Instruct

with:

GGUF format
Q4_K_M quantization
Approximately 1 GB model size
CPU-only local inference

On the test laptop, the model loaded in approximately 7.3 seconds and generated at approximately 6.8 tokens/second.

Testing

The deterministic test suite currently contains 61 tests covering:

Frost-date calculations
Planting windows
Year rollover
Plan generation
Calendar export
JSON export
CLI behavior
Other core functionality

The test suite does not require the model file.

This makes CI faster, cheaper, and more reliable while keeping the AI layer separate from the core correctness tests.

The repository also uses CI across multiple Python versions and operating systems.

Why Does Open Innovation Matter?

Open innovation was important because the goal of this project was not simply to add an AI chatbot to a gardening application.

The goal was to build something that could remain useful without the cloud.

Closed / Cloud Approach	Touch Grass Garden
Requires an API key	No API key required
Requires an internet connection	Works offline
Sends user location to a third party	Data remains on-device
Per-token API costs	$0/month after setup
Model is hosted remotely	Model runs locally
Fixed hosted model	GGUF models can be swapped
Requires backend infrastructure	Runs directly on a laptop

The gardening knowledge itself is bundled with the application as local data.

The AI model is also available locally.

That combination enables something that is difficult to achieve with a traditional closed API approach:

The entire experience can continue working after disconnecting from the internet.

The user's city, gardening questions, and generated conversations do not need to leave the device.

Open-weight models also make experimentation possible.

Because the application accepts GGUF models, users can potentially experiment with:

Smaller models for faster inference
Larger models for higher-quality responses
Different quantization levels
Future fine-tuned models
Other compatible open-weight models

This keeps the application architecture flexible instead of tying it to a single hosted AI provider.

Another major benefit is cost.

After installation, the application can run locally on a low-end laptop without recurring inference charges.

That makes local AI practical for a much wider range of users and projects.

Most importantly, open innovation makes the philosophy of the project possible:

AI should help reduce screen time, not create more of it.

The deterministic planner gives the system reliable facts.

The local model turns those facts into a useful briefing.

Then the user closes the laptop and goes outside.

My Agent Session

[ADD YOUR DEVRELAY AGENT SESSION HERE IF AVAILABLE]

Prize Categories

Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
Open Source
AI

I Took It Outside 🌿

[ADD YOUR REAL-WORLD FIELD NOTES HERE]

For example:

I ran the October gardening plan for my city and used the recommendations to decide what needed attention that week. After checking the generated tasks, I closed my laptop and actually went outside to work on the garden. One thing the application got right was the timing of the seasonal task, while the real-world conditions in the garden reminded me that local soil and weather can still differ from an average schedule. That was exactly the point of building this project: use the computer to create a plan, then spend the real time outdoors.

What I'd Improve

There are still several things I would like to improve.

The bundled dataset currently covers 50 US metros, although users outside those locations can configure their own frost dates with:

touchgrass config set-frost

The 1.5B model can occasionally drift from the prompt, which is another reason the application keeps the actual planting calculations outside the LLM.

Harvest forecasts are also approximate and should be treated as estimates rather than predictions.

Future improvements could include:

Southern Hemisphere support
More global city data
Persistent chat sessions
More crop varieties
Better local-weather integration
More precise gardening recommendations

Try It

Install

uv sync

Download the Local Model

powershell -ExecutionPolicy Bypass -File scripts/download-model.ps1

The model download is approximately 1 GB, resumable, and SHA-256 verified.

Verify the Installation

uv run touchgrass doctor

Configure Your City

uv run touchgrass config set-city denver

Generate a Weekly Briefing

uv run touchgrass brief

Or Generate a Deterministic Plan Without AI

uv run touchgrass plan

The deterministic planner works without loading the local model.

Final Thoughts

Touch Grass Garden started with a simple question:

What if AI could help us spend less time using computers instead of finding new reasons to use them?

The answer was to make the AI layer intentionally small.

The computer calculates the gardening schedule.

The local model explains it.

Then the user goes outside.

That's the entire idea behind Touch Grass Garden. 🌱

🔗 GitHub: https://github.com/AdityaAneNenu/touchgrass-garden

🌿 Check the plan. Close the laptop. Touch grass.

Samajh — a reader for the letters my mother couldn't read

Aditya D — Fri, 02 Oct 2026 23:31:33 +0000

Samajh — a reader for the letters my mother couldn't read

The letter

Every few weeks, an official letter arrives at home — a bank notice, an insurance renewal, a hospital bill, or another document written in formal English.

My mother can understand the underlying idea, but the language of the document makes the important part difficult to follow.

The problem is not always complexity. Sometimes one sentence determines whether something needs to be paid, when it is due, or what action is expected.

I kept seeing someone else read and explain these documents.

Understanding depended on another person.

I wanted to build something that could help with that first step.

That became Samajh.

What I built

Samajh is a document reader and explainer designed for people who may understand their own language better than the formal language used in official documents.

You provide a document, and Samajh explains it in simple language and in the reader's preferred language.

Instead of producing one large AI-generated summary, it focuses on five things:

What is this?
What is the gist?
What does it want from me, and by when?
What numbers and dates matter?
What is easy to miss, and what is uncertain?

Every factual explanation is connected back to the source document.

Input formats

Samajh can work with:

Plain text
.txt
.md
.csv
PDF documents
Photos/images when the configured AI model supports image input

It supports multiple languages, including English and Telugu, so the explanation can be presented in the reader's own language.

There is also deliberately no account, dashboard, or document history.

The goal is simple:

Understand the document first.

Why quotes matter

Large language models can produce fluent answers while still being wrong.

That becomes a serious problem when the document contains:

payment amounts
deadlines
dates
policy conditions
instructions
warnings

So Samajh does not treat the model's explanation as the final truth.

For each factual claim, the system tries to preserve evidence from the original document.

The flow is roughly:

Claim → Source quote → Verification

The quote is independently checked against the extracted document text.

If the system cannot verify the claim, it should not quietly present it as a fact.

Instead, it can mark information as uncertain or leave it out.

This was one of the most important design decisions in the project.

The goal is not to make AI sound confident. The goal is to make the result checkable.

How it works

flowchart TD
    A[Upload document] --> B[Extract text]
    B --> C[Structured AI analysis]
    C --> D[Validate model output]
    D --> E[Normalize and recover output]
    E --> F[Ground claims to source]
    F --> G[Reader-friendly explanation]