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

What I Built

If you rent out a few units, the first week of every month goes like this. Rent arrives through Zelle, Venmo, Cash App, PayPal, Apple Cash and the occasional ACH or mobile check deposit. Roommates split it ("other half"). Someone pays on the 31st. The bank sends the same alert twice. Venmo sends you a request that looks a lot like a payment. And somewhere in there is the $200 pet deposit refund you sent, which is not rent received.

So you sit down with your phone and a spreadsheet and work out who has paid.

Rent Sloth does that sitting-down for you. Save the notifications into a folder (a mail rule can do it), run it overnight with cron, and in the morning you get two lines:

November 2026 rent: 4 of 6 units paid in full, $6,350.00 of $8,400.00 collected.
Short: 2B Priya Nair $650.00. Not yet: 3B Tom Becker (late after Nov 6). Check 2 payments: $300.00 (no payer named) on Nov 4, $85.00 from J Rivera on Nov 3.

Behind those two lines it also writes a ledger.csv (one row per counted payment, with how it was matched) and an audit.md that shows every field the model read, marked ok, FIXED or CHECK, plus every message it didn't count and why: a payment request, an ad, a payment you sent, a duplicate alert, or last month's rent.

The lazy part is the point. It never asks you to tag, categorize or confirm anything. It only speaks up when it can't place a payment, and then it tells you exactly which one.

Demo

A real run on an 8-core CPU with no GPU: 13 notifications in 89.6 seconds, about 7 seconds each. The GIF speeds up the model wait 6x (MP4). The real output files are in examples/. The sample inbox is synthetic: six units, thirteen messages, written to look like real alerts, including the traps above.

Code

November 2026 rent: 4 of 6 units paid in full, $6,350.00 of $8,400.00 collected.
Short: 2B Priya Nair $650.00. Not yet: 3B Tom Becker (late after Nov 6). Check 2 payments: $300.00 (no payer named) on Nov 4, $85.00 from J Rivera on Nov 3.

Python standard library only, MIT licensed. If you don't have a model handy, --from-json tests/fixtures/gemma-4-E2B-it-Q4_0 replays the recorded Gemma replies so you can see the whole pipeline in under a second.

How I Built It

The design rule: the model reads, code decides. A small model is good at pulling "who, how much, when" out of messy text. It's not something we want adding up money.

1. Read (Gemma 4 E2B, local). Each message goes to llama.cpp's llama-server (build b11617) running the 2.8 GB Q4_0 GGUF of Gemma 4 E2B, at temperature 0 with thinking turned off. The reply is constrained by a JSON Schema, so it always parses. The model returns the kind of message (money_received, money_sent, payment_request, refund, not_a_payment), plus payer, amount, date, memo and reference, each with the exact words it copied them from.

2. Check with rules, not a second model. Every quote must appear in the message. The amount must appear inside its quote. Dates are re-read from the quote, or from the message's own Date: header if the model paraphrased. Wording rules overrule the model on the kind of message: "You sent", "You paid" and "You requested" are never money received. A payer that turns out to be the bank or app that sent the alert is replaced by the person the message names ("Devon Price paid you"), or left blank and flagged.

3. Match and add up, in plain Python. A payment matches a unit by tenant name (including "Samuel" for "Sam" and a bank's "ALVAREZ, BETH M") or by a unit number in the memo. If the name and the memo point to different units, it goes to CHECK instead of guessing. Duplicates are dropped by reference number, payments outside the month aren't counted, and each unit ends up Paid, Paid (over), Partial, Not yet or Late.

How well does it work? We wrote 13 dev messages with an answer key, wrote the rules against them, then froze the rules (sha256 in the repo) and only then wrote 8 held-out messages for a different building and month.

Gemma got every amount and every date right. Its mistakes were all about who and which direction: five times it named the alert's sender as the payer (Venmo, a bank twice, Apple, and a bank-style "ALVAREZ, BETH M"), and twice it called money the landlord sent "money received". That second one is the expensive mistake, and a plain wording rule caught it both times.

The held-out set found one real hole: "ALVAREZ, BETH M" didn't match tenant Beth Alvarez, so a paid unit showed as Not yet (with the $990 listed under "Check", so not silently wrong, but wrong). It's fixed and is now two tests. Because we fixed it on those same messages, the last row isn't a clean held-out number anymore, and the README says so. Recorded model replies are in the repo and CI re-scores them on every push. 21 messages is a small test, so read it as an honest small sample, not a benchmark.

Why Does Open Innovation Matter?

Because of what's in the input. Rent alerts are tenants' names, amounts, unit numbers, bank account endings and payment memos ("rent nov half", "deposit refund - pet deposit"). That's exactly the kind of data you don't want to paste into a hosted API every month.

With an open-weight model:

• It all stays on the machine. The model file sits on disk, the server listens on 127.0.0.1, and nothing about a tenant leaves the box.
• It runs on what you already have. Gemma 4 E2B at Q4_0 is 2.8 GB and needs no GPU. Seven seconds a message is slow, and that's fine: it runs at 5:30 AM while you sleep. Slow and steady.
• Set it up once and it never bills you. No API key, no per-token cost, no rate limit, no "this model is deprecated" email next year. The weights don't change under you, so the recorded fixtures in CI stay meaningful.
• Open pieces all the way down. llama.cpp's JSON Schema-constrained decoding is what makes a 2B-class model dependable enough to build on: the output always parses, so all the effort went into checking meaning, not fixing broken JSON.

A bigger hosted model might read a few more payer names right on the first try. But the rules fix those anyway, and no rule can fix "your tenants' payment data is now on someone else's server."

Prize Categories

• Best Use of Gemma: Gemma 4 E2B (open weights) does all of the reading, locally, through llama.cpp.

Disclosure: Rent Sloth and this post were produced by an AI agent working for Sheet & Flow (we make landlord spreadsheets). The numbers above come from the recorded runs in the repo. The sample notifications and tenants are synthetic, and nothing here is accounting or legal advice.