DEV Community: Samar Nathani

One Real Docstring a Night: A Local Open-Weight Model That Keeps a Streak Honest

Samar Nathani — Sun, 25 Oct 2026 02:07:16 +0000

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

What I Built

streakkeeper is a nightly GitHub Action that makes one small, real documentation improvement to one of my repositories, then stops.

It is scheduled for 22:30 every night. It wakes up, asks GitHub whether I have already contributed today, picks a repository, shallow-clones it, and walks the Python syntax tree for a docstring or README section that is missing or says nothing. A local open-weight model drafts the text. A second model reads the same code and decides whether the draft is true. If it is, the script proves the code did not change, commits one file, and goes back to sleep.

The effort it saves is not typing. It is the ten minutes every evening when I think "I should commit something", open a repo, stare at it, and close it again. That loop is gone, and what replaces it is a change a reader would actually want.

What it will not do is manufacture a contribution. No empty commits, no whitespace, no generated files. If nothing passes review, the run ends and nothing is committed. The tool is allowed to do nothing. It is not allowed to invent work.

Demo

The demo is the schedule itself: the workflow, and a commit it made on its own on a placeholder CLI.

Looking at SammySN-car/jev-deliberation-judge
  review rejected cli: The proposed text asserts that the implementation was completed, whereas the code only states it is implemented in M5 without indicating completion status.
Committed src/deliberation_judge/cli.py to SammySN-car/jev-deliberation-judge

Three lines, the whole loop: it looked, the reviewer threw out the first draft, it tried the next place, and it committed a docstring.

The commit is one line added and nothing else:

 def main() -> None:
+    """Raises a SystemExit upon execution. The exit message indicates that the judge CLI is not implemented yet. This message also references milestone M5."""
     raise SystemExit("judge CLI not implemented yet (milestone M5)")

A dry run, from a separate dispatch, stops one step earlier and shows the text before it is written:

Looking at SammySN-car/devpulse
Would update SammySN-car/devpulse/src/devpulse/__init__.py:1
  reviewed: The proposed text accurately describes the __version__ assignment without introducing unsupported claims, markdown formatting, or speculative language.
  --- new text ---
  Defines the module's version number. The variable __version__ is assigned the string value "0.1.0". This variable provides a specific version identifier for the package.

The part worth reading is the reviewer's sentence. It rules out "markdown formatting" and "speculative language" by name, because those were the two ways the first drafts went wrong: backticks inside docstrings, and hedged verbs like "likely".

Code

SammySN-car / streakkeeper

One small, real documentation improvement per night, so a contribution streak survives busy days.

streakkeeper

Makes one small, real documentation improvement to one of your repositories every night, so a contribution streak survives the days you are too busy to commit.

A placeholder commit keeps the streak alive and makes the history worse. This does the opposite: it finds a docstring or a README section that is missing or says nothing, writes it properly, proves the code did not change, and commits that one file.

What happens each night

Gate. Ask GitHub how many contributions you have today, in your own timezone. If it is more than zero, stop.
Rotate. Start from a different repository each night, then shallow-clone one of them.
Scan. Walk the Python syntax tree and list the places where documentation is missing or too thin: modules, classes, functions, methods and README sections that are a heading and nothing else. This step is deterministic and uses no model.
Rank. A small…

View on GitHub

How I Built It

Eight steps, and only three of them involve a model:

Gate. Ask GitHub how many contributions I have today, in my timezone. If it is more than zero, stop.
Rotate. Start from a different repository each night (day.toordinal() % len(repos)), so no single project takes all the attention.
Scan. Walk the Python syntax tree and list modules, classes, functions and README sections whose documentation is missing or shorter than forty characters. Deterministic, no model.
Rank. The local model orders those candidates and keeps the best fifteen.
Write. The same local model drafts the text for the best one.
Review. A different model reads the code and the draft and returns {"ok": true|false, "reason": "..."}.
Verify. Strip every docstring from both versions of the file and compare ast.dump. If anything else differs, refuse.
Commit. One file, one commit, one push.

The split is the design. The scan decides where to look, so a model can never invent a place to write. The model writes, and a different model judges. Nothing in the pipeline is both author and approver.

