DEV Community: Encrypted

NoticeCatcher: Qwen3-8B Finds the Deadlines in a WhatsApp Group, and Plain Code Picks the Dates

Encrypted — Sun, 25 Oct 2026 09:33:01 +0000

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

What I Built

Every class has that WhatsApp group. 300 messages a day, memes, "ok sir", "who has the notes?" and somewhere in the middle, one message with the exam date. I mute the group to stay sane, and then I'm the one who misses the deadline.

NoticeCatcher is my lazy fix. You export the group chat as a .txt file, and it reads the whole thing for you. It pulls out only the notices that matter (exams, deadlines, workshops, cancellations) and writes a calendar file (.ics) you can open on your phone.

On the built-in fake chat from "Demo College" (40 messages), it found 4 events, noticed 1 cancellation, and set 1 vague notice aside for me to check instead of guessing a date.

Demo

There is no live demo link. The page runs on my own computer with python serve.py and only processes the built-in fake sample chat. The screenshots above are from a real run of the real model.

The main way to use it is the command line:

python cli.py samples/sample_android.txt

Real output from my run:

Events: 4, Cancelled: 1, Needs Check: 1
Event: Final Exam for CS301 | Start: 2026-10-28 10:00:00
Event: Submit Assignment 2 | Start: 2026-10-20 23:59:00
Event: Project demo | Start: 2026-10-15 14:00:00
Event: Workshop on Cloud Computing | Start: 2026-10-19 10:00:00
Cancelled: Guest lecture on Robotics
Needs Check: annual sports day | Reason: Unclear date: 'sometime next month'
Seconds taken: 68.52

Code

DkHrR / noticecatcher

NoticeCatcher

Extracts notices, deadlines, exam dates, and cancellations from WhatsApp group chat exports into standard iCalendar (.ics) files.

What It Does

NoticeCatcher parses exported WhatsApp group conversations (Android or iPhone format), identifies announcements with dates or deadlines, resolves dates deterministically, and writes valid .ics calendar events.

How It Works

NoticeCatcher uses a hybrid architecture: the model proposes, plain code decides.

Parser (parser.py): Reads raw text exports, handles Android (DD/MM/YYYY, h:mm am/pm - Sender: Text) and iPhone ([DD/MM/YY, h:mm:ss PM] Sender: Text) formats in 12h/24h time, preserves multi-line notices, and filters out system notifications and media lines.
Model Extraction (engine.py): Sends chunked messages to an open LLM (Qwen/Qwen3-8B) with strict instructions treating chat text as untrusted data. The model proposes candidates with exact date/time words copied verbatim from the text without attempting date math.
Deterministic Resolver (resolver.py)…

View on GitHub

MIT licensed. 32 tests pass.

How I Built It

The one rule I followed: the model proposes, plain code decides.

Parser (plain code). Reads both Android and iPhone export formats (DD/MM dates), joins multi-line messages, and skips system and media lines.
Model (Qwen3-8B through Tinker). Reads the messages in chunks of about 25 and returns JSON: a title, the date words copied exactly as written (like "next Monday"), and a time. It is told never to turn those words into a real date. The chat text goes into the prompt marked as data, not as instructions.
Resolver (plain code). This is where dates are decided. "Tomorrow" counts from the date of the message it was written in, not from today. It also checks that the source message really exists. Anything it can't pin down goes to "Needs your check" and is never guessed.
.ics writer (plain code). Writes the calendar file in the Asia/Kolkata timezone. Cancelled notices never become events.

Why split it like this? A language model is bad at "what date is next Monday?" but good at "is this message an announcement?" So the model only does the second job, and ordinary code does the first.

I checked two dates by hand against the sample chat:

"Project demo tomorrow" was written on 14 Oct 2026, and it resolved to 15 Oct.
"Workshop is next Monday" was written the same day (a Wednesday), and it resolved to 19 Oct.

What went wrong: my first prompt told the model to skip vague dates. The result was "Needs Check: 0", which meant the review list could never show anything. I changed the prompt so the model includes vague notices with their original words, and the resolver now refuses to guess them. The annual sports day ("sometime next month") now lands in the check list, which is where it belongs.

Timing: the command-line run took 68.52 s for 40 messages, including model startup. Through the local web page it took 40.43 s. These are single runs, not benchmarks.

What I did not do:

Calendar events get a default length of 1 hour, so "Submit Assignment 2" ends at 00:59 the next day.
I only tested on fake chats, never on a real group in this post.
I did not test whether a chat message containing instructions can trick the model.
I did not host it. The page is local only.

