DEV Community: Padma Lochini

SlothSort: A Local AI File Organizer That Believes Slow and Steady Wins

Padma Lochini — Sun, 25 Oct 2026 18:22:09 +0000

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

What I Built

🦥 SlothSort — A Local AI File Organizer

What if organizing files didn't require endless manual sorting?

SlothSort is a Python-based file organizer that explores how local AI can make everyday file management simpler. Instead of spending time sorting a cluttered folder, users can scan files, categorize them by extension, identify potential duplicates, and review organization suggestions before approving file moves.

I built SlothSort around one simple principle: let AI do the repetitive thinking, but keep the user in control.

✨ Key Features

📂 File Categorization: Organizes files into categories based on their extensions.
🤖 Local AI Suggestions: Uses Ollama with Qwen 2.5 1.5B to generate filename suggestions.
🔍 Duplicate Detection: Uses SHA-256 hashes to identify files with identical contents.
👀 Preview Before Action: Lets users review proposed file moves before applying them.
🛡️ User-Controlled Workflow: Keeps file organization deliberate rather than silently changing files.

The goal is to help students, developers, and anyone with cluttered folders spend less time organizing files manually.

Demo

GitHub Repository:

https://github.com/padmalochini27-del/SlothSort

The project runs locally through Streamlit.

Code

🧑‍💻 Explore the source code:

https://github.com/padmalochini27-del/SlothSort

The project is built with Python and Streamlit, with a locally running Ollama model for AI-powered suggestions.

Contributions, suggestions, and improvements are welcome!

How I Built It

I built SlothSort using Python, Streamlit, and Ollama.

The AI component uses Qwen 2.5 1.5B, an open-weight language model that can run locally through Ollama. The application communicates with Ollama's local API to request filename suggestions.

The workflow combines several components:

Scanning: Reads files from a user-selected folder.
Categorization: Groups files based on their extensions.
Duplicate Detection: Calculates SHA-256 hashes to compare file contents.
AI Assistance: Requests filename suggestions from the local language model.
Review and Organization: Presents proposed file moves for the user to review before applying them.

Streamlit provides the interface, while Python handles file processing and organization logic.

The idea was to combine deterministic programming for tasks such as categorization and hashing with AI assistance for tasks that benefit from language understanding.

Why Does Open Innovation Matter?

Open innovation makes experimentation more accessible.

Using an open-weight model with local inference allowed me to explore AI integration without depending on a paid, cloud-hosted language-model API for every suggestion.

It also gave me the opportunity to learn how model runtimes, Python applications, and local APIs work together.

For a file organizer, local inference offers an additional privacy advantage: model processing can happen on the user's computer instead of sending prompts to a remote AI service. The application's complete data flow still needs to be reviewed before handling sensitive files.

Most importantly, open tools make it easier for developers to inspect, experiment with, adapt, and improve the technology they use.

I want SlothSort to reflect that spirit: useful, approachable, and open to improvement.

The Lazy Payoff

The idea behind SlothSort is simple: spend less time sorting files and more time doing what matters.

Instead of manually checking every filename or searching for identical files by eye, users can use automated categorization and hash-based duplicate detection to reduce repetitive work.

I haven't measured a reliable time-saving figure yet, so I won't claim a specific number. My next step is to test SlothSort with realistic folders and compare the time required with manual organization.

Because sometimes the smartest productivity improvement is making a repetitive task a little less repetitive. 🦥

Prize Categories

Select only the partner prize categories that your project actually qualifies for, based on the official challenge rules.

Open-source AI / local inference — if this matches an eligible category in the challenge.

Final Thoughts

SlothSort is my exploration of the Slow and Steady theme: a small, practical application that combines local AI with predictable file-processing logic.

I believe AI tools should help people work smarter without taking away their control.

Slow and steady. One folder at a time. 🦥

I'd love to hear your suggestions for making SlothSort more useful!

I Built a Local AI Electricity Investigator — Because AI Should Explain the Numbers, Not Invent Them ⚡

Padma Lochini — Sun, 18 Oct 2026 17:43:34 +0000

I Built a Local AI Electricity Investigator — Because AI Should Explain the Numbers, Not Invent Them ⚡

What if a household electricity bill could become the starting point for an investigation, rather than just another amount to pay?

Imagine opening your electricity bill and noticing that your consumption seems unusually high. You know you use an air conditioner, a refrigerator, fans, lights, and a laptop. But which appliances contribute the most to your estimated energy use? How much might they cost over a month? And what should you investigate first?

A generic chatbot might give you a list of energy-saving tips. A calculator can give you a number.

I wanted to bring those two capabilities together: reliable calculations and understandable, locally generated explanations.

That idea became LeakLedger AI, my project for the Hacktoberfest 2026 Open-Source AI Challenge — Week 2: Side Hustle.

