Have you ever opened your Downloads folder to find invoices mixed with screenshots, duplicate documents, videos, old notes, scripts, and files whose names tell you absolutely nothing?
You know it needs organizing. You keep postponing it. And when you finally start, you end up doing the same repetitive work again.
I built LazyDeskAI around a simple idea:
A good automation system should not redo work that has not changed—and it should never take control away from the user.
LazyDeskAI is a local-first file organizer that scans a folder, classifies files, detects exact duplicates, proposes an organization plan, and lets the user review changes before applying them.
This is my submission for the Hacktoberfest 2026 Open-Source AI Challenge — Week 3: Slow and Steady.
🎬 See LazyDeskAI in action
Watch the LazyDeskAI demo on YouTube
The demonstration uses a synthetic workspace rather than personal files. It covers file discovery, proposed organization, review, apply/undo history, and performance inspection.
🗂️ What does LazyDeskAI do?
The goal is not to move files as quickly as possible. It is to make file organization predictable, reviewable, and repeatable.
The current application includes:
- Local folder scanning: inspect a selected workspace without uploading its files to a remote service.
- File classification: route supported file types using deterministic extension rules, with an optional local Ollama integration in the codebase.
- Incremental processing: reuse cached results for unchanged files rather than processing every file from scratch.
- Exact duplicate detection: identify duplicate groups using file content hashes; detection does not automatically delete anything.
- Review before applying: inspect proposed destinations and approve or reject changes.
- Safety checks: validate proposed paths and recheck operations before execution.
- Apply history and Undo: review previous operations and attempt recovery when the original conditions still hold.
- Performance inspection: compare rule-only, cold-cache, and warm-cache runs using temporary benchmark data.
The important design choice is that finding a possible destination is different from being allowed to move a file. The application separates proposing, reviewing, approving, and applying changes.
🖥️ Inside the application
1. Start with a workspace
The workspace view lets the user select a local folder to inspect. Discovery is separate from applying changes, so scanning alone does not reorganize the directory.
2. Inspect the files
The file view lists discovered files and their types. The synthetic example contains mixed documents, images, videos, code, and unfamiliar extensions.
3. Review proposed destinations
LazyDeskAI creates a review plan showing the proposed destination for each file. In the captured run, the suggestions came from deterministic local extension rules because Ollama was unavailable.
g`]**
4. Inspect duplicates and activity
Exact duplicate detection helps identify files with matching content without silently choosing files to delete. The activity view records scans, plans, approvals, executions, and recovery actions.
5. Confirm before changing files
The Apply confirmation lists the intended moves. The user can inspect the plan before proceeding. This is important because a file organizer should not make surprising changes just because it can.
6. Review the result and recovery history
The synthetic demonstration includes an Apply/Undo cycle: six file operations were applied and then undone. Undo is deliberately described as best-effort recovery, not a guarantee. If a file has changed or its original location is occupied, recovery can be refused rather than overwriting unexpected data.
🦥 Slow and Steady: why incremental processing matters
A naive organizer can repeat the same classification work every time a folder is scanned.
LazyDeskAI maintains a local processing cache so unchanged files can reuse previous results. When relevant file metadata or content changes, the application can invalidate cached results and process the affected file again.
That leads to a useful engineering distinction:
- Correctness: produce the same classification results for the same inputs.
- Incremental behavior: recognize unchanged inputs and reuse cached results.
- Performance: measure whether that reuse actually reduces the work that matters.
The third point matters. A cache is not automatically faster than a simple deterministic rule lookup. The real value depends on the cost of the work being cached.
📊 What did the benchmark show?
I ran the application's performance inspection against two synthetic workloads. These are measurements from one machine and one run, not universal performance guarantees.
| Synthetic workload | Rule-only | Cold cache | Warm cache |
|---|---|---|---|
| 22-file workspace | 2.498 ms | 11.871 ms | 8.102 ms |
| 200-file workspace | 13.099 ms | 70.240 ms | 48.678 ms |
The warm run reported 22/22 cache hits for the smaller workspace and 200/200 cache hits for the larger workload. The benchmark also reported identical results across the compared phases.
But there is an important catch: the warm-cache timings were slower than the rule-only baseline in both cases.
Why? These runs use deterministic extension rules, which are already cheap. Cache lookup and validation add overhead, and the benchmark made zero model requests. It therefore does not demonstrate that caching saves model-inference time.
That is a limitation, not something I want to hide. A useful next experiment is to measure repeated classification with a real local model, count actual inference requests, and compare the total cost while checking that results remain correct.
[Insert screenshot: 08-benchmark-comparison.png]
🔓 Why local-first and open innovation matter
Files can contain personal, academic, professional, or sensitive information. A file organizer should not require sending that information to a third-party server just to determine where it belongs.
LazyDeskAI is designed around local processing:
- The selected workspace stays on the user's machine.
- File discovery and organization are performed locally.
- SQLite stores processing and activity state locally.
- An optional Ollama integration provides a path to local model inference when a compatible model is installed.
- The application does not automatically download a model when one is unavailable.
Open innovation matters because developers can inspect the implementation, change the rules, integrate a compatible model, and experiment with different approaches instead of being locked into a remote service.
There is also an important distinction between design and demonstrated behavior: the screenshots in this submission were captured while Ollama was unavailable. The shown suggestions therefore come from deterministic extension rules. They demonstrate the current review-and-organization workflow, not a successful live model-inference run.
I want the model-powered path to be evaluated with the same transparency as the deterministic path: real requests, measured latency, validated output, and clear fallbacks.
🛡️ Safety is part of the feature
File automation can cause real inconvenience if it moves the wrong document or handles a conflict badly. For that reason, LazyDeskAI is designed around several safeguards:
- Proposed operations can be reviewed before application.
- Destination paths are validated.
- The user explicitly approves changes.
- Execution checks whether operations are still safe to perform.
- Exact duplicate detection does not automatically delete files.
- Undo checks whether recovery is safe and may refuse when conditions have changed.
Undo is not a substitute for a backup. It is a best-effort recovery mechanism, and the application says so directly.
The demo's Apply/Undo cycle was performed against disposable synthetic data, not a personal Downloads folder.
🧰 How it is built
The project uses a small full-stack architecture:
- Frontend: React, TypeScript, and Vite.
- Backend: Python and FastAPI.
- Local persistence: SQLite.
- Optional model integration: Ollama for local inference when available.
- Testing and performance inspection: automated tests and synthetic benchmark workloads.
The backend is responsible for validating and executing file operations; the frontend provides the workspace, review queue, activity history, duplicate view, and performance inspection.
🚧 What still needs work?
This is an active project, not a claim that every part is finished.
The current demonstration exposes several next steps:
- Measure real local-model inference and the model requests avoided by incremental processing.
- Compare cache overhead against the actual cost of model-backed classification.
- Test broader file collections and edge cases across operating systems.
- Improve presentation of successful operations and make long review lists easier to inspect.
- Expand recovery and conflict testing while preserving the rule that unexpected changes must not be overwritten.
I would rather document these gaps than present a benchmark or model integration as more mature than the evidence supports.
🌱 Try it and explore the code
- GitHub repository: https://github.com/shrey04kaitke-sys/LazyDeskAI
- Demo video: https://youtu.be/ZFXDwcewOLI
If you explore the project, I would especially appreciate feedback on safe file-operation design, cache invalidation, and how to benchmark local-model workloads meaningfully.
Final thought
The point of “Slow and Steady” is not to make every operation faster at any cost.
It is to avoid unnecessary repeated work, make changes deliberately, and keep the user in control.
Sometimes the best automation is the one that remembers what it has already done—and knows when to stop.
Top comments (0)