slothsort 🦥 — Gemma reads my messy Downloads folder so I never have to

Harsh Chaturvedi — Sun, 25 Oct 2026 16:55:55 +0000

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

What I Built

My Downloads folder is where files go to be forgotten. Invoice_88213 (1).pdf. download.pdf. image (3).png. doc_final_v2_FINAL.pdf. Every few months I tell myself I'll sort it, open it, look at forty files with meaningless names, and close it again.

The work is dull, but it isn't hard. You open each file, see what it is, give it a real name, and drop it in a folder. A small open-weight model can do exactly that. So I built slothsort, a command-line folder tidier that hands the job to Gemma 3 4B running locally through Ollama.

For every loose file, slothsort shows the model:

the name, size and date,
the first part of the text, for .txt, .md, .csv, .json, code and simple PDFs,
the file list inside a .zip,
the image itself, for screenshots and photos. Gemma 3 is multimodal, so it actually looks at your screenshots.

Gemma answers with a folder (Finance, Screenshots, Code, Notes…), a readable new name, and a one-line reason. You see the full plan before anything moves:

python slothsort.py plan  ~/Downloads   # look, don't touch
python slothsort.py apply ~/Downloads   # do it
python slothsort.py undo  ~/Downloads   # never mind

Who gets to be lazier? Anyone whose Downloads folder is a junk drawer. That's everyone.

Demo

Here's a real run on my Windows laptop: Gemma 3 4B in Ollama 0.34.2. The test folder is a fake "messy Downloads" I made with fictional bills, a payslip, screenshots, a bank CSV, code and an installer. All 14 files are in the repo, so you can run it yourself.

Before:

data.json                       export_1729834.csv        New Text Document.txt
doc_final_v2_FINAL.pdf          files.zip                 Screenshot 2026-10-21 231407.png
download.pdf                    image (3).png             Screenshot 2026-10-23 104512.png
Invoice_88213 (1).pdf           main (2).py               untitled.md
VSCodeUserSetup-x64-1.105.1.exe WhatsApp Audio 2026-10-19 at 22.14.03.mp3

What Gemma proposed (trimmed from the real log):

Finance/
  download.pdf
    -> payslip-a-sharma-september-2026.pdf
       The contents clearly show a payslip with employee and pay period details.
  Invoice_88213 (1).pdf
    -> electricity-bill-september-2026-a-sharma.pdf
  doc_final_v2_FINAL.pdf
    -> rental-agreement-august-2026.pdf
  export_1729834.csv
    -> bank-statement-october-2026.csv

Code/
  Screenshot 2026-10-23 104512.png
    -> android-gradle-build-failure.png
       The screenshot shows a failed Gradle build output from an Android project.
  main (2).py
    -> python-results-checker.py
  untitled.md
    -> talk-ideas-college-tech-fest.md

Notes/
  New Text Document.txt
    -> groceries-sunday-plumber.txt
       The file contains a shopping list and a reminder about a plumbing issue.

14 files planned. Nothing has moved yet.

Look at download.pdf → payslip-a-sharma-september-2026.pdf. Nothing in that filename says "payslip". Gemma got it by reading the document. The Gradle screenshot is even better: there's no text to extract, so the model read the error off the image.

After apply, the folder is a tidy tree. After undo, all 14 files were back exactly where they started. The full, unedited log is in demo/run-log.txt.

Code

Chaturvediharsh123 / slothsort

🦥 slothsort

A lazy, local folder tidier. Point it at your messy Downloads folder. An open-weight model running on your own machine (Gemma 3 4B via Ollama) looks at every loose file. It reads text files and PDFs, and actually looks at images. Then it suggests a folder and a readable name for each one.

You review the plan, apply it with one command, and undo it with another. Nothing leaves your computer.

download.pdf                      -> Finance/payslip-a-sharma-september-2026.pdf
Screenshot 2026-10-23 104512.png  -> Code/android-gradle-build-failure.png
New Text Document.txt             -> Notes/groceries-sunday-plumber.txt

(Real output from Gemma 3 4B on a CPU-only Windows laptop. The full log is in demo/run-log.txt.)

Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 3: Slow and Steady.

Why it's built like this

Local model, local files. Downloads folders are full of payslips, bank exports, rental agreements and boarding passes. Sending their contents to a cloud API just to…

View on GitHub

It's a single Python file (~500 lines) using only the standard library. There are 13 tests, which run against a fake Ollama server, so CI doesn't need a model.

How I Built It

