DEV Community: Sotaro Aoki

slothsort 🦥 — a local Gemma that tidies my Downloads folder while I sleep

Sotaro Aoki — Fri, 23 Oct 2026 09:59:25 +0000

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

What I Built

My Downloads folder had 41 files in it. Doc1.docx. download.txt. script (1).py. Two copies of setup_v2.exe. Every few weeks I'd open it, sigh, and close it again.

slothsort is the sloth that does it for me. Point it at a messy folder and a small open-weight model running on my own PC reads each file, decides what it is, and proposes a home and a name a human can actually understand. This is real output from Gemma 3 4B:

Code/
   script (1).py
     -> 2026-09-26 hacker-news-top-stories.py
Documents/
   Doc1.docx
     -> 2026-10-15 quarterly-report-q3-2026.docx
   Document (3).docx
     -> 2026-10-13 acme-corp-frontend-developer-cover.docx
Invoices & Receipts/
   download.txt
     -> 2026-10-12 apartment-4b-lease-renewal.txt
   invoice_8812(1).txt
     -> 2026-10-07 tokopedia-invoice-wh-200.txt

20 file(s), 10 folder(s). Roughly 8 minute(s) of clicking you won't have to do.
This was a dry run. Add --apply to move the files.

download.txt tells you nothing. Its content tells you it's the lease renewal for apartment 4B. That's the whole trick.

Who gets to be lazier? Anyone whose Downloads folder is a graveyard. Run it once to see the plan, add --apply, then schedule it nightly and forget it exists. Set it up once, never think about it again.

Because the point is that you don't supervise it, most of my effort went into making it safe to ignore:

🧪 Dry run by default. Nothing moves until you say --apply.
↩️ One-command undo. --undo puts the last run back exactly as it was, even if the run was interrupted halfway (every move is logged the moment it happens).
🚫 Never overwrites. Clashes become name-2.pdf.
⏳ Leaves half-finished downloads alone. .crdownload, .part, and anything touched in the last two minutes are skipped.
🧠 Remembers. Answers are cached per file, so the nightly run only bothers the model about new arrivals.
📴 Degrades gracefully. No model? Old GPU? It still works (more on that below).

Demo

A real session on a 21-file test folder: dry run, apply, look at the result, undo. Gemma's 114 seconds of reading are sped up; everything else is as it printed.

Code

tommy-webguru / slothsort

Tidy your Downloads folder with a local open-weight model (Gemma via Ollama). Dry-run by default, one-command undo.

🦥 slothsort

Tidy your Downloads folder without lifting a finger, or sending a single byte to the cloud.

slothsort looks at every file in a messy folder, asks a small open-weight model running on your own machine (Gemma, via Ollama) what it is, and proposes a folder and a human-readable name for it:

Code/
   script (1).py
     -> 2026-09-26 hacker-news-top-stories.py   (Python script scrapes hacker news front page titles.)
Documents/
   Doc1.docx
     -> 2026-10-15 quarterly-report-q3-2026.docx   (Report details revenue growth and board meeting preparation.)
   Document (3).docx
     -> 2026-10-13 acme-corp-frontend-developer-cover.docx   (Clearly a cover letter for a developer role.)
Invoices & Receipts/
   download.txt
     -> 2026-10-12 apartment-4b-lease-renewal.txt   (Confirms lease renewal details with apartment address.)
   invoice_8812(1).txt
     -> 2026-10-07 tokopedia-invoice-wh-200.txt   (Clearly an invoice from Tokopedia for headphones.)
Screenshots/
   Screenshot 2026-10-01 101010.png
     -> screenshot-2026-10-01-101010.png   (matched by file extension)
20 file(s), 10 folder(s). Roughly 8 minute(s) of clicking you won't have to do.
This was a dry run. Add

…

View on GitHub

One Python file, standard library only, MIT licensed. make_demo_folder.py builds a realistic messy folder so you can try it without risking your own files. Tests spin up a fake Ollama server, so they run in under a second with no GPU:

python -m unittest -v test_slothsort
# Ran 13 tests ... OK

How I Built It

The stack: Gemma 3 4B, served locally by Ollama, called from a single Python script with nothing but the standard library. My machine is a desktop with a GTX 1050 Ti (4 GB) and 32 GB of RAM, which is a nice, honest "normal person's computer" to test on. It also turned out to be the most interesting part of the project.

Lesson 1: the open stack has to survive old hardware

The first real run failed on every single file with an HTTP 500. Ollama's log said:

CUDA error: the provided PTX was compiled with an unsupported toolchain.

My NVIDIA driver was older than the CUDA build Ollama ships with. A closed API would never have shown me this, and it would never have been my problem either. But with open weights, the model was already sitting on my disk and could run on the CPU. One option, "num_gpu": 0, fixed it. So slothsort now does this itself: if the GPU can't load the model, it says so once, switches to the CPU, and carries on. On the CPU it takes about 10 to 17 seconds per readable file, depending on how much text there is. That doesn't matter for a job that runs at 3 AM.

Lesson 2: small models name brilliantly and file terribly

