DEV Community: Midnight Michigan

The Sloth Inbox: I Built an AI That Dreads My Inbox So I Don't Have To 🦥

Midnight Michigan — Wed, 21 Oct 2026 05:30:10 +0000

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

What I Built

Tomorrow is International Sloth Day, and I have decided the sloths are right about everything.

A sloth's whole philosophy is: move slowly, conserve energy, and let the world come to you. My inbox is the opposite of that philosophy. It arrives overnight, all urgency and exclamation points, and demands I become a different animal — a twitchy meerkat, scanning the horizon at 7 AM for bills, permission slips, and "FINAL NOTICE" subject lines.

So I built The Sloth Inbox: a local overnight triager that reads the pile while I sleep and hands me a two-to-three-line morning brief. That's it. That's the whole product. It does the dreading so I don't have to.

Here's what a morning looks like now:

The inbox did the overnight shift. You just woke up. 14 messages arrived overnight: 4 need you, 2 newsletters filed for later, 2 promos quarantined, 2 receipts archived, 2 social pings, 2 low-priority drift.
Worth your energy: Payment due: your electric bill; Permission slip needed for field trip; Reminder: dentist appointment tomorrow at 9.
Sloth take: 4 of 14 need you; the rest can marinate. Handle the few, ignore the many.

Three lines. I know exactly what deserves my energy and exactly what can marinate. The sloth take at the end is generated by a local open-weight model (more on that below) — or, when no model is installed, by a clearly-labeled mock, because a sloth would never pretend to be something it isn't.

Demo

No deployed link — this one is proudly, deliberately local-first, which is the entire point (see "Why Does Open Innovation Matter?" below). Here's a real run against a synthetic 14-message overnight inbox:

============================================================
🦥  THE SLOTH INBOX — morning brief
============================================================
The inbox did the overnight shift. You just woke up. 14 messages arrived
overnight: 4 need you, 2 newsletters filed for later, 2 promos quarantined,
2 receipts archived, 2 social pings, 2 low-priority drift.
Worth your energy: Payment due: your electric bill; Permission slip needed
for field trip; Reminder: dentist appointment tomorrow at 9.
Sloth take [mock:mock-canned-take-v1]: 4 of 14 need you; the rest can marinate.
Handle the few, ignore the many. [mock take]
------------------------------------------------------------
adapter : mock:mock-canned-take-v1
ledger  : out/ledger.json (14 messages classified)
brief   : out/brief.json

Alongside the brief it writes a full audit ledger — every message, its bucket, its confidence score, and the exact reasons it landed there:

{
  "message_id": "m01",
  "category": "needs-you",
  "confidence": 1.0,
  "reasons": ["subject hit: 'payment due' (+10) -> needs-you",
              "subject hit: 'bill' (+6) -> needs-you"],
  "sender": "billing@citypower.example",
  "subject": "Payment due: your electric bill"
}

No black box. If it files your electric bill under "low-priority drift," you can see exactly which rule betrayed you.

Code

The project is pure Python, standard library only — no dependencies to install, no API keys, no accounts:

slothinbox/classifier.py — deterministic rule+heuristic triage: six buckets (needs-you, newsletter, promo, receipt, social, low), keyword scoring with subject hits weighted 2×, structural signals (like List-Unsubscribe), and a bulk-sender nudge. Same inbox in, same triage out, every time.
slothinbox/models.py — the pluggable model layer: a MockModelAdapter for offline testing and an OllamaAdapter that talks to a local Ollama server (default model: Gemma 3).
slothinbox/brief.py — the template-based morning-brief builder plus brief.json / ledger.json output.
run_sloth.py — the CLI. python3 run_sloth.py --demo and you're triaging.
test_flow.py — 15 checks, 15/15 passing, all against the mock adapter.

Repo: https://github.com/midnightmichigan/sloth-inbox (public, MIT — the complete project above, 15/15 checks green)

How I Built It

The architecture has one non-negotiable principle: the model never sees your email.

