DEV Community: Saptadeep Nath

SlothSort — Tidy Files, Slowly

Saptadeep Nath — Sun, 25 Oct 2026 19:04:50 +0000

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

What I Built

My Downloads folder has a familiar problem: files accumulate faster than I organize them. Screenshots end up beside lecture notes, code files get buried under documents, and filenames like document1.pdf, IMG_1234.jpg, and final_final_v2.txt don't make finding anything easier.

I built SlothSort, a local-first, AI-powered file organizer that does the tedious part for me.

SlothSort scans a selected directory, including nested folders, and suggests categories and more descriptive filenames using an open-weight Qwen model running locally through Ollama. It also detects exact duplicate files using SHA-256 hashing.

Instead of immediately making changes to my filesystem, SlothSort lets me review the proposed changes first. It creates organized copies in a dedicated output directory, preserves the original folder paths beneath category folders, and provides an undo mechanism for its copy operations.

The idea is simple: spend less time organizing files and more time doing literally anything else.

What it can do:

📂 Scan directories recursively.

🧠 Use local Qwen inference to suggest file categories and names.

🔍 Detect exact duplicates using file hashes.

✏️ Let users review and edit naming suggestions.

🛡️ Keep the original files untouched when creating organized copies.

↩️ Provide an undo mechanism for supported copy operations.

📴 Run its core workflow locally after the dependencies and model have been installed.

Demo

dev4.mp4 - Google Drive

drive.google.com

In the demo, I'll show the workflow from selecting a messy test directory to reviewing AI-generated suggestions and creating an organized copy.

The most important part is that SlothSort doesn't need to send my files to a third-party AI API to perform its core AI-assisted workflow.

Code

Gitcarbonath / SlothSort

SlothSort

A local-first file organizer designed to make folder cleanup safer and less tedious.

SlothSort is a work-in-progress project built with Python, FastAPI, a lightweight browser interface, and a locally running Ollama model (Qwen).

Status: In development. Features and setup instructions may change as the project is tested.

What it does

Scan a selected folder, including subfolders.
Group files into categories based on their extensions.
Optionally request naming or categorization suggestions from a local Qwen model for supported files.
Detect byte-identical files using SHA-256 hashes.
Copy organized files into a separate output folder rather than moving or deleting originals.
Preserve relative folder structure where appropriate and avoid overwriting existing files.
Support undoing the app's copy operations where possible.

AI analysis may be skipped for file types where it is unlikely to be useful. Exact behavior depends on the current version.

Why SlothSort?

File cleanup can be repetitive, and uploading personal…

View on GitHub

The project is built with Python and a lightweight browser interface. Its core components include:

FastAPI for the backend and API endpoints.
HTML, CSS, and JavaScript for the user interface.
Ollama for local model inference.
Qwen 2.5 3B as the initial language model.
Python filesystem operations and SHA-256 hashing for file management and duplicate detection.

The goal is to keep the application simple enough to run on an ordinary laptop without requiring a cloud deployment or a complicated infrastructure setup.

How I Built It

I started with a simple local web application: a Python backend, a browser-based interface, and a local language model.

The first version could scan a folder and suggest categories, but it had two practical problems. It didn't inspect nested folders, and the AI analysis was slow enough that it wasn't always clear whether anything was happening.

I iterated on the application to address those issues.

1. Local AI with Ollama and Qwen

SlothSort uses Qwen 2.5 3B through Ollama. The model helps make naming and categorization decisions, while ordinary Python handles deterministic operations such as hashing files, creating directories, and copying files.

This separation matters: the model proposes what should happen, but the application is responsible for carrying out filesystem operations.

2. Faster analysis

Calling a language model for every file can be unnecessarily expensive in time and computation. SlothSort therefore uses extension-based rules for familiar file types and reserves AI analysis for text files and unknown file types by default.

An optional all-file analysis mode can request naming suggestions for additional file types, although binary files may provide only filenames and folder-path clues unless their contents are extracted or analyzed by a suitable model.

3. Recursive scanning and safer organization

The initial implementation only scanned files directly inside the selected folder. I changed it to scan nested directories and display their relative paths.

I also changed the organization workflow to create copies in a dedicated output directory rather than scatter files throughout the original directory. Existing destination files are not intentionally overwritten, and the original files remain available.

4. Human review before changes

AI suggestions aren't always correct. SlothSort lets users inspect the proposed categories and names before applying them.

The application combines AI assistance with conventional safeguards instead of giving the model unrestricted control over the filesystem.

Why Does Open Innovation Matter?

For SlothSort, open innovation isn't just a way to avoid API costs. It changes where the computation happens and who controls the workflow.

Privacy and local processing

