DEV Community: Dinuka Ekanayake

I Built a Sloth That Organizes My Files While I Do Nothing 🦥 (With Local Open-Source AI)

Dinuka Ekanayake — Thu, 22 Oct 2026 20:47:14 +0000

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

What I Built

Every few weeks, my Downloads folder tells the same story: an invoice named document-final-2.pdf, meeting notes named notes.txt, an appointment reminder saved among work files, and a hundred small decisions I keep postponing.

I didn't need a smarter to-do list. I needed something that quietly finished one of those chores.

Meet SlothSort, a local-first AI file organizer. Drop supported files into an inbox and let a small open-weight model read what they're about. It suggests folders such as Finance, Work, Health, Learning and Personal—even when the filename gives away almost nothing.

But the interesting part isn't deciding which folder sounds right. It's knowing when not to decide.

SlothSort compares the similarity of each file against descriptions of my folders. If the best match is sufficiently strong and clearly better than the next-best match, it's eligible for sorting. If it's ambiguous, it waits for me. In the Streamlit interface, I can approve or edit suggestions in a table, then move files as one batch. Each move is recorded, and I can undo the last batch if I change my mind.

There's also an opt-in CLI watcher. With the model cached, it can sit on my laptop offline, wait for files to finish copying into the inbox, and file high-confidence documents as they arrive. It leaves uncertain files alone instead of guessing.

The result isn't an agent that makes grand promises. It's a tiny, deliberately boring assistant that helps future-me avoid the same chore again.

Demo

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

In the video I:

Create 11 synthetic files with unhelpful names like note_005.txt.
Run semantic matching with the local model and inspect suggestions and top-two gaps.
Show a low-confidence file that remains unchecked for review.
Approve a batch, show the created category folders, then undo it safely.
Restart in offline mode and show that the cached model still performs inference disconnected from the internet.

The exact outcome and evaluation numbers will be added after running the model on my PC.

Code

GitHub: https://github.com/DinukaEk/slothsort-week3

The project is MIT-licensed and includes the local UI, Python CLI, semantic engine, document readers, safe file-moving journal, synthetic dataset, an evaluation script, deterministic tests, and a GitHub Actions workflow.

How I Built It

AI core: sentence-transformers/all-MiniLM-L6-v2, an Apache-2.0 open-weight sentence embedding model, run locally through the open-source Sentence Transformers library.

The model does not generate prose. It maps the file text and each folder's natural-language description into a shared vector space. SlothSort measures cosine similarity and ranks candidate folders. The top score and its margin over second place determine whether to mark a suggestion as ready or needing review.

# Simplified from slothsort/engine.py
vectors = encoder.encode(category_prompts + document_texts)
ranked = sorted(
    ((folder, cosine(doc_vector, category_vector))
     for folder, category_vector in category_vectors),
    key=lambda pair: pair[1],
    reverse=True,
)
ready = ranked[0][1] >= min_similarity and (
    ranked[0][1] - ranked[1][1]
) >= min_margin

It is easy to confuse these similarities with confidence percentages. They aren't calibrated probabilities. That's why manual review and undo are essential to the design.

The files are handled by a deliberately narrow pipeline: extract limited plain text, embed locally, preview suggestions, move only selected files, write a SHA-256-backed audit entry, and provide a verified undo. File collisions get numbered names instead of overwriting other data. Watch mode checks stability between scans so it doesn't immediately move half-written files.

Test evidence: 32 deterministic unit tests passed in the initial build environment. These exercise the scoring logic, supported/unsafe file types, path validation, no-overwrite behavior, tamper detection, and undo. The unit tests mock embedding vectors; they do not prove production AI classification quality.

Real-model evaluation: [PASTE ACTUAL python scripts/evaluate.py --offline RESULT HERE]. The evaluator uses a small synthetic dataset, including one intentionally vague note. It also reports a transparent keyword baseline. It is a toy comparison, not a scientific or production benchmark.

Why Does Open Innovation Matter?

I didn't want to build an automatic organizer that demands a subscription to decide where notes.txt belongs.

With an open-weight model, the user controls the entire inference loop:

Privacy: the content is processed on the user's own machine. Local file contents aren't sent to a third-party AI endpoint.
Offline usefulness: after downloading the model once, sorting still works without Wi-Fi. I can demonstrate that by disconnecting my laptop during a scan.
Custom behavior: the five default folders are plain-text descriptions, not categories baked into an inaccessible hosted model. I can replace descriptions, adjust thresholds, or swap the model.
Predictable economics: there are no per-document or per-token API charges; running the model still has local CPU, memory, and electricity costs.

