SlothSort

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

What I Built

I built SlothSort, a local AI file organizer for people who keep saying, “I’ll clean that folder later.”

You point SlothSort at a messy folder like Downloads, Desktop, or a project dump, and it uses a locally running open-weight model to suggest:

• cleaner filenames
• sensible folders
• which files belong together
• a short explanation for every decision

The important part: SlothSort does not immediately move anything.

It creates a dry-run plan first, so I can review what the AI wants to do before applying it.

The workflow is basically:

slothsort ~/Downloads

Review the plan.

Then, if it looks good:

slothsort ~/Downloads --apply

It turns a task I repeatedly procrastinate on into something closer to approving a checklist.

Very sloth-friendly.

Demo

The demo shows SlothSort taking a deliberately messy folder containing screenshots, PDFs, invoices, notes, images, and random downloads and turning it into a clean organization plan.

Because the model runs locally, the demo also works without sending the filenames or file contents to an external AI service.

Demo:

[ADD YOUR DEMO / VIDEO LINK HERE]

Code

The project is open source and designed to be easy to run on a normal laptop.

Repository:

[ADD YOUR GITHUB REPOSITORY HERE]

The basic setup is:

git clone [YOUR_REPOSITORY]
cd slothsort

pip install -r requirements.txt
ollama pull qwen3:4b

python -m slothsort ~/Downloads

SlothSort defaults to preview mode, so nothing is changed unless --apply is explicitly provided.

How I Built It

SlothSort is built around local inference with Ollama and an open-weight Qwen3 model.

Instead of asking the model for a paragraph describing what it thinks should happen, SlothSort requests structured output representing a file-operation plan.

Conceptually, the model receives metadata such as:

IMG_4821.png
bank_statement_june.pdf
Screenshot 2026-10-18.png
notes-final-final2.txt
invoice_acme_1042.pdf

and returns structured suggestions similar to:

{
  "operations": [
    {
      "source": "invoice_acme_1042.pdf",
      "destination": "Finance/Invoices/Acme_Invoice_1042.pdf",
      "reason": "The filename indicates that this is an invoice from Acme."
    }
  ]
}

The application validates that plan before touching the filesystem.

I intentionally separated the AI decision layer from the file-operation layer.

The model can suggest actions, but ordinary application code decides whether those actions are valid and safe.

That also makes the model replaceable.

For example:

slothsort ~/Downloads --model qwen3:4b

can be changed to another locally available model without rewriting the application.

The AI is not an optional chatbot bolted onto the project. The open-weight model is the component doing the tedious part: interpreting messy human filenames and turning them into useful organization decisions.

Why Does Open Innovation Matter?

For this project, running an open-weight model locally changes the product itself.

A file organizer can see surprisingly personal information.

Even filenames can reveal things like:

medical_results.pdf
salary_revision.pdf
passport_scan.jpg
client_contract_draft.docx

I did not want organizing those files to require sending that information to a server I do not control.

With local inference, the workflow can stay on the user's machine.

There is another advantage: SlothSort is not tied to one AI provider.

If a different open model works better, I can swap it.

If I want a smaller model for an old laptop, I can use one.

If I want a larger model on a workstation, I can use that instead.

If I want to customize the prompts or fine-tune a model around a specific filing system, I can do that too.

There is no API key required for every run, no per-file inference bill, and no dependency on a remote service remaining available.

A closed API could certainly classify files, but the open approach gives this particular project the properties I actually wanted:

privacy, offline operation, model choice, hackability, and local ownership.

Those are not implementation details here. They are features.

My Agent Session

I used an AI-assisted development workflow while designing and building SlothSort, including thinking through the architecture, safety boundaries, CLI experience, and local-model integration.

DevRelay session:

[ADD YOUR DEVRELAY SESSION HERE]

The Lazy Payoff

File organization is rarely difficult.

It is just annoying enough to keep postponing.

Normally the workflow looks like this:

open file → figure out what it is → decide where it belongs → rename it → move it → repeat 50 times

With SlothSort, it becomes:

scan folder → review plan → approve

I still keep the human in control, but I remove most of the tiny repetitive decisions.

That is the kind of laziness I wanted for this challenge: not avoiding useful work entirely, but letting the computer handle the boring part so I only have to make the decisions that matter.

Slow and steady.

Preferably while doing almost nothing.