Why Does Open Innovation Matter?

A class group chat is private: names, plans, half-finished conversations. So it matters to me which model reads it.

With an open-weight model, the model is one line in a settings file (MODEL in .env). I can swap it for another one without rewriting anything, and I could point the same code at a smaller model running on my own machine. Qwen3-8B is the one I used here.

Here is the honest limit: in this version, the chat text is sent to the Tinker API, so it does not stay on my device. My laptop has 4 GB of RAM, so I did not run a local model, and I did not compare against a closed model. What open models gave me in this project is the freedom to switch and to see how the pieces work together, not a privacy guarantee.

My Agent Session

I did not save a DevRelay session for this project. Claude planned the project and drafted the prompts, Antigravity (Gemini) wrote the code, and I ran everything step by step and checked the output myself.

The Lazy Payoff

I haven't had a classmate use it yet, so I won't pretend it saved anyone hours. What I can say honestly: on a 40-message chat it finishes in about a minute, and it did not guess a single date. The one notice it couldn't date came back to me as a question, and that is the kind of laziness I trust.

RuleFit: an open model rewrites messy product titles, and plain code decides if they pass

Encrypted — Sun, 18 Oct 2026 13:29:34 +0000

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

What I Built

RuleFit cleans up messy product titles so they follow a store platform's rules. You upload a CSV, pick the title column, and download a CSV with a rewritten title, a status (PASS, FIXED or FLAGGED) and the reasons for any failure.

The first rule pack is Google Shopping titles. Google's title docs set a 150 character limit and say products can be disapproved for things like promotional text or all-caps titles. A store with hundreds of messy titles would otherwise fix them by hand.

The open model rewrites each title. Then plain Python checks the rewrite: max 150 characters, one line, no promotional phrases, no ALL-CAPS words unless they were in the original, not mostly capitals, no emoji, symbols or HTML, and no new numbers or sizes. A failing row gets one retry with the exact reasons. If it still fails, it is flagged and your original is kept. The model never decides what passes. The code does.

Who would pay? I think small store owners, or freelancers who clean product feeds for them. That is a guess. I have not found a paying customer, and I did not check whether people already sell this on freelance sites. Bigger feed tools like Feedonomics exist, and I did not compare prices.

Demo

There is no live link. I tried Render's free tier and the service kept restarting (details below). This screenshots is from RuleFit running on my laptop with the real model. The header shows Engine: Tinker / Qwen/Qwen3-8B.

Real output:

NIKE AIR ZOOM PEGASUS 40 RUNNING SHOES MENS SIZE 10 FREE SHIPPING!!! became Nike Air Zoom Pegasus 40 Running Shoes Men's Size 10 (PASS)
Cotton Bath Towels 6 Pack Soft Absorbent Quick Dry 50% off Today Only became Cotton Bath Towels 6 Pack Soft Absorbent Quick Dry (PASS)
Blue Denim Shirt Size M Slim Fit Long Sleeve stayed the same (PASS)

All three passed on the first try, so the retry and FLAGGED paths did not run in this test.

Code

DkHrR / rulefit

RuleFit

RuleFit rewrites e-commerce product titles to adhere to catalog rules using a dual-engine architecture: an open language model hosted by Tinker generates candidate rewrites, and deterministic Python validators enforce the rules.

How It Works

Model Draft: The model drafts an initial rewrite of each title.
Deterministic Check: Plain code checks the draft against catalog rules.
One Retry Loop: If any rule check fails, the model is invoked once more with the specific failure reasons.
Safety Fallback: Rows that still fail after retry are marked as FLAGGED, and your original title is kept.

Rules (`packs/google_shopping_titles.json`)

max_chars: Maximum 150 characters.
not_empty_single_line: Title must be a single non-empty line.
banned_phrases: No promotional phrases ("free shipping", "sale", "best price", "buy now", "limited time", "discount", "cheap", "% off", "today only", "limited offer", "clearance", "hot deal").
no_caps_words: No ALL-CAPS words (4+ letters) unless already present in the original…

View on GitHub

MIT licensed, with 67 automated tests. The tests use a stub in place of the model, so they never call it.

How I Built It

Model: Qwen/Qwen3-8B through Tinker's sampling client (inference only). Thinking is turned off with the qwen3_disable_thinking renderer.
Rule packs: each platform is one JSON file, so a new niche means a new file.
App: Flask. Each upload runs as a background job that the page polls. Results live in memory and expire after 15 minutes.
Design: Google Stitch. Code: Antigravity (Gemini).
AI disclosure: Claude helped me plan the project, wrote the prompts I gave Antigravity, and drafted this post. Antigravity wrote the code. I ran the app, checked its outputs and reports, and fixed what they showed.

