DEV Community: Anurag Yadav

Sloth Digest: I Taught Gemma to Read My Group Chats So I Don’t Have To

Anurag Yadav — Sun, 25 Oct 2026 09:36:03 +0000

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

What I Built

Sloth Digest is a small web app that reads your group chats so you don't have to.

You paste in a noisy chat from WhatsApp, Slack, Telegram or email. A few seconds later you get three things:

A two-line summary of what actually happened
What needs you, with the person and the exact deadline
What you can safely ignore (good-morning messages, stickers, match banter)

It also shows a rough "minutes saved" figure. It divides the words you skipped by an average reading speed of 200 words per minute, so treat it as an estimate.

Anyone who has come back to 200 unread messages and had to scroll for the one line that said "pay by Saturday" gets to be a little lazier. That was the goal.

Demo

Live demo: https://sloth-digest.onrender.com

There is a Try a sample chat button, so you can see a full result without pasting anything private. The sample is a made-up chat about a trip and a deadline.

https://youtu.be/NIsI54rqJQY

Code

https://github.com/ypunit757-prog/Sloth-Digest

How I Built It

The stack is deliberately small: a Node + Express server and a plain JavaScript frontend, with no framework and no build step.

The open-source AI piece is Gemma, Google's open-weight model. The server has one switch, AI_PROVIDER, that decides how Gemma is run:

On my laptop: Gemma runs through Ollama (gemma3:4b). Inference is fully local.
In the deployed demo: The same Gemma family is served through the Gemini API, and the app is hosted on Render.

The route handler is the same either way. Only the model call changes:

const text = PROVIDER === "gemini"
  ? await askGemini(model, buildPrompt(chat))
  : await askOllama(model, buildPrompt(chat));
const digest = extractJson(text);

A few things I learned along the way:

Gemma on the Gemini API takes no system instruction. I put the rules in the prompt itself instead, and used one prompt for both providers.
Small models don't always return clean JSON. The server strips markdown fences, pulls out the JSON object, and validates the shape before it reaches the UI.
The browser never sees a key. It only talks to /api/*, so the Gemini key lives in a Render environment variable. The server also rate-limits requests and caps input at 12,000 characters.
Slowness is a feature. The loader is a slow-moving bar, in keeping with the sloth theme.

Why Does Open Innovation Matter?

Group chats are some of the most private text we have. They hold family plans, money, health news and gossip. Pasting that into a closed API means trusting a company with it.

Because Gemma has open weights, I could build the same app so it runs entirely on my own machine. With Ollama it works offline, costs nothing per run, and sends nothing anywhere. A closed API wouldn't let me make that promise.

Open weights also gave me freedom to move. The same model family runs locally and on a hosted API, and I switched between them with one environment variable. If a model improves or a price changes, I can swap it without rewriting the app.

I'll be honest about the trade-off: my hosted demo calls Gemma through an API, so the demo is not private the way local mode is. The local mode is the privacy-first version, and the hosted one is there so you can try it quickly.

The Lazy Payoff

The app's own estimate for the sample chat (about 120 words) is roughly half a minute of reading saved. That's small for one chat, but it adds up over a busy week of active group chats.

[

Prize Categories

Best Use of Gemma: Gemma is the core of the app. It runs locally through Ollama and is served through the Gemini API for the hosted demo.
Best Use of Render: The app is deployed on Render with a render.yaml blueprint, so the whole deploy is one click plus an API key.

ListingLoom: an Etsy and eBay listing writer that runs on an open model I control

Anurag Yadav — Sun, 18 Oct 2026 00:13:28 +0000

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

What I Built

ListingLoom is a listing writer for small sellers on Etsy and eBay. You describe what you made (product, materials, scent or style, a few details, and what it cost you), pick a voice, and it returns a title, a description, tags, and a suggested price range.

The person who would pay for it is the maker who lists a few new items every week and hates the writing part. Anyone who sells candles, ceramics, prints or resale finds knows the routine: you finish the product, then spend twenty minutes staring at an empty description box and guessing which tags buyers search for.

The price suggestion is what I think makes it more than a text generator. Most sellers price by feel and forget that marketplace fees take a real bite. ListingLoom takes your cost to make, subtracts estimated fees for the marketplace you chose, and shows a range that leaves you roughly 30 to 45 percent profit.

There are three plans on the pricing section: Free for people who self-host, Seller at $9 a month for a hosted version with saved voices and listing history, and Studio at $29 a month for bulk CSV uploads and a model tuned on a shop's best sellers. The paid plans are a waitlist for now, and the form on the page collects emails.

Demo

Live app: https://listingloom.onrender.com

[Video demo: https://youtu.be/0fweN4gcJL8]

Code

https://github.com/ypunit757-prog/ListingLoom

How I Built It

The app is a small Node and Express server with a plain HTML, CSS and JavaScript front end. There is one real dependency, Express.

The writing is handled by an open-weight model, Gemma [confirm the exact model you ran, for example gemma3:1b], through a standard OpenAI-style chat endpoint. The server only needs three settings: a base URL, a model name and an optional key. That means the same code works with Ollama on a laptop, a model server on a private network, or a hosted provider that serves open models.

A few details that took more work than I expected:

Structured output from a small model. The server asks for a single JSON object, then pulls the first object out of the reply and checks it. It also trims the title to the marketplace's limit (140 characters on Etsy, 80 on eBay) and caps the number of tags.
No made-up facts. The system prompt tells the model to use only what the seller provided and to avoid inventing sizes, certifications or health claims. A candle listing that claims it is "allergy safe" can cause real trouble, so I kept the model on a short leash.
A fallback that is honest about itself. If no model is connected, or the model call fails, the server returns a simple template draft instead of an error. The result card says which one wrote the listing, either the model's name or "Template draft", so a seller is never told a template is AI output.
The price math lives on the server. It is deterministic, not generated by the model. The fee percentages sit in one table and are estimates, so they need checking against current marketplace fees.
Basic protection. Inputs are length-limited, and the endpoints have a small rate limiter.

I deployed it as a web service on Render, with the model settings kept in environment variables so the key never touches the repository.

Why Does Open Innovation Matter?

A listing writer only works as a business if two things hold, and an open model helps with both.

Margins. A closed API charges per token. At $9 a month, a heavy user who generates dozens of listings and regenerates the ones they dislike can quietly cost more than they pay. With an open-weight model I control, the cost of the thousandth listing is the same as the first, so a low price stays viable.

Privacy. A seller's cost of goods, supplier names and unreleased designs are the most sensitive things they own. With an open model on a server I control, none of that has to be sent to a third-party AI company. That is a practical selling point for a small business, not just a principle.

It also gives me room to change things. Swapping the model is a two-line settings change, and the Studio plan idea (a model tuned on a shop's own best-selling listings) is only possible because the weights are open. I can't fine-tune a closed API on a customer's catalogue the way I can an open model.

Prize Categories

Best Use of Gemma: the writing is done by Gemma running behind an open chat endpoint.
Best Use of Render: the app is deployed as a Render web service at https://listingloom.onrender.com.

Pocket Trail: an open-weight model writes you a walk, then tells you to close the tab

Anurag Yadav — Sat, 10 Oct 2026 15:25:22 +0000

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

What I Built

Most "get outside" apps want you to stay inside them. Pocket Trail does the opposite.

You tell it how long you have and what kind of walk you want: wander, wildlife, plants, quiet or brisk. It checks today's weather, daylight and moon phase, and an open-weight model writes a one-page trail card. The card has a title, three or four physical steps, three things to notice, what to bring, and a turn-back time. You can print it, copy it as text, or start walk mode, which shows only one countdown and the current step.

The first thing on the page is not a button. It is a clock counting how long you have been on the screen, with a goal of 90 seconds. If you linger, it turns red. The success metric is how fast you stop using the app.

Other features:

Daylight bar: a drawn arc from sunrise to sunset with your walk highlighted, so you can see how much light you have.
Notice checklist: tick things off as you spot them, and the count goes into your log.
Outings log: outings, day streak, minutes outside, and your average screen time before leaving. It stays in your own browser.

It is for anyone who has said "I should go for a walk" and then spent twenty minutes picking the perfect route.

Demo

Short video of Pocket Trail running with Gemma 3 1B on my machine (the card footer shows which model wrote each card):

Code

ypunit757-prog / pocket-trail

Pocket Trail

An open-weight model writes you a one-page walk card (print it or copy it), then gets out of your way The app times its own screen use and aims to be done in under 90 seconds.

Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.

How it works

Context in code, not in the model: weather, sunset, moon phase and season come from Open-Meteo (free, no key) and plain Python.
Gemma 3 1B (open weights) runs on the same Render service through Ollama and writes the card as JSON.
Guardrails in code: thunderstorms or under 35 min of daylight return "Not today" and no card. The turn-back time is capped 20 min before sunset. Model output is validated and step times are rescaled to your time budget.
Offline rules fallback: if the model is unreachable, a deterministic generator still returns a card, and the card…

View on GitHub

Run it yourself:

pip install -r requirements.txt
ollama pull gemma3:1b && ollama serve   # optional: without it you get an offline fallback
uvicorn app.main:app --reload

How I Built It

Gemma 3 1B (open weights) runs locally through Ollama and writes the card as JSON.
FastAPI serves one API route and one static page, with no front-end framework and no build step.
Open-Meteo supplies weather and sunset. Moon phase and season are computed in Python.

The design choice I care most about: the model only writes the prose. Code decides everything that could hurt you.

A thunderstorm nearby, or less than 35 minutes of daylight left, returns "Not today" and no card at all.
The turn-back time is computed in code and capped 20 minutes before sunset.
Gear advice (rain shell, hat, warm layer) comes from the weather numbers, not the model.
Step times are rescaled so they add up to the real walk length.
If the model is unreachable, a deterministic offline generator still returns a card, and the footer says which one wrote it.

What I learned from a 1B model. My first Gemma cards failed my own validation. The model returned steps like {"do": 1, "min": 10}, numbers where instructions should be. I fixed it by putting a worked example in the prompt and allowing one retry. Later it described crisp autumn air on a hot day, and a moonlit sky at noon, so I added a "Feels" word to the prompt and code checks that reject cold-weather wording when it is warm and any moon mention in a daytime card.

Here is a card Gemma wrote while I was testing:

Autumnal Echoes: The sunlight filters through the thinning leaves, painting the forest floor in gold.

Walk slowly towards a small, moss-covered stream.

Listen closely; you hear the faint chirping of robin chicks.

Observe a busy ant colony marching across a fallen log.

It is not perfect (robin chicks in October is a spring detail), and that is the point. A small model makes small slips, so the code owns timing, safety and gear, and the model owns the wording.

Why Does Open Innovation Matter?

No API key, no meter. The model runs on my own laptop, so there is no key to leak and no usage bill behind a free tool.
My location stays with me. Generation happens locally. The only thing that leaves is a latitude and longitude sent to the public Open-Meteo weather API, and I do not store it.
I can change how it behaves. The model is one environment variable (LLM_MODEL), and any OpenAI-compatible server works. I could swap in another open model or fine-tune one on local trail knowledge without asking anyone.
I could see the failures. Because I run the model myself, I read its raw output when it went wrong and fixed the prompt and the guardrails, which a closed API that hides retries would not have let me do as easily.
The honest downside: a 1B model is less inventive than a frontier one. For a card with a 25-word limit per item, that trade is fine.

Prize Categories

Best Use of Gemma: Gemma 3 1B runs locally through Ollama and writes every card in the demo video.

Saathi - a help application for my friend

Anurag Yadav — Mon, 05 Oct 2026 07:12:23 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

Saathi is a study companion built around one person's own notes. You add your notes. It writes quiz questions from them, asks "how sure are you?" before you answer, works out why a wrong answer was wrong, brings each question back just before you would forget it, and at the end of the week writes a short letter about how things went, in the way you like to be spoken to.

I built it for [[Rahul Kumar]], [[He is my classmate]]. [[He was often struggles to evaluate him during exam time ]]

A chatbot answers from the whole internet. [[Rahul Kumar]] does not need the internet's version of chapter 4. They need to find out what they do not understand about their notes. So Saathi works only from their notes:

Grounded questions only. Every generated question must pass a check (four distinct options, and the right answer has to appear in the source passage) before it is saved.
Confidence matters. A wrong answer you felt sure about is the most valuable signal, so it hurts the card's schedule the most and is called out in the letter.
Mistakes get a reason. The model names the likely misunderstanding behind that specific wrong choice, and the tags are counted over the week.
The letter only uses true numbers. It is written by the model but from facts computed in SQL.

Demo

[[Live link: https://saathi-1vua.onrender.com. username - admin , password - Hello@123]]

Code

[[

ypunit757-prog / Saathi

An offline study companion, built for one person

Saathi

An offline study companion, built for one person.

Saathi turns a friend's own notes into quiz questions, asks how sure they are before they answer, works out why a wrong answer was wrong, schedules each question for the moment they are about to forget it, and writes a short weekly letter in their own style of language. It runs an open-weight model (Gemma by default) through Ollama on a laptop. Nothing is sent anywhere.

Built for the DEV Hacktoberfest Weekend Challenge, "Build for a Friend" (Oct 2 to 5, 2026). All code in this repo was started inside that window.

Why it is shaped this way

Their notes, not the internet. Questions are written only from the notes you add, and every generated question must pass a grounding check (the right answer has to appear in the source passage) before it is saved. Small models make things up; this…

View on GitHub

]]

How I Built It

The model. Gemma, an open-weight model from Google. Saathi has three ways to reach it, chosen by one environment variable:

ollama: Gemma (gemma3:4b, or any Gemma you have pulled) on the laptop through Ollama. Nothing leaves the machine.
cloud: hosted Gemma 4 (gemma-4-31b-it) through the Gemini API. This is what the live demo uses.
mock: a deterministic stand-in so the app and its 45 tests run with no model at all.

Saathi talks to the model over plain HTTP, so there is no SDK between my code and the model.

Stack. Python and Flask, one SQLite file, plain HTML/CSS/JS with no CDN and no framework. Hosted on Render as a web service with a persistent disk, started with gunicorn. A password (SAATHI_PASSWORD) protects the public URL.

Four ideas that make it feel like a tutor, not a quiz generator

Grounded questions. The model returns JSON and I validate it:

   ctx = set(rag.tokenize(context))
   ans = rag.tokenize(options[idx])
   if not ans or not any(t in ctx for t in ans):
       return None   # the model invented it; drop the question

Confidence changes the schedule. Standard SM-2 only knows right or wrong. Saathi also asks whether you were sure. Wrong-and-sure scores 0, wrong-and-unsure 1, and right-but-guessing gets a shorter gap than right-and-sure.
Every mistake gets a reason. A second request asks for the misunderstanding behind that wrong choice, so the right/wrong feedback stays instant.
The letter only uses true numbers. The prompt forbids inventing anything outside the facts object.

Retrieval. "Ask my notes" uses BM25 in pure Python (plus embeddings when a local embedding model exists). If the notes do not hold the answer, Saathi says so. Optionally, the learner can tick "Also search the web" and web results are labelled as such.

Monitoring the agents. Each task is a named agent (Saathi Quiz Writer, Misconception Diagnoser, Notes Assistant, Letter Writer) traced with Sentry's agent tracing: every model call records model, tokens and latency. Prompts and notes are not sent to Sentry unless I turn that on.

Voice. The weekly letter can be read aloud with ElevenLabs.

Comparing models on the real job. bench/benchmark.py measures how often each model returns valid JSON and how many questions survive validation:

model	json_ok	questions asked	kept after validation	sec/chunk
[[gemma3:1b]]	[[ ]]	[[ ]]	[[ ]]	[[ ]]
[[gemma3:4b]]	[[ ]]	[[ ]]	[[ ]]	[[ ]]

[[Run python bench/benchmark.py gemma3:1b gemma3:4b yourself and paste the real numbers. Delete this table if you do not run it.]]

Why Does Open Innovation Matter?

Their study history is private. It is a record of everything someone does not understand yet. Because Gemma is open-weight, Saathi can run on Rahul kumar's own laptop and nothing has to leave it. The hosted demo is a deliberate trade-off, and it is the same code with one setting changed.
I could shape it. I could swap models when a small one was too slow, validate and discard its output, and rewrite the prompts so Saathi talks the way Rahul kumar talks .
It works when the internet does not. A local model does not care.
Cost. Spaced repetition means thousands of small questions. Per-token pricing turns "study a bit more" into a bill; a local open model does not.
Not locked in. The hosted backend can also be any OpenAI-compatible endpoint, so moving from Google to a GPU server I run myself is a settings change, not a rewrite.