DEV Community: Sanketh Kumar

My 1B model renamed one file to another file's name — the fix was a provenance guard

Sanketh Kumar — Thu, 22 Oct 2026 05:36:41 +0000

My Downloads folder had 599 loose files in it — 101 PDFs, 79 spreadsheets, 129 images, and a folder full of things called img.png, fp.jpeg and 1762857107887_floop-plan-4.png. I had been closing that tab for months.

So for this week's Hacktoberfest challenge ("build something with open-source AI that rewards laziness") I wrote Tidy Sloth: a local file tidier that sorts a mess into folders and gives files names a human can actually read. Python standard library, Ollama, no cloud, no API key.

It works. But the interesting part isn't the sorting. It's that a 1-billion-parameter model confidently renamed one file to a completely different file's name, and the fix was not a better prompt.

The sloth is the architecture, not the mascot

Sloths are slow because speed costs energy. A file tidier has the same economics: most files are obvious, and asking a language model about them is wasted work.

So the pipeline spends tokens like they're calories:

file ──▶ rules ──▶ confident? ──yes──▶ done, 0 tokens
                       │
                       no
                       ▼
              local model (batched) ──▶ category + name
                       │
                       ▼
             Python validates, then moves

Extension rules — png → Images, xlsx → Data, zip → Archives.
Purpose rules beat extension — Invoice-March.pdf goes to Invoices, not Documents. Resume-Sanketh.pdf goes to Resumes.
A meaningful filename is enough — carprices.csv doesn't need a model to tell you it's data.

Only the leftovers go to llama3.2:1b: the timestamps, the img.pngs, the AC3.jsons.

On my real folder:


loose files	599
resolved by rules	453 (75.6%)
needed the model	146
model calls	13 (batches of 12)
wall time	14.2 min
estimated manual sorting	~80 min

Three quarters of the folder never touched the model. That's the whole trick.

Then the model lied

Small models are not editors. I knew that. What I didn't expect was how it failed.

I batch a dozen filenames per prompt and ask for a category and a cleaner name for each. The model returned exactly twelve answers, in order, in valid JSON. The count matched. The JSON was clean. And it had silently shifted the associations:

1786076876258_SoulTree-Brochure-1 (1).pdf  →  AC2.pdf
1786076876258_SoulTree-Brochure-1.pdf      →  Cost-Breakdown-6a61d9864a29092bf3f7159d-1.pdf
1748950125346_out-0.webp                   →  Aadhar-Card.webp
1764919659917_floop-plan-4.png             →  Copy-of-2024-07-TBC-Banner-Generic-2560x650-1-H1nZTAL.png

Every one of those names belongs to a different file in the same batch. The model didn't hallucinate a filename; it recycled a real one. Which is worse, because it looks plausible enough to ship.

My first fix was to stop trusting the model's self-reported index and match answers positionally. That didn't help — the count was already right, so there was nothing to catch. I also stripped echoed extensions, which fixed thing.pdf.pdf but not this.

The fix: a rename may only reuse the file's own words

The rule I settled on is boring and it works. A proposed name is accepted only if it is built from words that were already in the original filename.

def provenance_ok(proposed, original):
    """A rename may reorganise a file's own words. Never import another's."""
    if _tokens(proposed) & _tokens(original):
        return True
    a, b = _compact(proposed), _compact(original)
    return bool(a and b and (a in b or b in a))

SoulTree-Brochure-1.pdf → AC2.pdf shares zero tokens with the source, so it's rejected and the file keeps its own name. SoulaceNew2.png → soulace-new-2 shares everything, so it's accepted.

The model may reorganise a filename. It may never import one.

I put that and the other invariants into 15 unit tests, including the exact five bad pairs the model produced:

$ python3 -m unittest test_tidysloth
Ran 15 tests in 0.002s
OK

After the guard, the same 599-file run produced zero cross-row names and zero doubled extensions.

Two more rules that saved me

A name with no meaning is never given invented meaning. Given 01.csv, the model happily suggested project-proposal.csv. That's not tidying, that's fiction — and it's unfalsifiable, so you'd never notice it was wrong. Now 01.csv stays 01.csv. Only the category is decided by the model.

Deterministic noise removal beats model creativity. 1762857107887_floop-plan-4.png became floop-plan-4.png by stripping a leading 10+ digit message ID in Python — no tokens, no guessing, and it works whether or not Ollama is running. (With one edge case: 4446563839.pdf is all digits, so stripping the "ID" would leave nothing. The strip only applies if a real name survives.)