What went wrong

Antigravity first passed enable_thinking=False to SamplingParams. The SDK shows only one generic data field there, and Tinker picks thinking through the renderer. I found it by inspecting the SDK before trusting the report.
Two threads importing tinker at once caused a circular-import crash. Top-level imports fixed it.
My rules had a loophole: an unchanged ALL-CAPS title would pass, because caps words were allowed if they appeared in the original. I added a "mostly caps" rule.
Stitch invented a "zero data retention guarantee" badge, an account icon and other fake features. I removed them and added tests that fail if those words come back.
Twice, Antigravity gave me two different versions of the same test run in one report. After that I only trusted output I could check.
My first API key never saved because I closed the editor without pressing Ctrl+S.
On Render's free tier (512 MB) the service restarted about every two minutes, starting shortly after the model warm-up. I suspect memory, but I did not confirm it in Render's metrics, so I can't say that is the cause.

What I did not do

I have no paying customer and no first user.
I did not compare against a closed model.
The rules check form, not meaning. In a test with a fake mock engine, a title cut off mid-word still passed.
I only tested English product titles.
RuleFit does not certify anything for Google. The page says "passes RuleFit checks" and nothing stronger.

Why Does Open Innovation Matter?

Because the rules live in code, I don't need the smartest model. I need a cheap one I can call twice on a bad row. An open 8B model fits that. The model name is a single setting, though a different model family would also need its own renderer, so swapping is not completely free. Later I could fine-tune on rows that failed the rules, but I have not done that.

I did not benchmark a closed API, so I can't say it would do worse. One honest limit: rows go to Tinker, so nothing stays on the user's machine. Open weights would let a store run the same model locally, but I have not built or tested that.

My Agent Session

I did not save a DevRelay session. Antigravity (Gemini) wrote the code from prompts I wrote with Claude's help, and I checked each of its reports against raw test output before moving on.

My First User

I don't have a first user. Nobody but me has run RuleFit, and nobody has paid for it.

Prize Categories

Tinker, for the inference behind Qwen/Qwen3-8B.

I built an AI that invents a playground game, then locks my phone so I'd go play it

Encrypted — Sun, 11 Oct 2026 16:45:25 +0000

What I Built

Most "touch grass" apps want you to look at them. I wanted one that wants you to stop.

Playground Game Maker takes a few facts (how many players, their ages, the stuff you have, the space, the minutes) and an open-weight model invents a game for exactly that mix. You tap Start playing, the screen locks behind a countdown, and the phone goes in your pocket.

Demo

Live: https://playground-game-maker.onrender.com/

It is a public demo on Render's free tier, running the real model (Qwen/Qwen3-8B through Tinker). The free tier sleeps when idle, so the first load can be slow, and the first game after waking can take up to 90 seconds. To protect my credits it allows 5 games per visitor per hour and 100 per day, and it does not save stats online (the stats page and CSV only work in the local version). The screenshots below are from my own computer.

The form: who is playing, what you have, how much space and time. The gear box takes free text.

A real game from Qwen3-8B ("Tennis Toss Tag"). It used only the chalk, cones and tennis balls I listed.

The phone locks behind a countdown. Elapsed and remaining always add up to the total.

Code

GitHub: https://github.com/DkHrR/playground-game-maker (MIT)

To run it locally: python app.py, then put your own model key in .env.

How I Built It

Flask backend and one HTML page. No accounts, no names, no location, no tracking. In the local version everything is saved in a SQLite file on my computer. Game prompts go to Tinker, so nothing here is "offline".
The model returns JSON: name, setup, up to 6 rules, how to win, a safety note.
The lock screen runs on the real clock, so a sleeping screen does not break the countdown.
The app counts screen seconds next to minutes outside. Outside minutes are self-reported by the player.
Code written with Antigravity. The interface was designed in Google Stitch (not open source). The games come from Qwen3-8B, served through Tinker's sampling client (inference only, no fine-tuning).
Hosting: Flask with gunicorn on Render's free tier. The model call goes out to Tinker. Keys live only in Render's environment settings, never in the repo. On my laptop the app used about 350 MB after warm-up and one game (peak 362 MB), which fits Render's 512 MB free tier.

Why an Open Model Mattered