🔗 GitHub repository: https://github.com/padmalochini27-del/LeakLedgerAI

1. The problem isn't just calculating electricity consumption

Electricity consumption is measurable, but turning appliance information into a useful household decision can be confusing.

A user may know that an appliance consumes a certain number of watts, but watts alone do not tell the whole story. Usage duration matters. The electricity tariff matters. The number of days matters, too.

The basic calculation is straightforward:

Energy consumed (kWh) = Power (watts) × Usage hours ÷ 1,000

For a billing period, we multiply daily consumption by the number of days. Estimated cost is then calculated from energy consumption and the entered tariff.

But a useful tool should do more than display formulas. It should help people interpret the results, compare appliances, and identify sensible next steps.

That's the gap LeakLedger AI is designed to address.

2. Meet LeakLedger AI

LeakLedger AI is a local-first household electricity consumption investigation assistant built with Python, Streamlit, and Gemma running through Ollama.

Users can enter appliance details, estimate consumption and electricity costs over a selected period, compare appliance-level usage, and ask a local AI model to explain the results.

The application brings together five capabilities:

Calculate: Estimate energy consumption and cost from user-provided appliance data.
Compare: Break down estimated consumption by appliance.
Visualize: Present the results through dashboard metrics, a table, and a chart.
Explain: Use a locally running language model to generate a plain-language interpretation.
Investigate: Offer a checklist of practical steps to examine unexpectedly high consumption.

It also supports exporting the appliance breakdown to CSV for further analysis.

The goal is not to pretend that a simple dashboard can diagnose every electrical problem. It is to give users a clearer starting point for understanding their consumption.

3. The most important design decision: code calculates; AI explains

One of the most important lessons from building this project was deciding what the language model should—and should not—be responsible for.

Language models can produce fluent explanations, but fluency is not the same as numerical reliability. A response can sound convincing and still misstate a value, misunderstand a time period, or confuse watts with kilowatt-hours.

That matters when a user is trying to understand a bill.

So LeakLedger AI separates the two responsibilities.

Python is responsible for the calculations. Gemma is responsible for helping explain the results.

The application calculates consumption and estimated cost using explicit formulas. The AI receives the calculated information and is instructed to use those values when generating its explanation.

This separation is intentional: the model should not be treated as the source of truth for arithmetic.

It does not eliminate every possibility of an incorrect AI explanation. The model can still make mistakes, so its narrative should be checked against the displayed calculations.

I see this as an important principle for practical AI development: use generative AI where language and interpretation help, and deterministic code where the result must be calculated explicitly.

4. Why use open-weight AI locally?

For this project, I used Gemma 3 1B through Ollama.

That choice was not simply about adding an AI label to an application. Local inference changes how the application can be used.

More control over personal data

Household appliance information and consumption estimates can reveal patterns about someone's daily life.

With local inference, the AI explanation can be generated on the user's own computer rather than requiring a hosted language-model API. This reduces the need to send that information to an external AI provider.

Local inference alone does not guarantee complete privacy: the application, dependencies, operating system, and any future integrations still need to be considered.

Fewer dependencies on hosted AI services

A locally running model avoids per-request fees charged by a hosted AI API. The user still needs to download the model and software, and local computation consumes hardware resources and electricity.

For a small utility, that trade-off is worth exploring.

More freedom to experiment

An open-weight model can be run and evaluated locally. Developers can experiment with different models and change the surrounding application without making every AI interaction dependent on one hosted provider.

For me, the value of open innovation is not simply that a model is available. It is that developers have more control over where inference happens, how it is integrated, and how the application evolves.

The open model is part of the application's architecture—not just a feature mentioned in its description.

5. What happens inside the application?

The workflow is deliberately simple:

The user enters appliance power, usage duration, tariff, and the relevant number of days.
Python calculates estimated energy consumption and cost.
Streamlit displays the results, appliance breakdown, and chart.
The application passes the calculated information to the local Gemma model for an explanation.
The user reviews the explanation and uses the investigation checklist to decide what to examine next.

The main technologies are:

Python for calculation logic.
Streamlit for the interactive application.
Pandas for tabular data handling.
Ollama for running the language model locally.
Gemma 3 1B for AI-generated explanations.

This is a small application, but it demonstrates a design pattern I want to keep exploring: combine transparent computation with local generative AI, and give each component a clearly defined job.

6. A look at the working application

Dashboard overview

[
]

Appliance consumption breakdown

[
]

Local AI explanation

[
]

Explore the code: https://github.com/padmalochini27-del/LeakLedgerAI

The repository contains the application code and setup instructions. The project currently runs locally rather than being presented as a publicly hosted service.

7. Could this become a side hustle?

I built LeakLedger AI as a prototype, but I designed it around a problem that households and small organizations may find worth solving.

Potential users include:

Households that want a clearer picture of estimated appliance-level consumption.
Renters and students who want to understand how their usage affects electricity costs.
Small offices that want a simple way to explore appliance energy estimates.
Energy-conscious users who want to compare different usage scenarios before changing their habits.

A future version could let users save appliance profiles, compare estimates with actual electricity bills, and maintain consumption records over time.

A possible business model would be a low-cost desktop utility or a paid version with saved profiles, reports, and historical comparisons. That is a hypothesis to validate, not a claim that customers are already paying.

The next meaningful test would be to put the tool in front of actual users, observe how they use it, and find out whether the results help them make decisions they value enough to pay for.

I would also want to test the estimates against real bills and improve how the AI explanation stays grounded in the calculated data.

8. What LeakLedger AI does not claim to do

Trust is important for an application that discusses electricity usage.

LeakLedger AI estimates consumption using the values entered by the user. It does not directly read a smart meter, verify an electricity bill, detect a physical electrical fault, or guarantee that a particular appliance is responsible for high consumption.

The quality of the estimate depends on the accuracy of the inputs and the assumptions used.

Likewise, Gemma's explanation is not an electrical diagnosis. Users should verify numerical values against the dashboard and consult a qualified electrician when they suspect an electrical fault.

These limitations define the current scope of the project and the work that remains.

9. What I learned from building it

This project reinforced an idea that is easy to overlook when building AI applications: choosing a model is only one part of the design.

The surrounding software matters just as much.

A useful AI application needs a clear problem, dependable calculations, an appropriate role for the model, understandable results, and honest boundaries around what it can do.

Open-weight models and local inference make it possible to explore those ideas without making a hosted AI service the center of every interaction.

LeakLedger AI is an early prototype, not a finished energy-management platform. But it is a working step toward a more transparent, local-first approach to everyday utility software.

Your turn

If you were using LeakLedger AI, what would make it genuinely useful?

Would you want to compare estimated consumption against actual bills, track appliance usage over time, or receive more detailed recommendations for investigating high consumption?

I'd love to hear your thoughts, especially from developers building practical applications with open-weight models and local AI.

Built for Hacktoberfest 2026 — Open-Source AI Challenge, Week 2: Side Hustle.

🇯🇵 KaiwaBuddy: I Built a Local AI Japanese Conversation Partner for My Friend

Padma Lochini — Mon, 05 Oct 2026 17:15:15 +0000

What I Built

I built KaiwaBuddy, a local AI Japanese conversation partner designed for a friend who is learning beginner Japanese.

The problem was simple: learning vocabulary and grammar is one thing, but actually using them in conversation is much harder.

KaiwaBuddy helps a beginner practice Japanese by providing:

🇬🇧 English meaning
🧩 Grammar explanations
💡 Beginner-friendly explanations
✏️ Corrections for common mistakes
💬 Follow-up questions
🎯 Practice Mode
📚 Vocabulary Mode

The current version focuses on beginner N5 Japanese and Minna no Nihongo Lesson 1 concepts.

Demo

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

The demo shows:

Japanese sentence input
Grammar analysis
Mistake correction
Follow-up conversation
Practice Mode
Vocabulary Mode

Code

https://github.com/padmalochini27-del/KaiwaBuddy

How I Built It

KaiwaBuddy is built with:

Python
Streamlit
Ollama
Gemma 3 1B

The project uses a hybrid approach.

For known beginner Japanese vocabulary and grammar patterns, KaiwaBuddy uses a deterministic learning engine.

For sentences that are outside the known patterns, Gemma 3 1B is used as a fallback conversational model.

This was important because I found that relying entirely on a small language model for beginner Japanese correction could produce unreliable answers.

Instead, I used rules for the concepts I wanted to teach reliably and kept the local AI model for more open-ended interaction.

Why Does Open Innovation Matter?

The most important part of this project is that the AI can run locally.

KaiwaBuddy uses the open-weight Gemma 3 1B model through Ollama rather than depending entirely on a proprietary cloud AI API.

This matters for a language-learning application because conversations can contain personal information.

Local inference also gives developers more freedom to experiment, replace models, change prompts, and build specialized experiences without being completely tied to one proprietary AI provider.

For a beginner developer like me, working with an open model also made the AI system easier to understand as part of the application rather than treating an external API as a black box.

My Agent Session

Optional: Add your DevRelay agent session here if you have one.

Prize Categories

I am submitting KaiwaBuddy for the Hacktoberfest Weekend Challenge: Build for a Friend.

The project uses Gemma 3 1B through Ollama, with local inference as a core part of the application.

What I Learned

This project taught me that building an AI application is not only about calling an AI model.

The most useful system was a combination of deterministic logic and AI:

User → Learning Engine → Grammar/Vocabulary Analysis → Local AI Fallback → Structured Feedback

That approach made the application more reliable for the specific learning experience I wanted to create.