The models. Ranking and writing run on gemma4:e4b through Ollama, inside the GitHub runner: 5.5 GB of model cache, restored in about forty seconds, in a job that takes about five minutes end to end. Review runs on gemini-3.5-flash with thinking disabled, falling back to gemini-3.1-flash-lite, because a busy reviewer should not be able to block the night. An unclear verdict counts as a rejection, never as approval.

The proof. verify.code_unchanged() parses both versions, removes every docstring, and compares the syntax trees. Comments are not in the tree, so a comment-only edit passes. A docstring edit passes. Anything else fails and the run exits non-zero. The code cannot change by construction, not by good behaviour.

Seventy-one tests cover the scanner, the replacement logic, the parser for each model's answer, the review gate and the GitHub helpers. None of them need a network or a model.

Why Does Open Innovation Matter?

Because the part that does the work is open, and I needed to see inside it.

The writer is an open-weight model running on the same machine as the tool. That is not a purity badge; it is what made the thing debuggable. When gemma4:e4b kept wrapping text in backticks that do not belong in a Python docstring, I could read the raw JSON, tighten the prompt, and then strip backticks in code instead of hoping the next prompt would behave. When it hedged - "likely", "suggests" - I could watch it hedge again on the same input. A closed writer would have handed me a wrong docstring and no way to see why.

It also costs nothing per night, runs on a free runner, and can be pointed at different models with two variables:

OLLAMA_MODEL=gemma4:e4b                                 # the writer
REVIEW_MODELS=gemini-3.5-flash,gemini-3.1-flash-lite    # the auditor

The reviewer is the one closed component, and I want to be straight about that. It is a second opinion, not the worker, and it is replaceable. If no reviewer answers, the run stops and nothing is committed. The writing - the part that makes the project work - is open and local.

The Lazy Payoff

After setup the tool asks nothing of me: one file, one commit, one push, about five minutes of compute, zero minutes of attention. Of those five minutes, roughly two and a half are the tool itself; the rest is installing Ollama and restoring the model cache.

The honest accounting is that it has run for real twice. One commit landed. One was reverted, and that is the better story.

The night it deleted a code block. The first real run added a docstring to a README section and, in doing so, removed a fenced bash block containing ollama pull llama3.2. The cause was one line in the scanner:

# roughly how the scanner decided which lines were headings
headings = [line for line in lines if line.lstrip().startswith("#")]

A shell comment inside a fenced block - # Runs on localhost:11434 by default - is not a heading, but that line said it was. The section was measured as ending at the comment, so its body looked twenty-eight characters long, and the writer replaced the body, fence included. The reviewer approved it, because the text accurately described the command that was about to disappear.

I reverted the commit within minutes. The fix is a fence-aware scan, plus a refusal to replace any section containing a code block, with tests for both. That is the lesson of the week: a tool that does nothing is better than a tool that does damage, and only a real run could have found this. Every dry run was clean.

The commit that would not have counted. The first version committed as streakkeeper <streakkeeper@users.noreply.github.com>. GitHub credits a commit to your streak only when its author email is associated with your account, so the tool would have worked perfectly and kept no streak at all. A dry run cannot catch that either, because a dry run never commits. It now derives the account's no-reply address from the API and commits as me.

Prize Categories

Best Use of Gemma - gemma4:e4b ranks the candidates and writes the documentation, locally through Ollama. Without it there is no text and no commit.

A Local Job Agent That Reads Your Code to Find Your Level (and the 4B Model That Invented a Basketball League)

Samar Nathani — Sat, 17 Oct 2026 23:17:47 +0000

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

What I Built

freelance_search is a job agent that runs entirely on my machine. On a schedule it crawls five job sources, discards whatever is a bad fit for me specifically, and posts a shortlist of 20–30 links to Discord. No feed to scroll, no tabs to keep open, no applications wasted on roles I am not senior enough for or cannot legally take.

The problem it solves: if you are a freelancer, intern, or junior developer job-hunting across several boards, you redo the same triage by hand every day. You open five sites, skim a hundred listings, and mentally discard the ones in the wrong country, the ones titled "Staff Engineer," and the ones whose links already 404'd. That is an hour of low-grade work a machine should be doing.

Who would pay for it: anyone stuck in that loop. The job-search tooling market exists because people pay for leverage when they are competing against hundreds of applicants. This automates the triage step, on your own hardware, without shipping your profile to anyone.