Files can contain personal documents, university assignments, screenshots, source code, and other sensitive information. Sending all of them to a remote AI service just to organize a folder is often unnecessary.

With Ollama running locally, SlothSort can send supported text previews to a model on the same machine rather than requiring a third-party inference API. This keeps the core workflow local, provided Ollama is configured to use a trusted local endpoint.

Control over the model

Using an open-weight model means I'm not locked into a single hosted AI provider. I can experiment with different compatible models, adjust prompts, and change how naming suggestions are generated.

A more accessible development process

Running inference locally makes experimentation practical without needing a paid API key or a deployed AI backend. The main costs are the hardware, storage, and time required to run the model.

There are trade-offs, of course. Local inference can be slower on a CPU, and a small model may generate inaccurate or overly generic names. Open innovation gives me the freedom to work on those limitations rather than treating a hosted model as a black box.

For a file organizer, keeping the data and the decision-making process under the user's control is a meaningful advantage.

The Lazy Payoff

The intended payoff is straightforward: fewer repetitive file-management decisions.

Instead of manually opening folders, deciding where files belong, and renaming them one by one, I can scan a directory, review a proposed organization plan, and let SlothSort prepare the copies.

I'm not claiming a measured time saving yet. I want to evaluate that properly by comparing manual organization with SlothSort on the same test folder.

The next improvements I'd like to explore are better content-aware naming for PDFs and images, clearer progress reporting, and automated tests for filesystem safety.

ScopeGuard AI: Catch Scope Creep Before It Costs You

Saptadeep Nath — Sun, 18 Oct 2026 19:24:59 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

ScopeGuard AI is a local-first AI assistant for freelancers, independent developers, consultants, and small agencies who need to manage changing project requirements.

Here's what it does:

Analyses client requests against the project's original agreed scope.
Classifies requested changes as in_scope, potentially_out_of_scope, or needs_clarification.
Provides supporting evidence by quoting relevant wording from the agreement.
Explains its assessment and recommends the next step.
Drafts professional client replies that users can review, edit, and copy.
Stores projects and analysis history in a local SQLite database.

One important design principle is that an unmentioned feature isn't automatically an explicitly excluded feature.

For example, if an agreement says "Do not implement checkout," ScopeGuard AI should identify checkout as explicitly excluded. If price sorting isn't mentioned, the system should recognise that the agreement may be insufficient to determine whether it was included.

The goal isn't to replace a freelancer's judgement or provide legal advice. It's to make scope discussions more structured, evidence-based, and less uncomfortable.

Demo

dev3.mp4 - Google Drive

drive.google.com

Code

Gitcarbonath / ScopeGuard-AI

ScopeGuard AI

An evidence-led, local-first assistant for reviewing client requests against an agreed project scope.

ScopeGuard AI helps freelancers and small development teams review proposed changes before agreeing to them. It compares a client's request with the project's stated scope, separates the request into findings, quotes relevant scope evidence, and drafts a professional reply for the user to review.

ScopeGuard AI is a decision-support tool, not a legal adviser. AI assessments can be incomplete or incorrect. Always review the evidence and use your own judgement before making commitments to a client.

Features

Three-way classification: in_scope, potentially_out_of_scope, and needs_clarification.
Evidence-led findings: relevant quotations from the agreed scope and an explanation of what the wording does—and does not—establish.
Explicit exclusion handling: distinguishes a feature expressly excluded by the agreement from one that is simply not mentioned.
Separate findings for combined requests: evaluates individual requested features when the analysis returns…

View on GitHub

How I Built It

ScopeGuard AI combines an open-weight language model with a conventional application backend.

Technology stack

Gemma 3 4B: The language model used for analysing client requests.
Ollama: Runs the model locally and provides the inference interface.
FastAPI: Handles API requests and backend analysis logic.
Pydantic: Validates request and response data.
SQLite: Stores project information and analysis history.
React and Vite: Power the interactive frontend.

The workflow is straightforward:

A user saves the original agreed scope for a project.
The user enters a new client request.
The backend sends the relevant context to the model for analysis.
The application validates and refines the returned classification and supporting evidence.
The frontend presents the findings, recommended action, and editable reply.

The most challenging part wasn't simply getting an LLM to classify a request. It was making sure the explanation remained grounded in the agreement.

During testing, I encountered cases where the model was too cautious about routine visual changes, too confident when the original scope was vague, or selected a valid quotation that wasn't the most relevant evidence.

I worked on improving feature-level classification, evidence selection, explicit-exclusion handling, and the distinction between missing information and an actual prohibition.
These improvements don't eliminate model errors, but they make the reasoning easier to inspect. The user remains responsible for reviewing the result before making a decision.