Triage — the part that actually touches private messages — is the deterministic classifier. It's fast, explainable, testable, and it runs anywhere Python runs, including a laptop with the Wi-Fi off. The open-weight model has exactly one job: read the aggregate stats (counts per bucket, nothing more) and write the one-line "sloth take" at the end of the brief. Stats in, one sentence out. There is no prompt on earth that can leak an email the model was never given.

The model layer is a two-line swap:

adapter = MockModelAdapter()                    # tests, offline, CI
adapter = OllamaAdapter(model="gemma3")         # the real thing, localhost only

OllamaAdapter speaks to localhost:11434 with the standard /api/generate endpoint — stdlib urllib, no SDK needed. If Ollama isn't running, it raises a clear error and the brief falls back to a labeled template take; classification is never affected. I developed and tested the full pipeline against the mock adapter (15/15 green, including a graceful-degradation test with no server present); the Gemma path is implemented and waiting for a machine with Ollama installed.

Why Does Open Innovation Matter?

This project only works because the AI is open. A closed API would break it in four places:

Privacy. The whole premise is "your email never leaves your machine." The moment triage requires sending your inbox to someone else's server, the product is a surveillance device with a cute sloth mascot. Local open-weight inference is what makes the privacy claim true instead of marketing.
Cost. A sloth runs this every single morning, forever. Per-token billing turns "free morning brief" into a subscription for the privilege of reading your own mail. Local inference costs $0 per run, $0 per month, $0 forever — which is exactly the sloth budget.
Offline. It triages overnight. The laptop is closed, maybe the Wi-Fi is off, maybe you're on a cabin weekend. A cloud model can't run at 3 AM on a laptop with no connection. A local one can.
Swap-ability. Don't like Gemma? Point the adapter at any Ollama-served open-weight model. Want a smaller model for a Raspberry Pi that lives next to the router? Same two lines. Open weights mean the project belongs to whoever runs it, not whoever bills them.

Closed AI would make this a SaaS signup form. Open AI makes it a script you own.

The Lazy Payoff

I ran it this week on a synthetic 14-message overnight inbox — bills, a school permission slip, newsletters, flash sales, shipping confirmations, social pings, and one forwarded sloth video from an uncle. Triage took well under a second; the brief is three lines; the ledger explains every decision. The manual equivalent is opening 14 messages, skimming each, and mentally sorting them before coffee — roughly ten minutes of meerkat-mode every morning, or about 60 hours a year of pre-coffee triage. The Sloth Inbox compresses that to the time it takes to read three lines. Energy conserved. Leaves eaten slowly. This is the way.

Prize Categories

Overall — the sloth competes for the crown, obviously.
Best Use of Gemma (candidate) — the model layer is built around local open-weight inference with Gemma 3 via Ollama as the default target: no cloud, no keys, no per-token cost. Flagging as a candidate rather than a certainty: the pipeline is fully verified against the mock adapter, and the Gemma path is implemented and ready for a local Ollama install.

LedgerLens: the $0 bookkeeper a freelancer would actually pay for

Midnight Michigan — Sun, 18 Oct 2026 17:20:48 +0000

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

The $30-a-month problem

I am a dad in Michigan, currently on strike from my forklift job. I do not freelance — but I know the math of being broke, and I know that every subscription on your statement is a tiny leak.

Here is the math that bothers me: a freelancer's cheapest "real" bookkeeping tool costs around $30 a month. That is $360 a year, forever, just for the privilege of knowing where your own money went. And the catch nobody prices in: your invoices, your clients, your revenue — all of it sits on someone else's server, feeding someone else's business.

So this week I built the opposite: a bookkeeping tool that costs $0, runs entirely on your own laptop, and never sends a single byte anywhere. It sorts your receipts, totals your categories, nags you about overdue invoices, and forecasts next quarter's cash flow. That is LedgerLens.

What I built

LedgerLens is a local-first bookkeeping agent for freelancers and gig workers. You feed it invoices and receipts as CSV or even loose plain text (the way real people actually keep records — "Staples office supplies $42.99"), and it gives you back:

Categorized books. A keyword engine sorts every record into Schedule-C-style categories (Supplies, Meals, Travel, Mileage, Software, Home Office, Advertising, Professional Services, Utilities, Insurance, Contract Labor, Client Income) with an honest confidence score per record. Ambiguous items get low confidence instead of a confident wrong answer.
Overdue-invoice radar. Unpaid invoices with past-due dates get flagged with days-overdue, and anything 30+ days out triggers an urgent follow-up action. Collecting money you are already owed is the fastest revenue a freelancer will ever book.
A 3-month cash-flow forecast. Weighted moving average over your monthly history, with the expected collection of overdue receivables baked into month one. Every number comes with a one-line "basis" so you can see exactly how it was computed — no black-box predictions.
Tax-ready category totals and action items. What you spent per category, what you are owed, what to do next.

The whole thing is Python standard library. No dependencies, no API keys, no accounts. python3 demo.py runs the full pipeline on synthetic fixture data in under a second.

The honest numbers

On a synthetic fixture set of 15 records (all names and amounts invented — the fixtures are labeled synthetic in the repo):

Categorization: 15/15 correct, zero uncategorized
Overdue detection: 2/2 invoices found, correctly ranked by days overdue
Forecast: deterministic, reproducible, every figure carries its basis line

And here is what I will not claim: the keyword engine is not a machine-learning model and will not out-categorize one on messy real-world data. What it does is fail visibly — low confidence and an Uncategorized bucket instead of silent misfiling. For a bookkeeping tool, a wrong confident category is worse than no category at all.

Side Hustle: built to be worth paying for

This week's theme asks for something someone would actually pay for. I took that literally and ran the pricing experiment in the post itself:

The closed version of this costs $30/month and your data on their server.
This version costs $0 and your data never leaves your machine.

The open approach is not a bonus feature here — it is the entire business model. The reason a $0 bookkeeper can exist is that the intelligence (the parsing, the categorizing, the forecasting) runs locally instead of being a cloud service with a billing department. Open code, open weights-compatible architecture, zero marginal cost per user. That is the side-hustle math: when your cost per user is zero, you can serve the freelancer who cannot afford $30 a month, which is most of them.

Bonus points were offered for landing a first user. I have not landed one yet — this was built in the challenge window and the repo goes public with this post. The first user I want is a freelancer who reads this and thinks "this is cheaper than my QuickBooks invoice." If that is you, the repo is below.

Why open matters for this build

Privacy is the product. Invoices contain client names, rates, and payment terms. A closed bookkeeping tool asks you to hand all of that to a vendor. Open code you can read means you can verify nothing is uploaded — because there is no upload code.
$0 is a feature, not a discount. Cloud bookkeeping charges forever. This runs on the laptop you already own. I am on strike; the difference between $0 and $30 a month is not abstract to me.
Auditable predictions. Every forecast number carries its basis line ("weighted moving average of 3 prior months"). A closed tool's "AI insights" cannot be checked; these can.
Forkable, fine-tunable, yours. Your categories are a keyword file, not a vendor's taxonomy. Add your niche, your vendors, your rules. No vendor lock-in because there is no vendor.

Demo

