DEV Community: Nitsuj

SlothDigest

Nitsuj — Wed, 21 Oct 2026 07:53:31 +0000

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

What I Built

SlothDigest is a ~200-line Python tool that does your morning reading for you. Overnight (via a single cron line), it:

Scans your folders for new files since the last run
Pulls new headlines from your RSS/Atom feeds
Hands the pile to a local open-weight model and asks for a two-line brief

You wake up, run cat digest.log, and know what happened. No feeds to scroll, no inbox triage — sloths move at their own pace, and so does this.

Demo

No deploy needed — it's a CLI that runs on your own machine. Here's the real session output from a test run against a mock downloads folder plus two live feeds:

First run: collects 4 new files + 20 new headlines, produces the brief above
Immediate rerun (dedup): Nothing new since the last run. The sloth rests.

That second line matters: it remembers what it has already reported, so a rerun never nags you with stale items. --dry-run mode prints the raw material without calling the model, so you can see exactly what it would read.

$ python3 slothdigest.py run

============================================================
SlothDigest — 2026-10-21 07:32 UTC
============================================================
Here's your lazy-person's morning brief:

1. New files were downloaded overnight, including a budget tracker and a
   hacktoberfest t-shirt idea, but nothing that seems critical.
2. Top 5 things to look at:
  - What nine job and property sites were advertising in mid-October 2026
  - Windows Robocopy Command: Mirror a Folder Without Deleting the Wrong Files
  - Anthropic tells investors quarterly revenue up nearly 50% to $16.8bn ahead of IPO
  - Chirp Pong
  - eMudhra Intermediate CA Compromise
3. Sloth verdict: Ignore the hacktoberfest design and just grab a coffee.

Saved to digest.log. Now go back to bed.

Code

hey-nitsuj / SlothDigest

A small Python tool that does your morning reading for you. Overnight (via a single cron line)

🦥 SlothDigest

An overnight digest that does your reading while you sleep. It watches folders for new files and RSS/Atom feeds for new headlines, then asks a local open-weight model (Gemma, via Ollama) to compress everything into a blunt two-line morning brief with a "Sloth verdict" on what to ignore.

No cloud. No API keys. No UI to test. ~200 lines of standard-library Python.

Why this exists (the lazy payoff)

Every morning the average developer re-scrolls the same feeds, re-checks the same downloads folder, and re-decides what matters. SlothDigest does that pass overnight, on your own machine, so you wake up to a decision-ready brief instead of a pile. On a normal weekday it saves 10–15 minutes of skimming — and it never sends a byte of your file names or reading list to anyone, because the model runs locally.

Requirements