A fixed list of games cannot cover "4 kids, two tennis balls, a small yard, 30 minutes". A model can. An open-weight 8B model also means no per-game price and no closed model deciding what is safe for kids. It also let me see exactly where a small model is weak, which led to the most useful part of the project: the safety rules live in code, not in the prompt.

What Went Wrong

The model invents items. In my first 3-game check it added things I never listed: a plastic knife, a bucket, a finish line, foam. Telling it "use only the listed items" in the prompt did not fix it.
Prompt rules are not safety. So the code removes unsafe items from what the player types before the model sees them (knife, scissors, matches, glass, rope and similar). The game card says "Removed unsafe item". The code also scans the model's reply and retries once, and it always adds "Tell a parent or adult where you are playing", because the model only sometimes remembered.
It is not 100% reliable. In my real-model check scripts, between 70% and 80% of generations passed (7 of 9, 7 of 10 and 8 of 10 in three runs). Some failed and I do not know why. Once warm, most games took 5 to 17 seconds. The first game after starting the server took 30 to 90 seconds, and a few took close to a minute.
Empty replies. Some calls ended with "No JSON object found". The most likely cause: Qwen3-8B "thinks" before it answers, and my 1,000-token limit could run out before the JSON started. I raised the limit to 2,500. I did not re-run my full check afterwards, so I cannot say it fixed every case.
The games are playable, not great. One game's rules were three half-ideas that did not fit together: run to the center, pass the ball, bounce it over cones.
A bug in the design code. The lock-screen countdown flipped between two numbers. I recorded my screen and found a hardcoded sample timer from the Stitch design running next to the real one. Deleting it fixed it.
Another leftover. After tapping an age chip, the age box showed the icon name ("All agescheck_cir..."). My screenshots use the default age.
A fake test result. My last scripted 20-call test hung, and Antigravity then ran it against my mock engine: 20 of 20 "passes" in 0.00 seconds. I threw those results away because they came from a fake model.
Free credits. Backboard's free credit could not pay for chat models, so I moved to Tinker.

The code removed the unsafe items I typed (jump rope, knife, air gun) before the model saw them, and it added the parent reminder. The rules and note still mention a chalkboard and foam balls.

What I Did Not Do

I did not field-test this outside with other people, so I have no play data, ratings, or "minutes outside" to report. The checks above are lab tests on my own laptop.

Prize Categories

Tinker: the games are generated by Qwen3-8B on Tinker, inference only.
Render: the demo runs as a Render free-tier web service. render.yaml is in the repo.

AI Disclosure

Code built with Antigravity, interface designed with Google Stitch, games generated by Qwen3-8B, and this post drafted with Claude and edited by me.

OneInbox: a fine-tuned 4B model that reads my inbox so I don't have to

Encrypted — Sun, 04 Oct 2026 14:58:29 +0000

What I Built

OneInbox is a daily email digest that sorts my inbox into four buckets:

Action required: needs a reply, or has a deadline within 7 days
Worth a look: useful, but nothing to do
FYI: receipts, confirmations, security notices
Noise: promos, newsletters, social

The idea came from a complaint in a hackathon Discord about how tiring it is to keep checking inboxes. I have the same problem, so I built it for my own inbox.

The core is a LoRA fine-tune of Qwen3.5-4B (Apache 2.0). Each morning it reads the last 24 hours of mail and produces a page I can read on my phone in under a minute. Every item has buttons to mark it Accurate or Wrong, silence the sender, or always show it.

Demo

Live: https://oneinbox-web.onrender.com/digest?token=hacktober2026

It runs in demo mode on 25 synthetic emails, classified by the fine-tuned model. The first load can take about 30 seconds, because Render's free tier sleeps when idle. Due dates are in September because the sample emails are synthetic, and timestamps are UTC.

Code

GitHub: https://github.com/DkHrR/oneinbox (MIT)
Model: https://huggingface.co/dKhRr/oneinbox-qwen3.5-4b-lora

How I Built It

Data. I didn't want to put a real inbox into a hackathon project, so I generated 600 synthetic emails (150 per label) with Qwen3.6-35B-A3B on Tinker. Sender names match the type of mail, deadlines are computed from each email's received date, and a second pass checks every email. I audited the set: no deadline mismatches, and very few subjects shouting "URGENT". I split it into 540 train and 60 validation emails.

Training. A Tinker LoRA fine-tune of Qwen3.5-4B on the full JSON answer (label, summary, deadline). Training cost about $0.19 to $0.31.