Demo

Code

SammySN-car / freelance_search

Daily freelance job scout — SerpApi + free feeds, scored by a local Gemma model, shortlist delivered to Discord

freelance_search

freelance_search is a daily opportunity scout that anyone can point at their own career stage: it searches SerpApi Google Jobs and free remote-job feeds for freelance work, internships, and entry-level jobs, scores each new listing with a local Ollama Gemma model against your profile, and posts a ranked list of up to 25 links to Discord each morning. A job is persisted as shown only after Discord confirms delivery, so the same job is never shown twice.

Everything it optimizes for comes from your own configuration — there is no hardcoded location or seniority bias in the code.

Quickstart

Requirements: Windows, Python 3.11+, and Ollama running locally.

python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install -e ".[dev]"
ollama pull gemma3:4b
Copy-Item .env.example .env
# Edit .env: Discord + SerpApi values, then your PROFILE,
# LOCATION, and EXPERIENCE_LEVEL (see Customization below).
python -m

…

View on GitHub

How I Built It

Two open-weight models, both running locally through Ollama:

mxbai-embed-large — embeds my profile and every listing into a shared vector space. Dense cosine similarity ranks candidates; it never discards them.
gemma3:4b — the judge. It reads the top candidates and scores each one 0–10 against my profile, with a one-line reason.