Python 3.8+ (standard library only — nothing to…

View on GitHub

How I Built It

The open-weight model is the core of the project, not a decoration. The pipeline is deliberately boring everywhere else:

Local inference via Ollama — the model is llama3.2:3b (open weights, runs 100% on my CPU). Gemma was my first pick, but on a CPU-only laptop the 6.6B model took ~50s per brief; the 3B model answers in ~10s. The model tag is one line in config.json, so anyone can swap in Gemma, Qwen, or anything else they've pulled.
One POST /api/chat call with all the collected material, a fixed instruction to return a two-sentence summary, at most 5 bullets, and a "Sloth verdict". Generation is capped at 300 tokens — on CPU-only hardware an uncapped local model can grind for minutes, which looks exactly like a hang.
Everything else is Python standard library: urllib for feed fetching and the Ollama call, xml.etree for RSS 2.0/Atom parsing, a JSON state file for dedup. Nothing to install, nothing to configure beyond a config file.

Architecture, such as it is:

folders ──┐
          ├──> digest material ──> local model (Ollama) ──> 2-line brief + bullets
feeds ────┘         ▲                                            │
             .slothdigest_state.json (dedup)                    └──> digest.log

Why Does Open Innovation Matter?

Three things this build gets because the model is open and local:

Privacy by architecture. The digest's raw material includes file names from my downloads folder — invoices, resumes. A closed API means shipping that list to a third party every night. Here it never leaves the machine; the model runs on my CPU.
Cost that scales with laziness, not usage. The whole thing runs daily forever for $0. There is no per-request meter watching me be lazy.
Swap-ability. When Gemma was too slow on my hardware, the fix was changing a string in a config file — no vendor migration, no API version to chase. That's what open weights buy you that a closed endpoint can't: the right to run the model on the hardware you actually have.

The Lazy Payoff

Measured: ~10–15 minutes a day of feed-scrolling and folder-checking, replaced by one line of terminal output over coffee.
One cron line does the work:

  30 5 * * * cd /path/to/slothdigest && python3 slothdigest.py run >> /dev/null 2>&1

I'm asleep at 5:30 AM. The sloth is not. That's the entire user experience: the tool runs, and you read two sentences.

Zero maintenance surface: no server, no database, no UI to break. Dedup state is one JSON file.

Quotely

Nitsuj — Sun, 18 Oct 2026 12:16:51 +0000

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

What I Built

Built for Hacktoberfest Week 2 (Side Hustle). A small CLI that uses a local open-weight model via Ollama to generate freelance quotes.

Takes a few inputs (client, description, hours, rate, timeline, currency) and outputs a simple Markdown quote. Runs entirely locally with Ollama, so client info stays on the machine.

Demo

Example Output:

# QUOTE

**Quote #:** Q-20261018
**Date:** 2026-10-18
**To:** Acme Corp

---

## Project Description

Build a landing page with contact form

---

## Scope of Work

- Design and development of responsive landing page
- Implementation of contact form with validation
- Mobile-friendly layout and cross-browser testing
- Deployment-ready deliverables

---

## Pricing

| Item | Hours | Rate (USD) | Amount (USD) |
|------|-------|------------|--------------|
| Landing page development... | 8 | 75.00 | 600.00 |

**Total:** USD 600.00

## Terms & Conditions

- **Payment:** 50% deposit required to begin work. Remaining balance due upon completion.
- **Validity:** This quote is valid for 30 days from the date issued.
- **Revisions:** 2 minor revisions included. Additional scope billed at quoted rate.
- **Timeline:** As discussed

Thank you for your consideration!

Code

hey-nitsuj / qoutely

A small CLI that uses a local open-weight model via Ollama to generate freelance quotes.

Quotely - Local AI Quote Generator for Freelancers

Quotely is a simple CLI tool that generates professional freelance quotes using a local open-weight model via Ollama. All client data stays on your machine - no third-party APIs, no data leakage, and zero ongoing costs.

🎯 Hacktoberfest Open-Source AI Challenge: Week 2

This project was built for the Hacktoberfest Week 2: Side Hustle challenge. The theme is to build something with open-weight models or open-source AI that someone would actually pay for.

Why open innovation matters

Privacy-first: Client project details, hours, and rates never leave your laptop
Zero costs: Once you have a model running locally, there are no API charges - critical for maintaining profit margins on a side hustle
No vendor lock-in: Swap between any open-weight model (Llama, Qwen, Gemma, etc.) with a simple flag
Offline capable: Works without internet connectivity
Transparent & auditable…

View on GitHub

How I Built It

Python CLI (quotely/cli.py, quotely/generator.py, quotely/formatter.py)
Uses Ollama's /api/generate with think: false for reasoning models
Defaults to qwen3.5:4b; any local model should work

Setup

pip install -r requirements.txt
ollama pull qwen3.5:4b

Usage

python3 quotely.py --client "Client" --description "Work" --hours 4 --rate 60

Why Does Open Innovation Matter?

Running locally keeps costs at zero and avoids sending client details to third-party APIs. It also avoids being tied to a specific vendor's pricing.

Touch Grass Bingo: an offline AI walk card that never leaves your browser

Nitsuj — Wed, 07 Oct 2026 14:03:47 +0000

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

What I Built

Every "AI feature" in a web app today is a round trip: collect input, send it to a hosted
model, stream tokens back. For a game whose whole point is getting you off the screen, a
server would have been both a contradiction and a liability — someone else would know where
you walked.

So Touch Grass Bingo runs Gemma 3 1B inside the browser, via
WebLLM and WebGPU. Pick a habitat, a time of day, and an
optional focus ("birds, street art, dogs"). The model writes a 5×5 bingo card of things you
can actually spot in the next 15 minutes. You tap squares on your walk — with zero signal —
and afterwards the same model writes a short field recap of your outing.

No accounts, no API keys, no analytics, no server. After the first visit it works in
airplane mode.

What it asks for, and what you get

flowchart LR
    subgraph Browser["Browser (static files, any CDN)"]
        UI["UI shell<br/>13 KB app JS"]
        SW["Service Worker<br/>precaches app + engine"]
        subgraph Worker["Web Worker"]
            H["WebWorkerMLCEngineHandler"]
            E["MLCEngine / TVM"]
        end
        Cache["Browser weight cache"]
        Store["localStorage<br/>current card"]
    end
    HF[("HuggingFace CDN<br/>gemma3-1b-it-q4f16_1-MLC<br/>~570 MB, once")]

    UI -- "dynamic import()" --> E
    UI --- Store
    UI --- SW
    SW -. precache .- E
    E -- "one-time fetch" --> HF
    E --- Cache
    H -- "chat.completions.create()" --> E
    E -- "24 squares / recap" --> UI

Generation runs in a Web Worker so the UI never janks while the model prefills, and the
6 MB engine chunk is lazy-loaded on first Generate — the initial page is 13.8 KB of app
code.

Why open innovation is the whole project, not a footnote

The challenge asks why the open piece matters. For this app it is the app:

It runs on a phone in the backcountry with no internet. Weights are cached after the first load; generation, checking, and recaps are all local. A closed API can't promise that, and I'd have nothing to demo at mile three of a trail.
Your location data stays off a server you don't control. The app never sees where you are. There is no backend to leak.
It costs nothing to run. Static hosting, no inference bill, no rate limits.
The model is swappable in one line. WebLLM ships Llama, Qwen, Phi and more in its prebuilt config — change MODEL_ID in src/engine.ts and the card's personality changes.

The interesting engineering problem: 1B models are flaky

The fun part wasn't calling an API, it was making a small model reliable enough for a game
that must always produce exactly 24 squares. Defenses, in order:

Failure mode	Defense
JSON wrapped in prose or markdown fences	bracket-hunting parser
Model answers with a numbered list instead of JSON	line-based fallback parser
JSON arrays with trailing commas (Gemma's signature)	salvage quoted strings when strict `JSON.parse` fails
Repeated squares across attempts	case-insensitive dedupe
Single-word lazy squares (`dog`, `leaf`, `flash`)	bare-noun gate drops them; card tops up from the pad pool, or regenerates
Recap falls into a repetition loop (`a another dog…`)	`repetition_penalty` + degenerate-output detector + colder retry
Fewer than 24 items returned	top-up from a themed pad pool
Genuinely bad response	retry with a stricter prompt, then a built-in preset deck
No WebGPU / failed worker	preset decks + an honest status chip, never a dead end

Every path terminates in a playable card. The parser and defense tests live in tests/extract.test.ts.

A detail worth stealing: before picking the model I checked WebLLM's prebuilt config for
required_features. Plenty of popular q4f16_1 builds declare
required_features: ["shader-f16"] and throw ShaderF16SupportError on GPUs without that
feature. gemma3-1b-it-q4f16_1-MLC (711 MB VRAM, low_resource_required: true) does not —
which makes it the right default for a game anyone should be able to open. Another landmine:
Gemma 3's config ships both context_window_size and sliding_window_size positive, which
WebLLM refuses (WindowSizeConfigurationError) — unless you disable one at load time via
chatOpts: { sliding_window_size: -1 }. Feature-detecting navigator.gpu up front and
falling back to preset decks keeps the promise: the app never dead-ends.

Getting it running

git clone https://github.com/hey-nitsuj/Touch-Grass-Bingo
npm install
npm run dev        # local dev
npm run test       # parser tests
npm run build      # typecheck + production build

WebGPU needs a secure context — https:// or localhost, nowhere else.

What I'd do differently

Streaming. Card generation currently resolves as one blob; streaming the 24 squares in as they decode would make the wait feel shorter. WebLLM supports it; I chose simplicity first.
A service worker engine host. WebLLM can host the engine in a service worker so the model survives reloads without a worker respawn. Worth it for a v2.

Try it, then go outside

The point of the game is that the screen is the shortest part of the experience. Generate a
card, put the phone in your pocket, walk, and come back for the recap.

Play it live: https://hey-nitsuj.github.io/Touch-Grass-Bingo/ — or read the source at
github.com/hey-nitsuj/Touch-Grass-Bingo.

Built with WebLLM + Gemma 3 1B (open weights), Vite, and no backend at all. MIT licensed.