Why Does Open Innovation Matter?

For this project, open innovation matters because of control over inference, data handling, and operating costs.

Client agreements and project requirements can contain commercially sensitive information. By designing ScopeGuard AI around local inference with Ollama, I can analyse project information on my own machine without requiring a hosted model API for every request, provided the model endpoint is configured locally.

Using an open-weight model also makes experimentation easier. I can try different supported models, compare their classifications, adjust the analysis prompts, and improve the evidence-handling logic without redesigning the entire application around a proprietary API.

There are trade-offs. Local inference requires sufficient hardware, and smaller models can still make mistakes. Downloading a model may require an internet connection, and the privacy benefits depend on the endpoint and deployment configuration.
For this use case, however, having control over where inference happens is a meaningful advantage.

Open-source application code also lets other developers inspect the implementation, reproduce issues, contribute improvements, and adapt the project to their own workflows.

Prize Categories

Best Use of Gemma

ScopeGuard AI uses Gemma 3 4B through Ollama as its core language model for analysing client requests against agreed project scopes.

REALITY.EXE: Some Problems Can't Be Solved on a Screen 🌿

Saptadeep Nath — Sun, 11 Oct 2026 04:52:38 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

REALITY.EXE is a scavenger-hunt-style game where the real world becomes the game environment.

Instead of navigating a fictional map or completing conventional digital quests, players receive challenges that encourage them to explore their surroundings, observe everyday objects, and find evidence in the physical world.

Here's how it works:

🎯 AI-generated missions: Players receive challenges containing objectives and clues.

🌎 Real-world exploration: Players must step away from their screens and search their physical environment for things that match the mission.

📸 Photo-based evidence: Players submit photographs of what they discover.

🤖 AI-powered analysis: A vision-language model analyses submitted images to help evaluate whether the evidence matches the challenge.

🏆 XP and progression: Completing challenges rewards experience points and advances player progression.

The game also includes a timer, hints, and a progression system to make exploration feel like a game rather than a checklist.

The central idea is simple: use AI to encourage people to interact with the physical world, not just generate more content for them to consume on a screen.

Demo

https://drive.google.com/file/d/13slxoySy0zVNZGcVZyhnaPa9PrEGQlEq/view?usp=sharing

Code

Gitcarbonath / REALITY.exe

An AI-powered real-world exploration game where some problems can't be solved on a screen.

REALITY.EXE — v0.1

A mobile-first PWA concept for Hacktoberfest 2026 "Touch Grass".

Core loop

Configure a case.
Open-source AI generates the mystery.
Put the phone away and explore the real world.
Photograph evidence.
Vision AI verifies it.
Solve the case or receive a new clue.

Run locally

Backend

cd backend
python -m venv .venv
.venv\\Scripts\\Activate.ps1
pip install -r requirements.txt
uvicorn app.main:app --reload

Frontend

cd frontend
npm install
npm run dev

Open the Vite URL on your computer. For phone testing on the same Wi-Fi, run Vite with npm run dev -- --host and set VITE_API_URL to the computer's LAN URL before starting the frontend.

The backend currently uses Ollama if available and has safe fallback cases for development. Default models are gemma3:4b for text and vision; change TEXT_MODEL and VISION_MODEL environment variables if needed.

View on GitHub

The project is open source, and the repository contains the application code and setup instructions.

The main technologies are:

Frontend: React + Vite
Backend: Python + FastAPI
AI inference: Ollama
AI model: Gemma 3 4B, used for text generation and vision tasks
Persistence: SQLite

The architecture keeps the frontend, backend, and local inference separate, making it possible to develop and test the application without relying on a paid cloud AI API.

How I Built It

Open innovation made this project possible without requiring a paid AI API.

Using an open-weight model through Ollama gave me the ability to experiment with AI-powered gameplay on my own hardware. I could iterate on prompts, test challenge generation, and experiment with image analysis without having every interaction depend on a paid external service.

It also gave me more control over the development environment and the way the model integrates with the application.

For an independent developer working with a zero-budget constraint, that freedom matters. It makes experimentation accessible and allows the focus to remain on the idea itself rather than the cost of every model request.

Open innovation also makes the project easier for other developers to inspect, learn from, modify, and extend.

I see REALITY.EXE as an experiment in a broader possibility: AI doesn't have to keep us inside digital environments. It can help us engage more meaningfully with the world outside them.

Why Does Open Innovation Matter?

Open innovation made this project possible without requiring a paid AI API.

It also gave me more control over the development environment and the way the model integrates with the application.

Open innovation also makes the project easier for other developers to inspect, learn from, modify, and extend.