The model: Gemma 3 4B, via Ollama. I wanted one small model that could handle text and screenshots, since screenshots are half of what's in my Downloads. Gemma 3 4B is multimodal, runs on a laptop CPU, and was already pulled on my machine. I talk to Ollama's /api/chat with plain urllib. No SDK, no LangChain, nothing to install except Ollama.

Structured output keeps it honest. Small models like to chat. Ollama lets you pass a JSON Schema in format, so every answer is forced into this shape:

SCHEMA = {
    "type": "object",
    "properties": {
        "category": {"type": "string", "enum": CATEGORIES},
        "new_name": {"type": "string"},
        "reason":   {"type": "string"},
    },
    "required": ["category", "new_name", "reason"],
}

The category has to be one from my list, and with temperature: 0 the same file gets the same answer every time. I still don't trust the output blindly: names are slugified, so a creative ../../etc/passwd becomes etc-passwd. If the model is offline or returns junk, the file falls back to an extension-based guess and is marked (guess) in the plan.

Built for a sloth, not a demo. These are the details that make it safe to run on a real folder:

plan touches nothing. It writes .slothsort/plan.json, and apply executes exactly that plan.
apply never overwrites. Name clashes become -2, -3, and if a target appears between plan and apply, that move is skipped.
Every apply is logged, and undo reverses it and removes the folders it created.
Half-finished downloads (.crdownload, .part), hidden files and desktop.ini are ignored.
Decisions are cached by file fingerprint. My first run took 428s. Running plan again on the same folder reported Took 0s, because no file needed the model. A nightly run only pays for new downloads.

That last point is the whole "slow and steady" idea. On my laptop, Gemma spends ~16–23s on a text file and ~70s on a screenshot. Waiting for that by hand would be slow. But slothsort tidy is built for a scheduler, and at 2am nobody cares how long it takes:

schtasks /create /sc daily /st 02:00 /tn slothsort /tr "python C:\path\to\slothsort.py tidy %USERPROFILE%\Downloads"

I iterated on real output. In the first run, files.zip came back as zip-file.zip. Fair enough, since the model only saw the name. I added a step that lists the files inside the archive. On the next run it became assignment3-report-code-main.zip. That loop of running it, reading the log and fixing what the model couldn't see is most of what building with a small local model looks like.

Why Does Open Innovation Matter?

Look at what's actually in that demo folder: a payslip, a bank statement, a rental agreement, an electricity bill and a train booking with a PNR. That's a normal Downloads folder. To sort it, the model has to read those files.

With a closed API, tidying my folder would mean uploading my salary, my bank transactions and my address to someone else's server, just to pick a folder name. That's a terrible trade, and it's the reason I'd never run a cloud-based version of this on my real files.

With an open-weight model running locally:

My files never leave my laptop. The only network call in the whole program goes to localhost:11434. Pull out the network cable and it still works.
It costs nothing to run forever. My first run made 14 model calls, and a big Downloads folder can mean hundreds. On an API I'd hesitate before every nightly run. Locally it's free, so I can let it run every night.
I can swap the brain. It's one flag: --model qwen2.5vl or --model llava, or a smaller text-only model on a weak machine. Nothing is tied to one vendor's SDK.
Ollama's open tooling did the heavy lifting. Structured outputs, image input and keep-alive model caching are all features of an open-source runtime I can read and rely on.

The closed models would be smarter. But for a file tidier, privacy and "free to run forever" matter more than the last few points of accuracy, and the misses are cheap to fix because of plan-and-undo.

The Lazy Payoff

On the 14-file test folder, slothsort did in one command what would take me a good 10–15 minutes by hand: opening each PDF to see what it is, squinting at screenshots, and typing new names. More importantly, it's the kind of 15 minutes I never actually spend, which is why my real Downloads folder looks the way it does.

It's not perfect, and I'd rather show the misses than hide them. Of 14 files, Gemma got sensible names for all of them, but put a few in debatable folders:

The train booking screenshot went to Finance/ (because of the fare) instead of Screenshots/, even though the prompt says screen captures go to Screenshots.
A bar chart image I'd exported went to Screenshots/.
The Gradle error screenshot went to Code/. Honestly, I like that one.

This is exactly why the tool plans first. You read the plan in ten seconds, and if you don't like it you don't apply it, or you undo. Being lazy is safe when the machine shows its work.

Prize Categories

Best Use of Gemma: Gemma 3 4B runs locally through Ollama and is the core of the project. It reads text and PDFs, and uses its vision input to classify and name screenshots and images.

Built with help from an AI coding assistant (Claude), which wrote much of the code and helped draft this post. The model calls, test run and results above are all real.

DEV Community: Harsh Chaturvedi