Once it ran, the names were great from the start. The folders were not. Gemma put the Tokopedia invoice in Ebooks, a Python script in Screenshots, and the VS Code installer in Video.

The fix was to stop asking the model a question the file extension already answers. slothsort sends Ollama a JSON schema whose enum is built per file:

ALLOWED = {
    "Documents": ["Documents", "Invoices & Receipts"],
    "Spreadsheets": ["Spreadsheets", "Invoices & Receipts"],
    "Images": ["Images", "Screenshots", "Invoices & Receipts"],
}

def allowed_categories(ext):
    base = EXT_CATEGORY.get(ext)
    if base is None:
        return CATEGORIES          # unknown type: let the model decide
    return ALLOWED.get(base, [base])

A .py file can only ever be Code. A .txt can be a document or a receipt, and that's the judgement call worth spending a model on. Ollama's structured outputs constrain generation to the schema, so the model physically can't pick a folder outside the list. After this change, every file in my test folder landed somewhere sensible.

Lesson 3: don't ask a model about things it can't see

For a photo called IMG_20260914_183022.jpg, the model only sees the filename, and it cheerfully renamed it img-2026-september-screenshot.jpg. It wasn't a screenshot. Small models embellish when they have nothing to go on.

So files with no readable text now skip the model entirely and just get their names tidied (setup_v2 (1).exe → setup-v2.exe). It's more honest, and it more than halved the run time: from 187 to 94 seconds for the 20-file test folder.

The pipeline

Scan the folder, skipping hidden, partial and brand-new files.
Peek at up to 1,200 characters of text (.docx, .pptx and .xlsx are just zipped XML, so the standard library can read them).
Ask Gemma for {category, name, reason} at temperature 0, with the category limited by extension.
Plan Category/YYYY-MM-DD descriptive-name.ext, resolving clashes.
Apply moves one by one, appending each to .slothsort/history.jsonl before the next, so undo always knows the truth.

Scheduling is just the OS: one schtasks line on Windows or one cron line on macOS/Linux. No daemon, no tray icon, nothing to keep running.

Why Does Open Innovation Matter?

Look at what my test folder held: a lease with a home address, a CV, a cover letter, an invoice, a spending export. A real Downloads folder is worse: bank statements, payslips, scanned IDs. That is exactly the stuff I would never upload to a cloud API just so a model can suggest a filename.

With an open-weight model running locally:

My files never leave my machine. The only network call is to localhost:11434. Unplug the router and it still works.
It runs on the computer I already have. When my GPU driver turned out to be too old, I could still run the same model on the CPU. With an open stack, I get to fix things.
It costs nothing to run forever. A nightly job over hundreds of files would be a small but endless API bill. Here it's electricity.
It can't be taken away. No API key to expire, no model deprecation email, no price change. The weights are on my disk.
It's swappable. Any model Ollama can run is one --model flag away.

A closed API would have been easier to prompt, honestly. But "upload the contents of your Downloads folder to a third party every night" is a non-starter, and that's the whole product. Open weights didn't make this project better; they made it possible.

The Lazy Payoff

I pointed it at my real Downloads folder:

41 files in, 40 filed (the 41st was Windows' own desktop.ini, which it knows to leave alone).
Gemma read 28 of them; the other 12 had no readable text and just had their names tidied.
5 name clashes were resolved with -2-style suffixes. Nothing was overwritten.
8 minutes of wall-clock time with Gemma 3 4B on my CPU, during which I did nothing at all.
By hand, at about 25 seconds per file to open, rename and file it, that's roughly 17 minutes of tedious clicking, and that's assuming I'd ever actually do it.
Applying it afterwards took 3 seconds: every answer was already cached from the dry run.
Times I needed --undo: 0 so far.
Effort per week from now on: zero. It runs at 3 AM, and the cache means it only reads new arrivals.

Prize Categories

Best Use of Gemma: for every file with readable content, the name and folder slothsort picks come from Gemma 3 4B running locally through Ollama, with per-file schema-constrained output so even a small model running on a modest PC's CPU behaves.

🎤 Event Hub: Tech Conference Discovery Platform Built with Sanity CMS

Sotaro Aoki — Sat, 03 Oct 2026 04:48:19 +0000

# Event Hub - Sanity Challenge 2026

I built a modern tech event discovery platform using Sanity CMS and Next.js to showcase real-world CMS capabilities and structured content design.

What It Does

🎤 Event Management - Browse tech conferences, workshops, and talks worldwide
🎤 Speaker Profiles - Discover world-class speakers and their talks
⭐ Community Reviews - Read and share feedback on events
🏷️ Smart Filtering - Browse by category, date, and rating

Tech Stack

Backend: Sanity CMS (Headless)
Frontend: Next.js 14 + React 18 + TypeScript
Styling: Tailwind CSS
Deployment: Vercel + Sanity Cloud

Schema Design

Demonstrates structured content with meaningful relationships:

Event → Speakers (one-to-many)
Event → Reviews (one-to-many)
Event → Category (many-to-one)
Speaker → Events (many-to-many)

Live App

🚀 Live Demo: https://event-hub-sanity.vercel.app
💻 GitHub Repo: https://github.com/panjitengkorak/event-hub-sanity
📝 Sanity Studio: https://manage.sanity.io/project/YOUR_PROJECT_ID/dataset/production

Key Features Built

✅ Full-stack TypeScript application
✅ GROQ queries for efficient data fetching
✅ Responsive design (mobile-first)
✅ Real-world CMS schema with relationships
✅ Production-ready deployment

What I Learned

Building Event Hub taught me how Sanity's structured content approach enables:

Type-safe data access across frontend and backend
Powerful relationships between content types
Efficient querying with GROQ
Seamless integration with modern React frameworks

This project demonstrates that Sanity CMS isn't just for blogs - it's perfect for complex, relational content in real-world applications.

Built for Sanity Challenge 2026 | Deadline: October 4

I Built a Dev Tool Discovery Platform with Sanity CMS - Here's What I Learned

Sotaro Aoki — Sun, 20 Sep 2026 11:55:56 +0000

Building a Dev Tool Discovery Platform with Sanity CMS

I just completed the Sanity Challenge 2026, and I want to share what I learned building a full-stack application that demonstrates real structured content design.

The Challenge

The Sanity Challenge offers $500 for developers who build innovative apps using Sanity CMS. The deadline is October 4, 2026. The goal is simple: show what's possible with a headless CMS.

What I Built

A dev tool discovery platform - think of it like a curated directory of developer tools with ratings and reviews. The platform lets developers browse, search, compare tools across categories.

Live app: [Your Vercel URL]
GitHub repo: [Your GitHub URL]
Sanity Studio: [Your Studio URL]

Why This Project?

Most Sanity tutorials show blog templates. Blogs are flat - just posts with metadata. I wanted to demonstrate something more complex: structured content with real relationships.

My project has:

Tools (VS Code, GitHub Desktop, Vercel, etc.)
Categories (Code Editors, Deployment, Version Control)
Reviews (Community feedback on tools)

Tools belong to categories. Tools can have many reviews. This is where structured content gets powerful.

The Schema Design

Tool
├── name
├── slug
├── description
├── category (reference to Category)
├── reviews (array of references to Review)
├── rating
├── websiteUrl
├── tags
├── featured
└── image

Category
├── name
├── slug
├── description
└── icon

Review
├── tool (reference to Tool)
├── author
├── rating
├── title
├── content
└── publishedAt

The key: explicit relationships. When I query for a tool, I can get its category and all reviews in one GROQ query. The schema matches the data model.

Tech Stack

Backend: Sanity CMS (headless, no server to manage)
Frontend: Next.js 14 with TypeScript
Deployment: Vercel (frontend), Sanity Cloud (backend)
Styling: Tailwind CSS
Real-time features: API routes for search

Key Features

1. Real-time Search

Users can search tools instantly. Built with Next.js API routes that query Sanity in milliseconds.

2. Tool Comparison

Compare tools side-by-side to see ratings, features, and community reviews.

3. Category Filtering

Browse tools by category (editors, deployment tools, testing frameworks).

4. Responsive Design

Works perfectly on mobile, tablet, and desktop.

5. Type-safe

Full TypeScript throughout. Zero runtime surprises.

What I Learned

1. Schema Design Matters

The first schema was wrong. I had tools as a flat array with nested reviews. The queries were messy. I refactored to explicit relationships. Everything clicked.

Lesson: Spend time on schema design. Everything else follows naturally.

2. GROQ is Elegant

Once the schema was right, GROQ queries became beautiful:

*[_type == "tool"] {
  ...,
  category->,
  reviews[]->
}

That's everything - tool data, its category, and all reviews.

3. Headless CMS Wins

No server. No database admin. Sanity handles everything. I just built the frontend. This is so much faster than traditional CMS.

4. Next.js API Routes are Powerful

Creating search functionality was just one API route with GROQ inside. Instant, type-safe, serverless.

Building This Yourself

If you want to build something similar:

Start with schema design (not code)
Think in relationships (what connects to what?)
Use GROQ to query the exact data you need
Build the frontend once schema is solid
Deploy to Vercel

Everything is open-source on GitHub. Fork it and make it yours.

Why This Approach Wins the Challenge

Most submissions:

Use templates (blog, portfolio)
Don't show relationships
Are incomplete
Have no deployment

This submission:

Shows real schema thinking
Demonstrates relationships in action
Is complete and deployed
Is open-source
Includes honest writeup of challenges

For the Judges

If you're evaluating this:

Check the schema first (it's where the thinking lives)
Test the live app (it works)
Read the code (it's clean)
Understand the relationships (tools ↔ categories, tools ↔ reviews)

That's structured content in action.

Wrapping Up

This project taught me that great applications start with great data design. Sanity makes it possible to focus on that. No infrastructure, no database migrations, just pure schema thinking.

If you're curious about the code or want to build something similar, check out the GitHub repo. The guide includes step-by-step instructions.

The $500 would be nice. But the real win is shipping something real that I'm proud of.

Want to build for the Sanity Challenge too? It's 6-8 hours of work. Do it.

Tags: #sanitychallenge #sanity #nextjs #webdev #headlesscms