I see REALITY.EXE as an experiment in a broader possibility: AI doesn't have to keep us inside digital environments. It can help us engage more meaningfully with the world outside them.

Prize Categories

This submission is for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

I am entering Best Use of Gemma.

Gemma 3 is the central AI component of REALITY.EXE. It runs locally through Ollama and is responsible for converting unstructured team updates into structured project events that drive the referee's analysis.

Group Project Referee: A local-AI assistant for understanding the real state of collaborative projects

Saptadeep Nath — Sun, 04 Oct 2026 23:24:37 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

Group Project Referee is a local-AI project coordination assistant built for my hackathon teammates.

Group projects have a surprisingly common problem: everyone gives updates, but nobody has a reliable picture of what is actually happening.

One person says an API is finished. Someone else says they still cannot access it. Another person is waiting for a database migration. A blocker gets fixed, but the old blocker continues to make the project look unhealthy.

I built Group Project Referee to act as a neutral referee for these situations.

Team members simply submit updates in plain language, such as:
"I am working on the authentication tests. I need Priya's database migration before I can run the tests."

The referee extracts useful project information from those updates:

Completed work
Work currently in progress
Blocked work
Dependencies
Risks
Potential conflicts
Resolved issues
Suggested next actions

The important part is that the system keeps an evidence trail. AI conclusions can be traced back to the actual team updates that produced them.

It doesn't try to decide who is lying or who is right. It identifies statements that may need clarification and lets the team investigate them.

The result is a shared project dashboard that answers:
"What is actually happening in our project right now?"

Demo

https://drive.google.com/file/d/1UFVnYGsj6oXr8sYMaWgfnMKzoPrJS7zS/view?usp=sharing

Code

Gitcarbonath / group-project-referee

Group Project Referee

A local-AI assistant for understanding the real state of collaborative projects.

Built for the Hacktoberfest Weekend Challenge: Build for a Friend.

Repository: https://github.com/Gitcarbonath/group-project-referee

Why I built it

Group projects are difficult to coordinate when updates arrive as informal messages. One teammate may finish an API while another still cannot access it; a blocker may be resolved without everyone noticing. Group Project Referee was built to help teammates see progress, dependencies, risks, and unresolved work without assigning blame.

What it does

Teammates submit natural-language updates, such as:

I am working on the authentication tests. I need the database migration before I can run them.

The application stores the updates and uses Gemma 3 running locally through Ollama to interpret project events. A project dashboard displays:

Completed, in-progress, and blocked work
Risks and possible conflicts
Dependencies and suggested next actions
A chronological update timeline
Evidence linking findings to…

View on GitHub

How I Built It

The core of the project is Google's Gemma 3, running locally through Ollama.

Instead of sending team updates to a hosted AI API, the application sends them to a local Gemma model for structured extraction.

                Team Member
                     │
                     │ Natural-language update
                     ▼
              React Dashboard
                     │
                     ▼
                FastAPI
                /       \
               /         \
              ▼           ▼
         SQLite        Ollama
                          │
                          ▼
                       Gemma 3
                          │
                          ▼
                 Structured events
                          │
                          ▼
                Project State Engine
                          │
                          ▼
                Referee Dashboard

Gemma is responsible for understanding the natural-language updates and extracting events such as:

completed work
started work
blockers
dependencies
risks
conflicts
resolutions The backend then uses deterministic project-state logic to distinguish historical events from the current project state. For example, if someone originally says: "I can't access the login API."

and later says:
"The login API access issue is fixed."

the original blocker remains visible in the project timeline, but it should no longer be counted as an active blocker. This separation between history and current state became one of the most important design decisions in the project.

The dashboard also supports multiple devices connecting to the same local FastAPI server, allowing team members on the same network to see updates from one another.

Why Does Open Innovation Matter?

For this project, using an open-weight model locally wasn't just a way to satisfy the challenge requirement. It directly changes what the application can be.

A group-project referee deals with potentially sensitive information:

unfinished work
internal project problems
disagreements between teammates
technical blockers
project architecture
development progress

Sending all of that to a closed third-party AI API would introduce an external dependency and require trusting another service with the team's project data.

With Gemma running locally, the team can keep its updates on its own machine.

It also gives us much more control over the system. We can experiment with prompts, model versions, extraction formats and deterministic logic without redesigning the application around a proprietary API.

Most importantly, the AI becomes a component we can run, inspect and build around rather than a remote service that the project depends on.

That is what open innovation made possible here: a private, local AI referee that can become part of the project's infrastructure itself.

Prize Categories

I am entering Best Use of Gemma.

Gemma 3 is the central AI component of Group Project Referee. It runs locally through Ollama and is responsible for converting unstructured team updates into structured project events that drive the referee's analysis.