Results on the 60 held-out synthetic emails:

Variant	Labels correct	Macro-F1	Deadline match	Cost / 1k emails
Base 4B, zero-shot	52/60	0.86	23/28	$0.157
Base 4B, 3-shot	56/60	0.93	25/28	$0.278
Fine-tuned 4B	58/60	0.97	25/28	$0.141
Base 35B-A3B, zero-shot	51/60	0.85	25/28	$0.229

What this shows, and what it doesn't:

The fine-tune beats 3-shot prompting by two emails. That is a small gain, not a landslide. The bigger point is that it needs no prompt examples, so it costs about half as much per 1,000 emails.
It is not faster: p50 latency is about 2.85s, against 2.55s for 3-shot.
Deadline accuracy is tied with 3-shot.
The test set is synthetic, and its gold labels came from the generator, not from a human. I reviewed the fine-tuned model's mistakes: some were real misses (an off-by-one bank deadline, a missed hospital deadline) and some were debatable labels. Treat these numbers as a sanity check, not a real-world accuracy claim.
Pricing uses Tinker's published base-model rates, because I found no separate rate for fine-tuned sampling.

Memory (Backboard). Sender preferences like "always show" and "silence" are stored as Backboard memories and applied by simple code rules each run. I use Backboard only for memory. Accurate/Wrong feedback is logged there but does not change filtering yet. It is saved for future retraining.

Hosting (Render + GitHub Actions). The digest page is a small Flask service on Render's free tier. The daily run is a GitHub Actions workflow at 07:00 IST, and it posts the finished digest to the service. Render cron needs a paid plan, so I moved the schedule to GitHub Actions to keep the project at $0 to run. The web service keeps nothing on disk, so the digest is saved in Backboard memory and survives restarts.

What I'd Fix Next

No outside person has tried OneInbox yet, so I had an AI reviewer play a first-time user and tell me what felt wrong. This is not user feedback, but its points matched gaps I could already see:

No way to open the original email. The digest tells you what needs action, but you still have to go find the email yourself. In IMAP mode I can link each item to a mail search for that sender and subject. The demo can't, because its emails are synthetic.
Accurate / Wrong buttons don't change anything yet. They only log feedback, as noted above. Next step is to use that log to adjust sender rules, or to feed it into a retraining run. Until then they are a data-collection tool, not a control.
Sender names can hide the real address. The full address is only in a tooltip, which doesn't work on a phone. Showing the domain in small text under the name matters for security alerts, where spoofed senders are the whole risk.
Trusting an AI with deadlines. A wrong date on a bill is worse than no digest. The fine-tuned model matched 25/28 deadlines in my test, not 28/28, so I want the original email one tap away, which brings back the first point.

Why Open Innovation Matters

An inbox is some of the most private text a person has, so I didn't want a closed model deciding what matters in it. With an open-weight 4B model:

The weights, my LoRA adapter, and the code are public, and the base model is Apache 2.0. Anyone can inspect, fork, or retrain them.
A small model is cheap enough to run daily without a subscription.
My feedback buttons are designed to feed a future fine-tune on someone's own corrections.

Prize Categories

Tinker: generated the dataset, fine-tuned, and evaluated everything on Tinker.
Render: the digest page runs as a Render free-tier web service. render.yaml is in the repo.
Backboard: sender preferences, feedback logs, and digest persistence use Backboard memory.

DEV Community: Encrypted

NoticeCatcher: Qwen3-8B Finds the Deadlines in a WhatsApp Group, and Plain Code Picks the Dates

What I Built

Demo

Code

DkHrR / noticecatcher

NoticeCatcher

What It Does

How It Works

How I Built It

Why Does Open Innovation Matter?

My Agent Session

The Lazy Payoff

RuleFit: an open model rewrites messy product titles, and plain code decides if they pass

What I Built

Demo

Code

DkHrR / rulefit

RuleFit

How It Works

Rules (packs/google_shopping_titles.json)

How I Built It

Why Does Open Innovation Matter?

My Agent Session

My First User

Prize Categories

I built an AI that invents a playground game, then locks my phone so I'd go play it

What I Built

Demo

Code

How I Built It

Why an Open Model Mattered

What Went Wrong

What I Did Not Do

Prize Categories

AI Disclosure

OneInbox: a fine-tuned 4B model that reads my inbox so I don't have to

What I Built

Demo

Code

How I Built It

What I'd Fix Next

Why Open Innovation Matters

Prize Categories

Rules (`packs/google_shopping_titles.json`)