The retrieval funnel, per run: crawl roughly 700 raw listings from five sources (Arbeitnow, Jobicy, remoteOK, We Work Remotely, and SerpApi's google_jobs engine) → embed → rank by similarity → hand the top 50 to Gemma for scoring → keep everything above a floor → post the best 20–30 as a links-only digest.

The part worth writing up is how the agent decides what "a bad fit" means, because I got it wrong twice.

First I tried keyword filtering. Drop any listing whose text mentions "senior," or whose location field names a country that is not mine. It worked, and it was a mistake. It threw away good listings that used the word incidentally, and it hid listings that described senior work without the title. Filtering on keywords is information loss. So I split the problem in two: dense retrieval handles relevance and discards nothing, and the only hard drops are the two things a keyword genuinely settles — a stated foreign location, and a seniority title that contradicts my level. Both come from my .env, so the agent carries no hardcoded bias toward any country or any seniority. It filters for me, not for a hypothetical average user.

Second, I had it read my GitHub to work out my level. Telling the model "you are matching for an intermediate developer" is a guess I typed in. Instead the agent lists my repos, pulls real source from each, and asks Gemma to name a level — but only after citing the specific files that prove it:

# Instruction goes AFTER the code: with a large code context, gemma3:4b follows
# recency and ignores format rules placed before it (verified locally).
GITHUB_PROMPT = (
    "CODE:\n{code}\n\n"
    "Now answer based ONLY on the code above, output exactly two lines:\n"
    "Level: beginner|intermediate|senior\n"
    "Evidence: <one line citing at least two specific repo or file names as proof>\n"
    "Judge what the code demonstrates: completeness, structure, testing, and complexity. "
    "Ignore stars and popularity. Output only those two lines, nothing else."
)

That comment is the whole post, really. Here is why it is there.

Why Does Open Innovation Matter?

Because I could only fix this bug because the model is open-weight and running on my machine.

The first version of that GitHub prompt asked Gemma for a JSON object — {"level": ..., "evidence": ...} — with the instruction placed at the top, before the code. On a large code context, gemma3:4b under JSON mode collapsed. Feed it roughly 63,000 characters and it returned an empty {}. Feed it roughly 30,000 and it invented an entire basketball league as its JSON response — a structure with nothing to do with the code, confidently emitted.

A closed API would have hidden every step of that. I would have gotten a wrong answer with no way to see why, no way to re-run the exact prompt and watch it fail differently at different context sizes, and no cheap way to iterate through five variations. Running it locally, I reproduced the failure on demand, bisected it by prompt length, and found the two things that actually mattered: put the instruction after the code (the model follows recency, not position), and ask for two plain-text lines instead of JSON (the parser takes the first Level: and Evidence: lines and ignores whatever else is echoed back). One retry, and it has held ever since.

That is the case for open innovation in a single bug report. An open, local model turned a silent wrong answer into a debuggable one. It also means my code, my job history, and my profile never leave my machine — which, for a tool that reads your source repositories to judge your skill level, is not a nice-to-have. It is the only version of this I would be willing to run.

My First User

Me. It has been running against my own profile daily through the entire build, which is how the basketball-league failure got caught in the first place — a staged demo would never have pushed a 63k-character context. No one else has used it yet, and nobody has paid for it. (Cut this section if you would rather not include a self-described first user.)

Prize Categories

Best Use of Gemma — gemma3:4b is both the judge and the level-detector. It runs locally through Ollama and is what makes the ranking work at all.
Best Use of SerpApi — the google_jobs engine is one of the five sources, surfacing Google-indexed roles that never appear on the boards directly.

I drove an AI agent to build a local-first outdoor quest game in a day

Samar Nathani — Sun, 11 Oct 2026 03:35:46 +0000

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

What I Built

SYSTEM://GRASS is a local-first outdoor quest game. An AI "System" assigns you one outdoor micro-quest per day, judges your photo evidence, narrates the verdict in a dry System voice, and tracks your rank from F to S — with real XP penalties for ignoring it.

The loop is deliberately short: open the app, see today's quest, go outside, snap 1-3 photos, submit. Screen time is seconds; the rest happens outdoors. Miss a quest by the deadline and you drop a rank step. The System remembers.

The phone is a dumb terminal. The brain — quest generation, judgment, narration — runs on a laptop via Ollama. Built for Hacktoberfest 2026 Week 1 ("Touch Grass").

Demo

A short screen-recorded walkthrough of the core loop: the quest loads, evidence is captured and submitted, and the System returns a verdict with its narration.

One honest note: this demo only really covers the single main path — one quest taken, submitted, and judged. The offline buffer and the rest of the loop are in the code and test suite, but I didn't have the energy to film them. I'd been awake most of the night building this and just didn't have the strength to step outside or do a longer take. The photos in the demo are indoor shots for the same reason. The quest itself is outdoor-oriented; the recording just shows the judgment loop working.

Code

SammySN-car / touchgrass

Hacktoberfest 2026 Open-Source AI Challenge Week 1 (Touch Grass) - scratch repo, design TBD

SYSTEM://GRASS

A local-first outdoor quest game. An AI "System" assigns you one outdoor micro-quest per day, judges your photo evidence, narrates the verdict, and tracks your rank from F to S - with real penalties for ignoring it.

Built for the Hacktoberfest 2026 Open-Source AI Challenge: Week 1 ("Touch Grass"). Submission post tagged #hf26challenge.

What makes it different

100% local. Quest generation and judgment run on your own machine via Ollama (Gemma). No cloud, no accounts, no API keys. Your photos never leave your laptop.
Phone = terminal. A mobile web app on your LAN captures evidence; the brain stays home. The screen is the shortest part of the experience.
Consequences, not confetti. Ranks, XP, streaks, demotions. The System is harsh but recovery is always one quest away.
System-window aesthetic. Isekai-inspired interface. Original names and lore - not affiliated with any rights holder.

Docs

docs/design.md - frozen…

View on GitHub

Python 3.13 + FastAPI + SQLite backend; vanilla JS/CSS frontend (no build step); Ollama + Gemma for narration. 61 tests green, ~2,200 lines, 20 commits.

How I Built It

The open-source AI at the core is gemma3:4b running locally through Ollama. No API key, no per-call bill, no request leaves the machine.

I built this by driving an AI coding agent, task by task, over a single day. I froze a design doc, split the work into ten tasks with exact contracts, and let the agent implement each one against a failing test first (TDD), committing after every green. I reviewed every diff.

Two design decisions worth calling out:

Two-tier judge. Tier 1 is deterministic rules (photo count, freshness vs. quest issue time, deadline, file-size sanity) that produce the skeleton PASS/FAIL — never depending on the model. Tier 2 is Gemma narration: quest text + evidence metadata into a dry System-voice line. If the model contradicts the rules verdict, the model's line is discarded and a canned bank line is used. The model narrates; it never judges. A hallucination should never cost you XP.

Offline-first evidence. Photos go into an IndexedDB buffer the instant you capture them — no spinner, no network. The buffer flushes on the online event, on app load, and on a manual tap. Rows are deleted only on a 200 or a 409. A 409 means the quest was already judged — the UI shows the existing verdict and clears the buffer, never an error dialog.

The Ollama client falls back gemma3:4b -> llama3.2 -> qwen2.5:7b. Change one env var (GRASS_MODEL) and the System gets a new brain.

Why Does Open Innovation Matter?

This project is made of open pieces, and each one earns it:

It runs where the data lives. Quest text and verdict narration happen on my laptop. Photos never leave the machine. A closed API would mean sending evidence photos to a third party, every day, forever.
It works with no signal. After the model is pulled once, the full loop works on a plane, on a train, behind a captive portal. Evidence is buffered in IndexedDB and flushed when you're back on the LAN.
It costs nothing per decision. No inference bill, no rate limit, no API key sitting in a .env file that can leak. Here it's electricity.
I could swap the model in one line. The fallback chain (gemma3:4b -> llama3.2 -> qwen2.5:7b) is one env var. Because everything behind the judge is an open interface, that decision was mine to measure, not a vendor's roadmap.

The honest tradeoff of open here is latency — Gemma narration takes ~10 seconds. For a game whose whole premise is leaving your screen, that's not a bug; it's a feature.

Honesty section

v1 does not understand pixels. The 4GB VRAM budget means the judge reads metadata (count, timestamp, file size), not image content. Owned honestly, not hand-waved. Planned next (not in this build): add a CNN verification tier that reuses a pretrained vision model — e.g. MobileNet/ResNet via torchvision, or a local vision model through Ollama — to catch wrong or irrelevant photos before they reach the narration layer. This submission ships without it; it's the next step. The deterministic rules stay authoritative; the CNN would be a gatekeeper, not a judge.
The roasts are a feature, not the marketed identity. The README and this post pitch the loop and the local-first story. The System's meanness is a discovery, not the headline.
No IP borrowed. Original lore and names. Not affiliated with any rights holder.

Try it

ollama pull gemma3:4b
pip install fastapi uvicorn pillow
uvicorn app.main:app --host 0.0.0.0 --port 8000

Open http://<laptop-ip>:8000 on your phone (same Wi-Fi).

Prize Categories

Entering Best Use of Gemma — SYSTEM://GRASS runs gemma3:4b locally through Ollama as the core model. Gemma is the only thing that speaks; it powers both the per-quest text and the verdict narration, entirely on-device.

Also automatically in the running for the overall Week 1 prize.

My Agent Session

The full build session — including the parts that went wrong (a 2-hour subagent wall-clock burn, a missing-table 500, and my own bad call that a saved DEV draft was a "phantom") — is saved as a DevRelay agent session:

SYSTEM://GRASS — building a local-first outdoor quest game

You

Build SYSTEM://GRASS — a local-first outdoor quest game — as my Hacktoberfest 2026 Week 1 entry. Local Ollama brain, phone as dumb terminal, offline-first photo evidence, a two-tier judge where Gemma narrates but never overrides rules.

Agent

Froze design docs (design.md, challenge-week1.md) and a 10-section build plan. Split into tasks 1-10 with exact contracts; each task = failing test first, then implementation, then commit. Ledgered all deferred minors. Tasks 1-8 approved (db, ollama_client, quests, judge, images, service, FastAPI). Approved deviation: FastAPI handlers use async def (Python 3.13). 61 tests green.

▸ task subagent implement Task 9 frontend (static/index.html, style.css, app.js + In...

Input

subagent implement Task 9 frontend (static/index.html, style.css, app.js + IndexedDB buffer)

Output

Subagent ran ~2h and was CANCELLED with code written but never committed. Lesson ledgered: cap browser/UI implementers at write+commit; live Playwright verification stays with the controller.

Recovered Task 9: controller committed 2e51620, reconstructed the task report, added bb40f78 static mount so frontend + API share origin (no CORS). Controller ran the Playwright drill.

You

What did we do so far?

Agent

Verified the offline buffer live: capture in airplane mode -> IndexedDB 'pending' store holds the blob -> back online -> flush on the 'online' event -> buffer cleared on 200. Verified the 409 path: second submit returns 409, buffered row is cleared, existing verdict is shown, and no error dialog appears. Only console noise is a favicon 404. Fixed /api/state 500 (OperationalError: no such table: quests) by calling db.init_db(). Committed 883bd2f to gitignore grass.db + evidence/.

▸ bash pytest -q

Input

$ pytest -q

Output

61 passed

Diagnosed the DEV draft confusion: I had wrongly called the draft a 'phantom' because public GET /api/articles/{id} 404s unpublished drafts. Author-scoped /api/articles/me/unpublished confirmed the draft (id 4831075) exists. Found DevRelay CLI bugs: 'articles create' silently truncated the body and dropped tags, and 'api' never forwards the request body. Pivoted to pasting the post manually.

You

ok draft saved

Agent

Restructured the post to the official Hacktoberfest Week 1 template (What I Built / Demo / Code / How I Built It / Why Does Open Innovation Matter? / My Agent Session / Prize Categories). Saved this agent session to DEV for the My Agent Session section.

Note: this is a curated slice of the session, not the full transcript. The complete conversation ran for hours and included every design decision, instruction, and course correction — too long to embed here. What's above captures the milestones, the parts that went wrong, and the recovery. The build itself lives in the repo.

Disclosure: Built by driving an AI coding agent. I set the architecture, froze the design, split the work into task contracts, reviewed every diff, and made all product decisions; the agent implemented large parts of the code under that direction. The AI's role was substantial and deliberate, not incidental.

devpulse: A Local-AI News Digest Built for One Person

Samar Nathani — Mon, 05 Oct 2026 00:17:33 +0000

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

What I Built

devpulse is a Discord bot built for my friend Soham.

His problem is simple, and you've probably felt it too: everything moves too fast now. Releases ship while you're looking the other way, the AI news cycle turns over before lunch, and Soham kept missing the things he actually wanted to see — new versions of the tools he uses, interesting projects before everyone else finds them. Keeping up had quietly become a part-time job nobody applied for.

So devpulse does the scanning for him. Every morning it pulls rising GitHub repositories, new releases from our shared watchlist, Hacker News, and dev.to, judges every single item with a model running on my laptop, and posts one clean message to our Discord:

TOP 5 FOR YOU — ranked by relevance and quality, with a two-line verdict on each
SLEEPER PICK — high quality, low attention: the thing worth finding before it's everywhere
NEW RELEASES — just the watchlist repos, linked straight to the release page

One message. No algorithm, no ads, no forty tabs. It lands at 7 AM, before either of us is fully awake, and the watchlist is just one config line — easy to repoint whenever Soham starts following something new.

I handed him the live bot in our Discord. His response, from the channel:

demnnn this looks pretty good , for a project made in a day this is pretty good , if you optimize it more then this can be fire and if you want to you can deploy it also so evryne will be able to use it but yeah personally ill be using this aand will wait for more updates from you

Demo

The whole thing in action - 2:40, no voiceover, just the sequence: refresh, offline cache, the crash with the terminal visible, recovery, /sleeper, then a friend's reaction in the channel before one last run:

https://youtu.be/MDPMhYyqOjs

It fails honestly too. When I stopped Ollama mid-day and ran /refresh, the bot didn't pretend things were fine — it posted a skip message, recorded the failed run, and picked the work back up automatically when the model returned.

The terminal tells the same story from the inside: every pending item logged judge failed for '<item>': [WinError 10061] No connection could be made because the target machine actively refused it, while Discord only ever saw the honest skip message.

Want to poke it yourself: join the server and try /sleeper, /releases, /dig fastapi, or /status.

Code

SammySN-car / devpulse

Discord bot: local qwen2.5:7b judges fresh tech news into a daily digest with sleeper picks. Built for Hacktoberfest 2026 Weekend Challenge.

devpulse

A Discord bot that gathers what is moving in tech - new releases, rising GitHub repos, Show HN posts, dev.to articles - and judges every item with an open-weight model (qwen2.5:7b) running locally through Ollama. Each day it posts one digest: the top 5 items for your stack, one sleeper pick (high quality, low hype scored by arithmetic, not vibes), and new releases from your watchlist.

Why open

Everything runs on-device: collectors call free public APIs, the judge runs on your own machine, and results live in a local SQLite file. No cloud inference, no subscription, nothing you fetch leaves the machine.

Setup

Install Python 3.11+ and Ollama; then ollama pull qwen2.5:7b
Create a Discord application, invite the bot, copy the token
python -m pip install -e ".[dev]"
Copy .env.example to .env and fill in token, channel id, owner id, watchlist
devpulse - the digest posts at DIGEST_TIME…

View on GitHub

Python 3.13 · discord.py · httpx · SQLite · pytest · ruff · GitHub Actions CI (Ubuntu + Windows). 61 tests, hermetic by default (no network, no model), plus one live marker test that does a real model round-trip when I ask for it.

How I Built It

The open-source AI at the core is qwen2.5:7b running locally through Ollama. No API key, no per-call bill, no request leaves the machine. The model reads each item and returns JSON: a relevance score, a quality score, and a two-line verdict ("what it actually is; worth clicking yes/no").

What the architecture looks like:

GitHub / HN / dev.to (free sources)
        │  collect
        ▼
  normalizer ── URL identity, dedupe, within-source engagement percentile
        │
        ▼
    SQLite ── items + judgments + digest ledger
        │  pending items only (never re-judges)
        ▼
  qwen2.5:7b via Ollama ── sequential, JSON mode, temperature 0.2
        │                    keep_alive: 0 → model evicted after each batch
        ▼
  composer ── TOP 5, sleeper pick, releases, 2000-char Discord limit
        │
        ▼
   Discord ── 5 slash commands + a 07:00 scheduler

Details I care about:

A RAM guard trips before anything can hurt the machine. If free memory drops below 1500 MB, judging stops cleanly, the reason is surfaced in the digest, and the run is recorded — leftovers are retried automatically the next day.
The sleeper pick is a formula, not an opinion: quality × (1 − engagement_percentile), with an eligibility gate (quality ≥ 7, engagement bottom 40%). A q8 repo at 14% engagement ranks below a q7 repo at 0% — high signal, no attention.
Judging failures never lie. One retry, then the item stays pending; if every judgment fails, the digest says so instead of pretending it's a quiet news day.
The model sleeps after every batch (keep_alive: 0) — a 4.7 GB resident model on a normal laptop is not a tradeoff I was willing to make 24/7.

Process, since judges asked to see it: I wrote the spec first, cut it into 13 tasks, and implemented each with tests written before code, followed by an independent spec review and quality review per task. The final whole-branch review caught a real production bug the test suite couldn't see: the SQLite connection was created on the main thread but digests run on a worker thread (asyncio.to_thread) — every scheduled run in production would have failed with SQLite objects created in a thread can only be used in that thread, while all 48 tests at the time stayed green. Fixed with a reentrant lock across every connection path, plus a cross-thread regression test. CI runs on Ubuntu and Windows, and a live round-trip test proved the real model answers and gets evicted afterward.

Why Does Open Innovation Matter?

This project is made of open pieces, and each one earns it:

It runs where the data lives. The digest is a reading habit — who and what someone follows is a profile. Here, fetches happen locally, judgments happen locally, and storage is a file on disk. A closed API would mean sending every title and description I care about to a third party, every morning, forever.
It runs with no internet. After the model is pulled once, judging works on a plane, on a train, behind a captive portal. The only thing that needs the network is the news collection itself.
It costs nothing per decision. 33 items judged in 4.5 minutes. On a closed API that's 33 calls, 33 bills, rate limits, and an API key sitting in a .env file that can leak. Here it's electricity.
I could swap the model in one line. I ran a spike comparing llama3.2 (3B) against qwen2.5:7b before committing: the small model echoed titles back as "verdicts" on 6 of 15 items; qwen produced real evaluations with a yes/no. Because everything behind the judge is an open interface, that decision was mine to measure, not a vendor's roadmap. The spike table is in the repo.
Where open beat closed outright: resilience. When the model was down mid-run, my bot degraded into an honest skip message and retried tomorrow. Try getting that failure semantics from a vendor status page.

The honest tradeoff of open here is speed — a 4.5-minute batch is not a streaming UI. For one digest a day, who cares.

Hacktoberfest 2026

Samar Nathani — Thu, 01 Oct 2026 12:24:04 +0000

Hey everyone!

Just signed up for Hacktoberfest this year. Figured I’d give it a shot and see what I come across.

Looking forward to finding some cool stuff to work on and having fun with it. :)