SlothPlan：做得更少的待辦清單

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

The problem

My to-do list has 47 items. Yours probably does too. And here's the dirty
secret of productivity culture: the list isn't the work. Triaging the
list is the work — the staring, the re-ordering, the guilt-math of "is
learning Spanish more important than calling the dentist?" I have spent
entire Sunday mornings reorganizing tasks instead of doing them, which is
just procrastination wearing a planner's clothes.

Every to-do app on the planet answers this with more features: priorities,
tags, Eisenhower matrices, AI scheduling assistants that need your calendar,
your email, your soul, and a $12/month subscription. They make the triage
heavier. Nobody built the app that does the triage for you and then —
this is the important part — tells you to do less.

So for "Slow and Steady" I built exactly that: a tool that rewards
laziness by doing the one piece of work you were avoiding (deciding what
matters), capping your day at three things, and granting you written
permission to delete the rest.

What I built

SlothPlan — a command-line tool where you dump a messy to-do list and
get back three buckets: DO TODAY (max 3, non-negotiable), DEFER
(officially not today's problem), and DELETE (permission granted, let
it go). Each item gets a one-line reason. The judgment comes from a local
open-weight model; the guarantees come from deterministic code.

python3 -m slothplan triage -f my-messy-todos.txt

The twist, same as my Week 2 entry: the model, the inference engine, and
all the code run on your own machine. No account. No API key. No
subscription. Your to-do list — which is, let's be honest, a map of your
anxieties — never touches a network.

The demo (real transcript, unedited)

I fed it a 12-item Tuesday dump. Here is what the recorded run produced
(full transcript in the repo's demo-output.txt — nothing cherry-picked):

=== SLOTHPLAN triage ===
method: rule-based fallback (--no-llm was passed; no model was run)

DO TODAY (max 3) — your only decisions today:
  1. Pay electricity bill, due Friday or they cut the power
     -> looks time-sensitive — it names a deadline, payment, or an urgent event
  2. Reply to Priya about the wedding RSVP — deadline is tomorrow
     -> looks time-sensitive — it names a deadline, payment, or an urgent event
  3. Submit the Hacktoberfest Week 3 entry README tonight
     -> looks time-sensitive — it names a deadline, payment, or an urgent event

DEFER — officially not today's problem:
  4. Call dentist to reschedule the appointment
     -> looks time-sensitive — it names a deadline, payment, or an urgent event [moved from today: the 3-item cap keeps your day lazy]
  12. Call mom back — she called twice today
     -> looks time-sensitive — it names a deadline, payment, or an urgent event [moved from today: the 3-item cap keeps your day lazy]

DELETE — permission granted, let it go:
  10. Delete that crypto spam email from "DOUBLE YOUR COINS"
     -> matches a junk pattern — nothing of value is lost
  11. Reorganize my Netflix watchlist
     -> matches a junk pattern — nothing of value is lost

That's the deterministic mode (--no-llm), and it's the mode I'd actually
use daily: three real obligations surfaced, the dentist and mom politely
bounced by the cap with an explanation, and the crypto spam and the
Netflix-watchlist reorganization sentenced to death. Twelve decisions I
didn't have to make.

Now the confession, because the transcript has two runs and I'm not hiding
the first one: when I let the 0.5B model judge all 12 items itself, it
took "rewards laziness" as a personal mission. It deferred the
electricity bill with the reason "no deadline, start next month" — for
a bill due Friday. It called buying milk "spam". It deleted calling my
mother. Every verdict parsed cleanly — 12/12, zero fallbacks — but its
judgment was a sloth with an agenda. The transcript shows it exactly as
it happened, which is the point of the architecture below: the model's
opinions are suggestions; the deterministic layer holds the guarantees.

How it works

Deliberately boring architecture, because boring ships:

• Parsing (stdlib only): every non-empty line is a task; # comments and bullet/checkbox markers are stripped. My sample file's header comment got triaged as a task in the first build — fixed, and there's a test for it now.
• Judgment (slothplan/llm.py): one verdict per task from Qwen2.5-0.5B-Instruct (Apache 2.0 open weights, Q4_K_M quantized) through the llama.cpp binary (MIT). Greedy decoding, ~3 seconds per item on two CPU cores. The model emits a single bucket word plus a short reason — a shape small enough for a 0.5B model to hold. This was a discovery, not the plan: my first prototype asked for one big JSON object covering all tasks, and the model hallucinated item numbers 13–20 for a 12-item list and stuffed 12 entries into a 3-item bucket. So the model judges one task at a time, and structure is enforced by code.
• Enforcement (slothplan/triage.py): every verdict is parsed and validated. Max 3 in "today" — overflow is moved to defer with the reason printed, so the cap is visible, not silent. Unparseable verdicts fall back to keyword rules and are labeled as fallback in the output. Nothing fails silently, ever.
• Zero third-party Python dependencies. Python 3.8, two downloaded files, and it runs. 29 unit tests, all passing.

Why open innovation matters

This tool cannot exist on a closed API, for two reasons — one
practical, one philosophical.

Practically: SlothPlan's entire design is a bet that a small model is
enough. A 0.5B model is honest about what it is — opinionated, sometimes
wrong, occasionally deleting your electricity bill — and the whole
architecture (deterministic guardrails, labeled fallbacks, a --no-llm
mode) is built around that honesty. You can only build that way if you can
run the model locally, iterate on prompts for free at 3 a.m., and ship
something whose marginal cost per triage is exactly zero. A closed API
charges per token, which means every design decision bends toward fewer,
bigger calls — the opposite of this architecture. And a to-do list is
personal enough that "send it to someone's cloud" was never on the table.

Philosophically: the open-weights ecosystem is what lets a student with a
$0 budget and a borrowed VM build something in a day that would have been
a research project five years ago. Qwen2.5's weights are public under
Apache 2.0. llama.cpp is MIT. My code is MIT. Anyone can audit every layer,
swap in a bigger GGUF with one flag, or fork the whole thing. That
composability — weights, engine, and app all inspectable and replaceable —
is open innovation working exactly as advertised. The moat isn't the model;
it's the trust that comes from everything being auditable.

Honest limitations

I'd rather tell you than have you discover them:

• The bundled model is 0.5 billion parameters — tiny on purpose, so it runs on any laptop CPU. Its verdicts are opinions, and sometimes bad ones (see: the electricity bill incident). Any GGUF drops in via --model; a bigger model would judge better.
• Reasons are sometimes missing ((no reason given)) — the model often emits just the bucket word despite being shown examples.
• The rule-based fallback is keyword heuristics, not understanding. It won't catch "renew the thingy before the thing expires."
• Prototype built in a day for a challenge, not a hardened product. 24 items max per run, .txt input, CLI only.

Bonus-points honesty: I have no first user yet — this was built for
the challenge this week, starting Monday morning. The demo above is real
output from the actual tool, and the limitations section is real too.

Try it

Repo: https://github.com/swarnnim/slothplan

./scripts/download-llamacpp.sh
./scripts/download-model.sh
python3 -m slothplan triage -f sample_todos/messy.txt

If you also have a 47-item list you're avoiding: what's the one task on
it you'd secretly love an app to delete for you? That's the roadmap —
a bigger delete bucket.