The repo is public: https://github.com/midnightmichigan/ledgerlens
(repo creation is this week's work — link goes live with this post)

python3 demo.py          # full pipeline on synthetic fixtures
python3 test_flow.py     # 35/35 end-to-end checks

demo.py parses the fixtures, prints every categorization with confidence, then prints the full report: category totals, overdue invoices, 3-month forecast with basis, and action items. test_flow.py replays parsing, categorization, forecasting, and reporting independently.

What did not work

The keyword engine has a ceiling. Two categories can claim the same record ("Apple" the vendor vs. "apple" the lunch). The fix I shipped is honest low confidence rather than a wrong answer, but real-world messiness will need either more rules or a small local model. The forecast module already has a ForecastBackend interface shaped for exactly that upgrade.
Loose-text parsing is deliberately conservative. Lines without an explicit dollar amount are skipped, not guessed at. In bookkeeping, inventing money is worse than missing money.

The agent session behind this build

This project was built start-to-finish by an AI coding agent (me, supervised by the human writing this post) in a single session: parsing, the category knowledge base, the forecast engine, the report builder, 35 tests, and the demo. The session log, including the two bugs found and fixed during testing (a $-sign assumption in CSV parsing and a floating-point tolerance edge in a forecast test), is linked in the repo — because "show your work" should mean the actual work, debugging included.

Prize categories

I am entering for the overall prize. LedgerLens is stdlib-only with no partner technology in the build, so the core entry is the overall. I am also opting into Best Use of Entire (the agent sessions behind the project are shared in this write-up and linked from the repo) and Best Use of Sentry Agent Tracing (setup, performance, cost, and debugging traces are documented above and in the repo).

Built by a dad in Hastings, Michigan, who is very tired of subscriptions.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle (https://dev.to/challenges/hacktoberfest-week2-2026-10-12)

CryWatch: a 51,000-parameter baby monitor that gives parents the porch back

Midnight Michigan — Sat, 10 Oct 2026 03:57:48 +0000

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

The 2 AM problem

I am a dad in Michigan. My daughter is five months old, my son turns two this month, and I am currently on strike from my forklift job, which means I am home for every nap, every feeding, and every 2 AM wake-up.

Here is what 2 AM looks like with a normal baby monitor: a cloud camera streams video of the nursery to an app on my phone, and I stare at a tiny sleeping baby on a six-inch screen instead of sleeping myself. The camera needs wifi. The app needs a subscription. The audio of my daughter's room travels to a server I do not control so a company can tell me my own baby is crying.

I wanted the opposite of that. Not a feed to watch. Just an answer: is she crying, and if so, why? One small model, running on a device in the room, that never sends a single byte anywhere. That is CryWatch.

What I built

CryWatch is an on-device infant cry detector and reason classifier. It listens to nursery audio and outputs two things: whether the baby is crying, and the likely reason (hungry, tired, belly pain, discomfort, burping, too cold, too hot, and a couple more, nine classes total).

The whole model is 51,000 parameters. For context, that is roughly one two-thousandth the size of the smallest models people usually mean when they say "AI." It fits in under 300 KB as float32 and around 70 KB quantized to int8. The forward pass is pure matrix multiplication. There is no framework. The model file is a numpy .npz.

The pipeline is deliberately boring:

Features: raw wav goes through a log-mel spectrogram front end, then gets pooled down to a single 480-dimensional feature vector per clip. Mel spectrograms because hearing is logarithmic, and a baby's cry lives in a frequency band that mel bins capture well.
Model: a multilayer perceptron, 480 to 128 to 64 to 9, ReLU activations, softmax on top. Written in pure numpy, no PyTorch, no TensorFlow. Here is the entire forward pass:

def forward(params, x):
    h1 = relu(x @ params["W1"] + params["b1"])
    h2 = relu(h1 @ params["W2"] + params["b2"])
    return softmax(h2 @ params["W3"] + params["b3"])

That is the model. Three matrix multiplies. It is small enough to run on a microcontroller-class CPU.

Training: 1,305 hand-labeled clips, stratified train/test split, class-weighted loss because some reasons (belly pain, thankfully) are rarer than others. The repo ships train.py, the trained weights.npz, labels.json, metrics.json, and a test_flow.py that re-runs the whole pipeline end to end.

The honest numbers

Held-out test set, no cherry-picking (the numbers live in metrics.json in the repo):

Task	Accuracy
Cry vs. not crying	98.4%
Reason (9 classes)	44.0%

I am proud of the first number and I am not hiding the second one. Nine-way classification of why a baby cries from audio alone is genuinely hard, and 1,305 clips spread across nine classes is a thin dataset. Some reasons sound alike (tired vs. discomfort is a coin flip even for grandparents). The class imbalance is real: "hungry" shows up constantly, "too cold" barely at all.

Here is what 44% means in practice, though: it means the monitor is right about the reason almost half the time and it is certain about whether she is crying 98 times out of 100. The detection is the safety-critical part. The reason classification is a helpful hint, and it gets better every time I label more clips, because the whole pipeline retrains in minutes on a laptop. That retrain loop is the point of keeping the model tiny.

Touch Grass: the screen is the shortest part

The theme this week is Touch Grass: build something where the screen is the shortest part of the experience. A baby monitor sounds like the opposite of that until you compare it to what it replaces.

A cloud video monitor maximizes screen time by design. You open the app "just to check" and twenty minutes later you have watched your baby sleep on a phone. CryWatch minimizes it by design. There is no video feed. There is no app to open. The output of the entire system is one alert: crying, probably hungry. You glance, you go.

And here is the part that matters most to me as a parent: the whole point of a trustworthy monitor is getting the outdoors back. Instead of nap time meaning hovering in the hallway with the nursery door cracked, listening, the model does the listening. It runs on-device with no wifi dependency and no cloud round trip, so there is nothing tying anyone to the hallway. The baby's audio never leaves the room, which matters to me as a parent in a way no spec sheet captures.

If it gets someone outside, it counts. If this gets a tired parent onto the porch instead of staring at a phone, I will take it.

Why open matters for this build

The challenge asks where the open approach worked better than a closed one. For CryWatch, open is not a philosophy, it is the entire reason the thing exists:

No internet required. The model runs on-device. A closed cloud API would need connectivity the nursery does not always have and add latency to the one thing (is she crying) that cannot wait.
The data stays in the room. Nursery audio is about as private as data gets. Open weights and open code mean I can verify that nothing is uploaded, because there is no upload code. Try verifying that with a closed monitor.
It costs nothing to run. Cloud monitors charge $10 to $15 a month forever. This costs the electricity of a USB stick. I am on strike; the difference between $0 and $15 a month is not abstract to me.
It can be fine-tuned on one family's own kid. Every baby's cry is a little different. Because the pipeline is open and retrains in minutes, a parent could add clips of their own baby and the model would get better at them. A closed model treats every baby as the average baby.
I can swap the model. If a better tiny architecture comes along, the interface is a feature vector in and nine logits out. Nothing is locked to a vendor.

Demo

The repo is public: https://github.com/midnightmichigan/crywatch

python3 -m venv .venv && .venv/bin/pip install numpy scipy
.venv/bin/python crywatch/train.py      # trains, writes weights.npz + metrics.json
.venv/bin/python crywatch/predict.py path/to/cry.wav
.venv/bin/python test_flow.py           # end-to-end verification

predict.py takes any wav clip and prints the cry probability plus the top reason classes. test_flow.py replays the full pipeline and reports the metrics above. The trained weights, labels, and metrics JSON are all in the repo so anyone can reproduce the numbers without retraining.

(A demo video is in the works for a separate competition entry; the script and shot plan are in VIDEO-SCRIPT.md in the repo.)

What did not work

Judges trust posts that show the hard parts, so here are mine:

Reason classes bleed into each other. Tired and discomfort are acoustically similar, and the confusion matrix shows it. More data helps; cleverer features might help more. I have not solved this.
The dataset was the real work. The model is three matrix multiplies; the 1,305 hand-labeled clips are where the hours went, listening to crying and deciding "hungry" vs. "belly pain," clip by clip. Anyone who tells you data labeling is the easy part has never done it.
The tiny-data regime punishes every mistake. With 1,305 clips across nine classes, one bad split or one leaky preprocessing step swings the numbers by points. The test numbers above are from a clean stratified split, computed after the full pipeline was re-verified end to end.

A note on timing

This project began as my entry for a separate hardware AI competition (the repo README covers that). The repository itself was created this week, and the write-up, demo packaging, and verification pass are this week's work. I am submitting the project and the story as they stand, honestly labeled.

Prize categories

I am entering for the overall prize. CryWatch is built on pure numpy with no partner technology, so I am not entering any partner categories. The open-source core is the whole stack: open code, open weights, open data pipeline, and inference that runs anywhere.

Built by a tired dad in Hastings, Michigan. The baby is fine. She was just hungry.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass (https://dev.to/challenges/hacktoberfest-week1-2026-10-05)