This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady
What I Built
I built LazyShift AI, a local-first AI workspace that takes care of repetitive file-organization work so people don't have to.
The idea is simple:
Your files are messy. LazyShift handles the boring part. You review the decisions. Then you let it work.
Instead of manually going through hundreds of files in a Downloads folder, LazyShift can:
- Scan folders and understand their contents
- Categorize files
- Detect exact duplicates using file content
- Extract useful text from supported documents
- Use a local open-weight AI model to suggest organization
- Propose file moves and renames
- Let the user review, approve, reject, or modify suggestions
- Execute approved filesystem operations
- Maintain an operation history
- Provide an undo mechanism for supported operations
- Run approved work through QuickShift or a persistent NightShift queue
The goal is not to give an AI unrestricted access to someone's filesystem.
The goal is to create a safe workflow:
Scan → Understand → Suggest → Review → Approve → Execute → Report → Undo
That means the human stays in control while the AI handles the boring reasoning.
LazyShift is designed primarily as a local-first application because the files being organized can contain private personal information.
Code
GitHub
[https://github.com/nishant394ads-glitch/LazyShift-AI]
The repository contains the application source code, setup instructions, configuration, and documentation.
How I Built It
LazyShift AI is built around open-source AI and local inference rather than sending users' files to a closed cloud AI API.
The core AI layer uses:
- Ollama for local model execution
- Gemma 3 4B as the default local model
- FastAPI for the local backend
- SQLite for persistent application state
- A desktop-style command-center interface for the user experience
The architecture separates AI reasoning from filesystem execution.
The AI does not directly execute filesystem commands.
Instead, it produces structured proposals such as:
Move:
Downloads/invoice_001.pdf
To:
Documents/Invoices/invoice_001.pdf
Reason:
The filename and extracted document content indicate that this is an invoice.
Confidence:
94%
The user can then approve or reject that proposal.
Only approved actions reach the deterministic filesystem executor.
This creates a deliberate boundary:
AI proposes.
Human approves.
The application executes.
LazyShift has two operating modes:
âš¡ QuickShift
QuickShift is designed for work the user wants handled immediately.
The flow is:
Select Folder
↓
Scan Files
↓
Local AI Analysis
↓
Generate Action Plan
↓
Review
↓
Approve / Reject
↓
Execute
↓
Report
🌙 NightShift
NightShift is designed around the idea that the user should not have to sit there waiting for repetitive work.
Approved operations can enter a persistent background queue.
The queue stores job state so work can be recovered after interruptions instead of treating the entire operation as one fragile request.
This is particularly useful for larger batches where the user can queue work and get back to something more important.
Why Does Open Innovation Matter?
This project would be fundamentally different if I simply uploaded someone's files to a closed AI API.
The biggest reason is privacy.
A Downloads folder can contain:
- resumes
- invoices
- assignments
- screenshots
- documents
- personal photos
- financial information
- work files
Sending all of that to a remote AI service just to decide where files belong creates a completely unnecessary privacy trade-off.
With local inference, the AI reasoning can happen on the user's own machine.
That means:
Files stay local.
The model runs locally.
The organization happens locally.
Using an open-weight model also means the AI layer is replaceable.
Today the default model can be Gemma through Ollama.
Tomorrow, a user can experiment with another compatible open model without rebuilding the entire application around a proprietary API.
That flexibility is one of the strongest reasons I wanted the project to be built around open AI.
Open innovation also makes the project easier to experiment with.
The model, inference runtime, prompts, validation layer, and execution policy can all evolve independently.
The Lazy Payoff
This is the part I care about most.
Imagine downloading 50, 100, or 250 files and then spending the next hour deciding:
"Where does this PDF go?"
"Is this image a duplicate?"
"Which folder should this assignment belong to?"
"Why do I have five copies of this file?"
That's exactly the kind of work LazyShift is designed to eliminate.
Instead of manually processing every file, the user reviews an AI-generated plan and approves the useful actions.
The computer handles the repetitive execution.
The human handles the decisions.
For a folder containing hundreds of files, the potential payoff is not just a few clicks.
It is turning a tedious batch-processing task into a review workflow.
That's the entire philosophy behind LazyShift:
Do less repetitive work.
Keep control of the important decisions.
Let the computer handle the boring bits.
What's Next
LazyShift is intentionally starting with a focused problem rather than trying to become an entire operating system.
The next stage is making it much more capable at scale:
- smarter file classification
- stronger duplicate detection
- better document understanding
- more robust background execution
- richer reports
- safer rollback
- better model selection
- more powerful automation rules
- cross-platform support
- stronger observability
- production-grade deployment
- more integrations with developer and productivity workflows
The long-term vision is bigger than cleaning a Downloads folder.
I want LazyShift to become a local-first personal automation layer that quietly handles the repetitive digital work people keep postponing.
The user shouldn't have to babysit automation.
They should approve the plan, walk away, and come back to the result.
That's the lazy payoff. 🦥
Top comments (0)