Sorting is destructive, so the defaults are cowards

plan changes nothing. It writes plan.json and an HTML report you read in the browser first.
apply moves files and writes a timestamped manifest.
undo replays that manifest in reverse and removes the empty folders it created.
There is no delete code path. Collisions get renamed, never overwritten.

I tested apply and undo on a 40-file copy: 40 files into 10 folders, then all 40 restored and the folders cleaned up. I have deliberately not run apply on my real Downloads folder yet — the plan is sitting there for review, which is exactly the workflow I want from a tool that touches my files.

What I'd tell someone reaching for a small model

Match by position, not by index. A model-supplied i field is another generated token, not a fact.
A correct count proves nothing. All twelve rows were there and correctly shaped; the mapping between rows and files was still corrupted.
Validate provenance, not just format. Schema validation would have passed every one of those bad renames.
Give the model the smallest job that still helps. Here, choosing between 15 folders. Names are mostly mechanical.

The 14 minutes is real, and it's slow — that's a 1B model on a laptop, and most of it is the model, not the rules. A bigger model would name better and cost more energy, which rather misses the point of a sloth.

Code: github.com/sank8-2/tidy-sloth — MIT, one file, no dependencies.

ollama pull llama3.2:1b
python3 tidysloth.py scan  ~/Downloads   # read-only summary
python3 tidysloth.py plan  ~/Downloads   # proposals + report
python3 tidysloth.py apply ~/Downloads/.tidysloth/plan.json
python3 tidysloth.py undo  ~/Downloads/.tidysloth/manifest-*.json

Or with no model at all, which still produces a complete and useful plan:

python3 tidysloth.py plan ~/Downloads --no-model

I built a listing writer that runs on the seller's own laptop — open-weight models, zero cloud

Sanketh Kumar — Mon, 19 Oct 2026 05:41:35 +0000

A reseller photographs forty things a week and then writes forty listings by hand. That is the tedious part of the side hustle — not the sourcing, not the shipping, the copy. Existing tools fix it by charging per listing and shipping your inventory to somebody else's cloud. I wanted to see how far a local open-weight model could get instead.

So I built Listing Studio: describe an item once and it writes a platform-shaped title, description, tags and price range for Etsy, eBay, Depop or Vinted — running entirely on your own machine.

🔗 Code: https://github.com/sank8-2/listing-studio (MIT)

Who would actually pay for this

The buyer is a one-person reseller: someone clearing a house, selling vintage finds, or running a small craft business. Their economics are small margins and large volume, and their two real costs with cloud listing tools are:

Per-listing pricing. When you list 200 items a month, a subscription or credit pack is a real line item. A local model costs electricity.
Handing over commercially sensitive data. Your stock list, your supplier names and your margins are the business. Uploading them to generate ad copy is a strange trade.

Neither of those is a technical argument. They are the reason a local tool exists at all.

How it works

flowchart LR
  A[item notes] --> B[Python: build prompt<br/>+ platform rules]
  B --> C[Ollama<br/>open-weight model]
  C --> D[extract JSON]
  D --> E[Python: clamp title,<br/>normalise tags, price band]
  E --> F[(SQLite history)]
  E --> G[listing + CSV export]

The pipeline has one deliberate rule: the model writes prose, Python decides every hard limit.

Etsy: 140-character title, 13 tags × 20 chars
eBay: 80-character title, no tags
Depop/Vinted: shorter titles, 5 tags

The model is never asked to count characters, because small models cannot count. finalise() clamps titles at a word boundary, lowercases and de-duplicates tags, caps their length, and reorders the price band if the model gets it backwards.

It is stdlib Python and one HTML file. No pip install, no build step, no account:

ollama pull llama3.2:1b
python3 app.py        # → http://localhost:8004

What it actually produced

Input:

item: vintage wooden birdhouse · category: garden decor · materials: pine wood · condition: good, some weathering · details: roof lifts off for cleaning; hanging hook on the back; 28 cm tall

First run, ~49 seconds on CPU, unedited:

Title: Vintage Weathered Pine Wood Birdhouse by Local Carpenter (56/140 chars)
Tags (12 returned, 13 allowed): garden decor · birdhouse · weathered pine wood · wooden birdhouse · hanging hook · pine wood birdhouse · local carpenter · handmade garden deco · garden accessory · wooden bird house · bird house for birds · decorative wooden (clipped to Etsy's 20-char tag limit mid-phrase — you can see the limit doing its work)
Price: GBP 25–40
Description: the model returned this one empty — so the deterministic fallback composer wrote it instead. That safety net is not a nice-to-have; it is the difference between an empty listing and a sellable one.

Then a second run on the identical input produced a shorter title (24 chars), only 8 tags, and a GBP 5–10 band — that is the screenshot above, and it is the honest headline: a 1B model is a drafting assistant, not an appraiser. Two runs, a 4× spread on price. The seller still sets the price. What the tool removes is the blank page, and it does that at zero marginal cost.

The part that did not work

I wanted the photo to be the input — point the camera at the item, get the listing. It is wired up, and it is not the default, for reasons worth sharing:

On this machine (Ollama 0.18.2, CPU-only) gemma3:1b and qwen2.5:1.5b both produced degenerate output — literal token loops like 1 1 1 1 1 even at temperature 0. Re-pulling did not help. llama3.2:1b worked fine, so the runtime is healthy and those blobs are not.
moondream:latest described a portrait correctly but returned symbol salad on real product photos, at 130–229 seconds per image.
With ~4 GB RAM free, holding a vision model and a text model at once made the model server return HTTP 500.

So I shipped text-first and left the photo field in place behind VISION_MODEL. The honest version of this project is less magical than the pitch, and it still saves the seller real time. I would rather write that down than show a screenshot of a vision pipeline I never got working reliably.

Why open matters here specifically

The privacy claim is structural, not a policy. There is no API key and no third-party endpoint; the app talks to 127.0.0.1:11434. You can verify it by pulling the network cable out and watching it keep working.
Model choice stays yours. WRITER_MODEL=llama3.1:8b is the entire upgrade path from "usable draft" to "genuinely good copy". No plan tier, no vendor deciding what you are allowed to run this month.
The price cannot be changed out from under you. A tool whose running cost is your own electricity does not get a pricing-page redesign that triples your bill.

For a business tool aimed at people with thin margins, those are not nice-to-haves. They are the product.

Try it

git clone https://github.com/sank8-2/listing-studio
cd listing-studio && ollama pull llama3.2:1b && python3 app.py

If you sell things on the side: I would genuinely like to know whether the output survives contact with a real listing, and where the copy falls apart. That feedback is more useful to me than a star.

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

Touch Grass: an offline terrace stargazing guide on open-weight Gemma

Sanketh Kumar — Sun, 11 Oct 2026 06:13:37 +0000

For the Touch Grass theme I built something that makes the screen the shortest part of the experience: a stargazing guide for Bengaluru terraces that tells you what's actually above the horizon right now — then sends you outside.

What I built

Terrace Sky Spotter — a web app (vanilla HTML/JS + zero-dependency Python server, stdlib only) in two halves:

Deterministic astronomy (code, not AI): 16 anchor stars from open catalogs (Yale Bright Star Catalogue / HYG, public domain) + real Julian-date → sidereal-time math computes altitude/azimuth for 12.97°N 77.59°E. No GPS, no network. Tap any constellation for its finder hint.
Open-weight narration (local Gemma 3 1B via Ollama): a "Narrate my tour" button produces the night's viewing order (setting constellations first), star-hop instructions, myths, and practical tips — plus per-constellation "how do I find it?" answers.

Since the first version I added the three features that make it a real observing tool:

🌙 Moon phase + washout filter — a synodic model computes illumination (validated against the Mar 3 2026 lunar eclipse); the naked-eye limit slides from ~mag 5.5 to ~mag 2.3 and faint targets get a 🌕 washed-out badge.
🪐 Planets — low-precision orbital math adds Venus, Mars, Jupiter and Saturn (verified by the Venus-elongation invariant). Saturn at 42° in the east is currently the best thing in the evening sky.
🕘 Time picker — plan any evening ahead, not just right now.
Live demo: run python3 app.py, open http://localhost:8002 (needs Ollama + gemma3:1b; tour narrates in ~30s on CPU)
Code: https://github.com/sank8-2/terrace-sky-spotter (MIT)

Who it's for

My roommate Nagaraj and me — terrace sessions in Bengaluru, phone brightness down, eyes up. I took it outside on a bright moonlit night and gazed for real: the moonlight washed out the faint stuff, exactly as the app's washout filter now predicts — the Pegasus square, Vega and Altair punched through while Pisces vanished. That field night is literally what the 🌕 badge is built from.

Why open matters here

Works with no signal. The catalog is bundled data and the model runs on-device. A closed-API guide dies the moment the bars disappear — exactly where you need it most: terraces, trails, villages.
Location stays yours. Stargazing needs your coordinates; here they never leave the laptop.
Free + swappable. One env var changes the model tomorrow.

The honest part: don't let the model invent the sky

Testing caught the key failure mode: asked about Cassiopeia while it was below the horizon, the model cheerfully described it as visible "high up". So the app never lets Gemma state positions — the deterministic math owns what's up and where, and the model only narrates how to find what code already verified. Below-horizon queries get an explicit "not up right now, here's when to catch it" path. Same architecture as my weekend entry's allergy guardrail: code enforces the safety property, the model supplies the words.

Also entering Best Use of Gemma — narrated end-to-end by open-weight gemma3:1b, running locally.

Build for a Friend: a local-first meal planner on open-weight Gemma

Sanketh Kumar — Mon, 05 Oct 2026 03:33:46 +0000

My roommate Nagaraj needed high-protein vegetarian food on a ₹2000/week budget — while strictly avoiding peanuts and lactose. So for the Build for a Friend theme, I built him a meal planner that runs entirely on his laptop: no accounts, no API keys, no cloud.

What I built

Friend Meal Planner — a web app (vanilla HTML/JS + a zero-dependency Python server, stdlib only) that generates a 7-day Indian meal plan with a grocery list and budget check. You fill in your friend's profile — diet, allergies, dislikes, budget — and the plan streams in, token by token.

Live demo: run python3 app.py and open http://localhost:8000 (needs Ollama + gemma3:1b pulled; ~40s per plan on CPU)
Code: https://github.com/sank8-2/friend-meal-planner (MIT)

Who it's for

Nagaraj, my roommate in Bengaluru. Hostel-style cooking, 30-minute recipes, ingredients from local markets, everything priced in ₹. I handed him the first plan — his verdict: "now that's cooking" (he also immediately asked for a recipe mode and non-veg mode, so that's next).

Why open matters here

Open-weight AI is what makes this project possible, not just cheaper:

Health data stays home. Allergies and eating habits are sensitive. With a local open-weight model, none of it touches a server anyone else controls — a closed API would mean shipping my friend's health profile to a third party on every generation.
Works offline. Hostel Wi-Fi dies constantly; the planner doesn't care.
Free forever. No per-token billing against a student budget.
Swappable. Gemma 3 1B today, something bigger tomorrow via one env var — no vendor lock-in.

The honest part: small models slip, so I built a guardrail

Testing caught something important: the 1B model kept suggesting paneer and yogurt to my lactose-allergic friend, despite explicit instructions. Rather than hide that, I added a deterministic allergy guardrail — every plan is scanned line-by-line against an allergen keyword map (lactose → milk, curd, paneer, ghee…) and an ⚠️ Allergy Check section is appended flagging risky dishes for review. Prompt engineering sets the intent; code enforces the safety property. That's the architecture I'd defend: never let a probabilistic model be the last word on food safety.

This also enters the Best Use of Gemma category — the whole app is Gemma-powered, running the open-weight gemma3:1b model locally through Ollama.

GoFr!?

Sanketh Kumar — Wed, 23 Oct 2024 05:06:09 +0000

Consider GoFr to be your own microservice helper. This framework, which is based on the robust Go language, handles the menial duties so you can concentrate on creating incredible applications.

Important attributes:

With built-in middleware, there's no need to start from scratch. GoFr saves you time and effort by including necessary middlewares like authentication, error handling, and logging.
Support for Datastores, File Systems, and Pub/Sub: Easily connect to your preferred file systems, messaging apps, and databases. You're insured by GoFr. Integrated Monitoring: Use the integrated tracing, monitoring, and logging features of GoFr to closely monitor your microservices.
Opinionated Approach: GoFr adheres to a precise and dependable framework that directs you toward best practices and steers clear of typical errors.

Why Opt for GoFr?

Quicker Development: Focus more on creating amazing features and less on boilerplate.
Enhanced Performance: GoFr creates high-performance microservices by utilizing Go's capabilities.
Enhanced Reliability: GoFr assists you in developing dependable and strong applications with integrated monitoring and error management.
Simplified Deployment: GoFr's Kubernetes design simplifies the deployment and management of your microservices.
Are you prepared to accelerate the development of microservices?

Try GoFr and see the difference for yourself.