I haven't proved this small model is more accurate than every closed API. A larger hosted LLM might interpret unusual documents better. For this specific low-stakes, repetitive chore, however, keeping private content local and making every decision reversible matter more than buying maximum model intelligence.

Open innovation makes the shape of the product possible: an assistant I can inspect, modify, run without a provider account, and keep using when a service's pricing changes.

The Lazy Payoff

The payoff isn't “AI productivity” measured in vibes. It is fewer manual moves.

The project includes 11 synthetic demo files. [AFTER RUNNING: ADD NUMBER OF FILES AUTO-ELIGIBLE, NUMBER ACTUALLY MOVED, NUMBER SENT TO REVIEW, AND ANY REAL TIMING YOU RECORDED.]

For a transparent illustrative estimate, if a manual file decision takes 20 seconds, organizing 50 eligible files avoids up to 16 minutes 40 seconds of repetitive decisions before review time. That's a scenario, not a measured user study. A more honest success metric is the number of correct moves requiring no correction, which I'll track with the audit journal.

My favorite design choice is the boring one: uncertain files aren't silently moved. The sloth can work slowly, but it mustn't break anything while I'm not looking.

Thanks for participating in Hacktoberfest! 🦥

RemitMatch: The AI Bookkeeper That Never Sees Your Cloud

Dinuka Ekanayake — Thu, 15 Oct 2026 14:20:18 +0000

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

What I Built

A bank statement tells you that money arrived. It doesn't always tell you which invoice was paid.

Imagine you run a small bakery-supply business. Your accounting software has an unpaid invoice for Nimali Grocery Stores. Your bank CSV says:

BNK-002 | 2026-10-04 | LKR 42,750 | NIMALI STORES ONLINE TRANSFER

Another payment says CEFT SUNRISE BAKERY PAYMENT. Another includes an invoice number, but not the customer's full name. Two rows appear to be the same payment. One payment could belong to either of two hardware stores charging the same amount.

Each of these is simple for a human to check individually. Together they make reconciliation an irritating, repetitive job. And when the business is small, the person doing it is often the same person trying to sell, deliver, and support the product.

So I built RemitMatch: a local-first AI reconciliation desk for freelancers, small businesses, and bookkeepers.

You upload an open-invoice CSV and a bank-payment CSV. An open-weight model compares the meaning of payer references with business names, even when the strings are not identical. Deterministic rules verify amounts, invoice IDs, and dates. The interface ranks potential matches, explains why they were suggested, and flags duplicates or conflicts.

Importantly, the software never decides that money has paid an invoice on its own. The human must approve each candidate. Only explicitly approved, exact-amount, one-to-one matches appear in the export.

Who would pay?

My initial target customer is a small shop or accountant processing many direct bank transfers but not using an expensive enterprise reconciliation tool. The potential product is not “AI accounting.” It is a narrowly scoped time-saver that can be installed on the customer's own laptop, with revenue from setup, configuration, and support. This is a business hypothesis, not a claim that someone has paid me.

Demo

Local demo: https://drive.google.com/file/d/1NvHNomwMgcdKh6FW0Ptya9ztoc3iv1Sq/view?usp=sharing

You can also reproduce the flow yourself using the synthetic files in the repository:

python -m pip install -r requirements.txt
python scripts/download_model.py     # only needed once
python -m streamlit run app.py

Open http://127.0.0.1:8501 and select Run local AI matching. Examine the suggestions for BNK-002, the intentionally repeated BNK-008 and BNK-011, and the deliberately ambiguous hardware transfer BNK-009. Approve a valid exact-amount candidate, then export the reviewed CSV.

The demo data is fictional. The app doesn't send it to a hosted AI inference API.

Code

GitHub: https://github.com/DinukaEk/remitmatch

The project includes a Streamlit interface, auditable reconciliation code, one-time local model setup, synthetic sample CSVs, a baseline-evaluation script, and a core unit-test suite. The code is MIT-licensed; the embedding model is Apache-2.0 licensed.

For reviewers who want to see where the AI matters, start with matcher.py in the repository: its reconcile() function calls the embedding encoder, combines meaning-aware name similarity with finance-specific rules, and returns inspectable candidate evidence.

How I Built It

I intentionally didn't ask a language model to “act as an accountant.” In a money-related workflow, fluent language is not the same thing as a valid payment match.

Instead, RemitMatch has two distinct responsibilities:

1. Open-weight AI does the messy-text work.

I use sentence-transformers/all-MiniLM-L6-v2, an Apache-2.0-licensed embedding model, through the open-source Sentence Transformers library. It runs in the Python process on the user's machine. Payment references and customer names are turned into local sentence vectors, allowing semantic similarity to contribute to the candidate ranking.

2. Explicit code handles financial constraints.

Each candidate has an inspectable ranking formula:

38%  Local AI name similarity
22%  Lexical business-name similarity
23%  Amount similarity
12%  Exact invoice ID present in bank reference
 5%  Payment/invoice date proximity

Those weights are engineering heuristics, not statistical confidence percentages. Additional rules detect repeated bank rows, multiple deposits targeting one invoice, ambiguous candidates, and amount differences. Amounts use Python Decimal, not floating-point arithmetic. The user must manually approve; the export enforces an exact-amount, one-to-one link and is not connected to a live bank or ERP.

The included tests use an injectable deterministic test encoder so they can run without downloading model weights. A separate scripts/evaluate.py lets anyone compare real-model + rules with rules only on a small labeled synthetic dataset. I am deliberately not claiming real-world accuracy from a handful of invented rows.

The hardest design choice

It wasn't choosing the model. It was deciding what not to automate.

A semantic model can confidently associate a transfer with the wrong customer if two firms have similar names. A matching amount can also be a coincidence. So I chose a reviewer-first interface instead of automatically changing invoice states. The best side-hustle software isn't necessarily software that does everything. Sometimes the sellable feature is turning ten minutes of detective work into a short, inspectable checklist.

Why Does Open Innovation Matter?

For this product, local execution is the feature, not an implementation detail.

Consider the alternatives. A hosted AI service could absolutely help interpret the names — and might perform better on some difficult references. But using it may mean transmitting bank references and customer details to an external processor, budgeting for usage-based pricing, and accepting whatever model behavior and terms that provider chooses.

An open-weight embedding model changes the economics and the privacy boundary:

Private by design: after a one-time model download, inference can run with the internet disconnected. Sensitive CSV content stays within the user's local application rather than being submitted to a hosted AI model API.
Low marginal inference cost: there is no per-request model API charge; customers still pay for their computer, setup, and maintenance.
A modifiable system: the model can be exchanged for a domain-adapted alternative, and the scoring rules can be tuned for local bank-transfer vocabulary.
A stronger trust story: technical users can inspect the code, run the ablation, and see where both the model and accounting rules contributed. They can change or remove the system without depending on an external AI provider's pricing.

This is where open innovation worked better for the specific business constraints: not necessarily higher model accuracy, but local control over data and predictable infrastructure costs. I wouldn't promise that any open model always beats a closed one. I would promise that the user gets to decide where their sensitive data goes.

What I'd Validate Next

The prototype handles one-to-one, exact-amount deposits in LKR. It does not yet resolve partial payments, multiple-invoice transfers, refunds, or native Sinhala/Tamil bank references. Those are important limitations, not features to hide.

Next, I'd sit with a real business owner, use a consented or anonymized sample of their transfer descriptions, and measure three things: minutes spent matching deposits, how often the correct invoice appears among the top three candidates, and whether their preference for private local software is strong enough to justify a setup or support fee.

That would turn a hackathon prototype into a side hustle.

Built for Hacktoberfest 2026. The story here is a working MVP and a commercial hypothesis - not a fabricated customer testimonial or a claimed production deployment.

I Gave a Local AI One Job: Get Me Off the Screen 🌿

Dinuka Ekanayake — Sat, 10 Oct 2026 16:51:16 +0000

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

What I Built

What if the most useful AI app was one that helped you spend less time using apps?

As developers, students, and people who work in front of screens all day, we know the feeling: we need a break, so we reach for our phones. Then a few minutes of scrolling becomes half an hour.

I wanted to try something different.

Meet GrassQuest Local — a local-AI-powered outdoor adventure companion that turns a short break into a small mission worth stepping outside for.

Instead of recommending another feed to scroll through, it gives you something to do in the real world.

Here's how it works:

Choose your break. Pick how much time you have, your outdoor environment, what you want from the break, and whether you're going solo or with someone.
Generate your quest. Gemma 3 4B creates a personalized outdoor mission with five tasks and a 3×3 Outside Bingo board.
Switch to Pocket Mode. Take your mission outside, use the timer, and check off tasks as you complete them.
Finish the adventure. Track your progress without needing a complicated account, social feed, or cloud AI service.

The app also saves your mission and progress in the browser, so refreshing the page doesn't mean losing your adventure. Its offline-friendly design keeps the interface and an already-generated mission useful even when the backend isn't available, provided the app has been cached.

GrassQuest Local is for anyone who spends too much time at a desk and wants a simple, low-friction reason to take a walk, notice their surroundings, or enjoy a short break outdoors.

The idea is simple: AI should help you get into the world, not give you another reason to stare at a screen.

Demo

https://drive.google.com/file/d/14d9VpWXjwM6R6zTMc26aftUtiTiOVq7Q/view

The demo should show the actual workflow:

Selecting a duration, environment, and goal
Generating a mission with local Gemma
Entering Pocket Mode and using the timer
Completing tasks and Outside Bingo squares
Refreshing the page and restoring saved progress

A short screen recording is enough. The AI runs locally, so a localhost URL alone isn't a publicly accessible demo.

Code

https://github.com/DinukaEk/grassquest-local

GrassQuest Local is built as a local-first application rather than a cloud-AI wrapper.

To run it locally, install the .NET 10 SDK and Ollama, pull the model, and start the application:

ollama pull gemma3:4b
dotnet restore
dotnet run

Then open the local URL printed in the terminal.

The repository should include the source code, project setup instructions, and any configuration needed to run the app.

How I Built It

I built GrassQuest Local with a deliberately lightweight stack:

AI model: Gemma 3 4B, an open-weight model served locally through Ollama.
Backend: ASP.NET Core on .NET 10, responsible for communicating with the model and generating quests through the /api/quest endpoint.
Frontend: HTML, CSS, and vanilla JavaScript.
Pocket experience: A responsive interface, mission timer, task tracking, and interactive 3×3 bingo board.
Persistence and offline support: Browser storage preserves the active mission and progress; a service worker caches the app interface.

The user provides a few preferences, and the backend asks Gemma to generate a structured mission. The frontend turns that response into a usable outdoor experience rather than exposing a raw chat conversation.

I also included a local-AI status check, so the interface can distinguish a ready model from an unavailable backend.

The most important design decision was to make the AI generate the mission and then let the person get on with it. The model isn't meant to be the activity; it's the starting point for the activity.

Why Does Open Innovation Matter?

For this project, running an open-weight model locally isn't just a technical preference. It changes how the application can be used.

1. AI without a cloud AI dependency

Gemma runs through Ollama on my own computer. Quest generation doesn't require sending prompts to a third-party hosted AI API or obtaining a separate AI API key.

2. More control over the experience

I can inspect and change the prompts, adjust how quests are generated, and experiment with compatible models. I'm not locked into a single hosted AI provider's interface or pricing.

3. A more private, local-first design

The application doesn't need a cloud AI account to generate missions. In this local setup, quest preferences are processed by the backend on the same computer rather than sent to a third-party AI inference service.

4. A practical offline boundary

Once a mission is generated and saved, the cached interface and saved progress can continue to work offline. Generating a new AI mission still requires the backend and Ollama to be running, so I don't claim that model inference works offline on every device.

That distinction matters. Local AI doesn't magically remove every connectivity requirement, but it makes a useful, more self-contained experience possible without depending on a remote AI API.

Open innovation gives me the freedom to experiment with the model and architecture while keeping the project accessible to other developers who want to learn from it or extend it.

Prize Categories

Best Use of Gemma

Gemma 3 4B is the core mission-generation engine in GrassQuest Local. It transforms a user's available time and outdoor preferences into the tasks that drive the experience. The model isn't an optional add-on; without it, the personalized quest-generation feature wouldn't work as designed.

The goal of GrassQuest Local isn't to keep you engaged with another app.

It's to help you make a plan, put your phone away, and notice a little more of the world around you. 🌿

CareRelay Local: Private AI Care Handovers with Gemma 3

Dinuka Ekanayake — Sun, 04 Oct 2026 20:51:31 +0000

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

What I Built

I built CareRelay Local, a private AI-powered tool that turns rough caregiving notes into clear handover reports.

I built it for a friend who helps care for an older family member.

The problem is small, but very real.

Care notes are often written quickly throughout the day:

Breakfast at 8. Ate about half. Medicine after breakfast. Went outside around 10. Said knee was hurting a little. Lunch at 12:30. Doctor appointment tomorrow.

All of the information is there, but handing those notes to the next person means they still have to scan through everything and work out what matters.

CareRelay converts those rough notes into a structured handover with sections for:

Summary
Meals & Hydration
Medication Mentioned
Activities & Mobility
Observations
Rest
Appointments & Reminders
Information for the Next Caregiver

There are two output modes.

Next Caregiver produces a concise and practical handover.

Family Member communicates the same facts in warmer, simpler language.

Most importantly, CareRelay is deliberately a note-organization tool, not a medical assistant. It is instructed not to diagnose conditions, recommend treatments, invent medication names or dosages, or fill gaps with assumptions.

The goal is simple: take information someone has already written and make it easier to pass to the next person.

After building it, I gave it to a friend to try.

“I like how I can just write the notes normally without worrying about a format. The handover is much easier to read, and knowing the notes stay on the computer makes me more comfortable using it.”

Demo

Demo: https://drive.google.com/file/d/1I1g-li0_KS-S0qEij_abUX7vczf-8wcd/view?usp=sharing

The demo shows CareRelay taking unstructured notes, generating a caregiver handover, switching to the family-friendly version, and running through Gemma locally.

One of my favorite parts of the demo is disconnecting from the internet and generating another report.

It still works.

That is not a workaround; it is one of the reasons I designed the project this way.

Code

GitHub: https://github.com/DinukaEk/CareRelayLocal

The project is intentionally small.

The stack is:

ASP.NET Core / .NET 10
HTML
CSS
Vanilla JavaScript
Ollama
Gemma 3 4B

No cloud AI SDK is hidden behind the interface.

The browser sends the notes to my local ASP.NET backend. The backend sends them to Ollama on localhost, and Ollama runs Gemma 3 4B locally.

The basic path is:

Browser
   ↓
ASP.NET Core
   ↓
Ollama
   ↓
Gemma 3 4B
   ↓
Structured handover

How I Built It

I started with the AI layer rather than the UI.

First, I installed Ollama and downloaded gemma3:4b. I tested Gemma directly and then tested Ollama's local chat API.

Once local inference worked, I created a small ASP.NET Core API with a /api/handover endpoint.

The endpoint receives:

{
  "notes": "...",
  "audience": "caregiver",
  "model": "gemma3:4b"
}

The backend constructs a carefully constrained system prompt and passes the request to Ollama.

For this project, prompting was not mainly about making the model more creative. It was about making it less creative.

CareRelay tells Gemma to use only information explicitly contained in the supplied notes. It must preserve uncertainty, avoid diagnoses and treatment recommendations, and say Not mentioned. rather than filling in missing information.

For example, if the original note says:

Went outside around 10.

CareRelay should retain around 10, rather than silently changing it to an invented exact time such as 10:00 AM.

Likewise:

Medicine after breakfast.

must not suddenly become a medication name or dosage that the caregiver never wrote.

I use a low generation temperature because consistency matters more here than imaginative output.

I then added a small browser interface with:

a large natural-language notes field
Caregiver and Family output modes
a live local-AI status indicator
a character limit
loading and error states
Copy
Download

The status indicator calls a local backend endpoint which checks Ollama and verifies that Gemma is available.

When everything is ready, the interface displays:

100% Local AI - Gemma 3 4B is ready on this computer.

I also tested failure cases such as empty notes, missing information, ambiguous medication references, Ollama being unavailable, and potentially medical observations.

Why Does Open Innovation Matter?

This is the part of the project I care about most.

I could have built CareRelay around a closed cloud AI API. Technically, that might even have been easier.

But it would have changed an important property of the product.

Caregiving notes can contain information that people may not want sent to an external AI service.

With CareRelay, the model runs through Ollama on the same computer as the application. After the model is installed, the core AI workflow does not require an internet connection.

That gives this small project several useful properties.

Privacy and control

The raw care notes do not need to be sent to a cloud AI provider for inference.

Offline use

The application can generate handovers even when the laptop is disconnected from the internet.

No per-request AI bill

Generating another handover does not consume paid API credits.

Model freedom

The application is not fundamentally coupled to a single hosted AI vendor. I can experiment with a smaller model for weaker hardware or another compatible local model without rebuilding the product around a new external service.

Behavior I can control

Because the model and inference layer are under my control, I can iterate on the guardrails, generation parameters, and eventually even specialized model behavior.

For CareRelay, open-weight AI was not something I added to qualify for the challenge.

It influenced the actual product design.

The fact that it can run locally is one of the reasons the idea makes sense in the first place.

Prize Categories

Best Use of Gemma

CareRelay uses Gemma 3 4B as the AI at the core of the application, running locally through Ollama.