DEV Community: Arin Dewangan

SlothSort: I taught an open-source AI to clean my Downloads folder so I'd never have to 🦥

Arin Dewangan — Tue, 20 Oct 2026 10:17:56 +0000

My Downloads folder is where files go to be forgotten. Installers from 2024. report-final(1).pdf sitting next to report-final.pdf. Screenshots of things I no longer remember screenshotting. Every few months I open the folder, sigh, and close it again — the digital equivalent of shoving everything into a closet before guests arrive.

So I built SlothSort — a file tidier that does the procrastinated chore for you, using TabPFN, the open-source tabular foundation model, running entirely on your own CPU. Point it at a folder listing and it triages every file into KEEP / ARCHIVE / DELETE with a confidence score and a plain-English reason — the 24-file demo folder scores in a single ~9-second forward pass — then archives or deletes in one click, always with undo, because laziness should never be irreversible.

🔗 Live demo: https://arindewangan.github.io/slothsort/demo/ (precomputed TabPFN outputs on a simulated folder, clearly labeled — works with zero backend)
💻 Repo: https://github.com/arindewangan/slothsort

What it does

Open the dashboard and SlothSort has already triaged a simulated ~/Downloads folder — 24 files, the usual suspects:

ChromeSetup.exe (untouched 400 days) → DELETE — "It's an installer — you can re-download it any time"
report-final(1).pdf → DELETE — "Suspicious name — smells like a duplicate"
trip-goa-2024.mp4 (1.8 GB, unopened 480 days) → ARCHIVE — "Cold media file worth keeping, not worth the clutter"
report-final.pdf (opened 3 days ago) → KEEP — "still in active use"

The dashboard shows a verdict badge, a confidence bar, and the reasons for every file. One click archives or deletes (simulated in the demo, with full undo), and a stats row totals what you'd reclaim. There's also a "score your own file metadata" box — paste a filename, size, and dates, and get a verdict. Note the deliberate design choice: you paste metadata, never the file. SlothSort never reads file contents, because it never needs to.

How it's built

A Python/Flask backend with a vanilla JS frontend. The pipeline:

data/build_dataset.py generates 6,000 simulated file records locally (seeded RNG, reproducible) — filename clutter signals, sizes, ages, access gaps — labeled KEEP/ARCHIVE/DELETE by common-sense "digital hoarding" heuristics with ~8% label noise, so the model has to generalize instead of memorizing a rule list.
At request time, TabPFN classifies each file in-context on a seeded, class-stratified 999-row context (333 per class) — one forward pass per batch, local CPU, no gradient training, no API key. Low-confidence calls (<55%) are flagged "review manually" rather than auto-acted on.
recommender.py turns the winning class into an action plus deterministic reasons drawn from the file's own metadata. The model decides the class; the file explains itself.
The frontend is vanilla HTML/CSS/JS. The GitHub Pages demo bakes real precomputed TabPFN outputs (via demo/build_demo.py, stamped with the build date) so it works with zero backend.

The honest hard parts

Getting TabPFN running at all. The build machine's /tmp is a 512MB tmpfs, and the default torch wheel (~800MB) died mid-unpack with "No space left on device" — on a disk with gigabytes free. The fix was a CPU-only torch install with TMPDIR pointed at real disk, plus --ignore-installed to dodge a Debian-pinned typing_extensions that pip refused to touch. Then the real surprise: current TabPFN (v9.x) requires a Prior Labs account + license acceptance + API token just to download weights — a non-starter for a "no accounts, no keys" project. So SlothSort runs TabPFN 2.2.1, the last version with freely downloadable open weights. None of this is in any tutorial; all of it is the actual tax of "runs on your CPU."

Making the synthetic data non-trivial. My first label rules were so clean a decision stump could ace them — which would make TabPFN decorative, not load-bearing. The 8% label noise and overlapping rules (a big cold media file that's also recently opened, a cluttered name on a warm document) exist specifically so the classifier has to weigh evidence like a real triage decision.

Refusing to fake explanations. It would have been easy to dress up rule outputs as "the model's reasoning." Instead the architecture is explicit: TabPFN outputs class probabilities; the reasons come from the file's metadata. The UI tooltips say exactly that. An explanation you can't trace to something real is marketing, not AI.

What I'm proud of

Real open-source-AI core: TabPFN inference on real (simulated, disclosed) data, reproducible end-to-end from the repo — no API keys, no proprietary models, no fake "AI" labels. If TabPFN isn't installed, the app runs a labeled fallback and says "NOT TabPFN" on every output.
Privacy as architecture, not a bullet point: metadata-only features mean the file list never needs to leave the machine. That's the whole reason open weights matter here (more below).
Laziness with a safety net: every destructive action is one click with undo — the demo keeps a full undo stack, and the design assumes you'll never double-check the AI.
An honest demo: precomputed vs. live is labeled, simulated data is labeled, the build date is stamped, low-confidence verdicts ask for review.

What I learned

TabPFN does 3-class in-context learning out of the box with no architecture changes — the same TabPFNClassifier that did binary risk scoring in my Week 2 entry (LatePay) handled KEEP/ARCHIVE/DELETE with just a stratified context. The technical takeaway: for small tabular problems, data plumbing beats model choice — the interesting work was all in the label design and the feature encoding (log-size, clutter signals), not the classifier. And the process takeaway: labeling your demo "simulated" costs nothing and buys everything. Nobody trusts a file-deleting AI that won't show its work.

What's next

Real folder scanning: a pathlib walker that reads actual ~/Downloads metadata into the same feature pipeline, with the undo log persisted to disk.
Learn from overrides: when you undo the AI's verdict, feed the correction back as context — TabPFN's in-context learning makes this nearly free.
Per-user thresholds: let the chronically anxious set "never auto-delete above 90% confidence."
Scheduled sloth mode: a weekly background pass that quietly archives the cold stuff and reports what it did — maximum laziness, minimum surprise.

How it uses open-source AI

SlothSort's decision engine is TabPFN (Apache 2.0, Prior Labs) — an open-source tabular foundation model. I generate a simulated file-history dataset locally with a seeded script, and TabPFN classifies each file's metadata vector in-context on the local CPU at inference time. No proprietary models or API keys are involved anywhere in the pipeline — which is exactly why this product can exist: a file tidier that phones your file list to a cloud API is a privacy non-starter, but an open-weight model on your own machine never sends anything anywhere. It works offline, it costs nothing, and nobody's file list is the product.

Built with: Python, Flask, TabPFN (open-source), JavaScript. License: MIT.

LatePay — know which invoices will ghost you, before they do 💸

Arin Dewangan — Mon, 19 Oct 2026 02:44:37 +0000

LatePay — know which invoices will ghost you, before they do 💸

DEV Hacktoberfest AI Challenge — Week 2: Side Hustle.

Every freelancer knows the feeling: the work is delivered, the invoice is sent, and then… silence. Cash flow is the oxygen of a side hustle, and one late payer can choke it for a month.

So I built LatePay — a late-payment risk predictor that scores every outstanding invoice with TabPFN, the open-source tabular foundation model, and tells you what to do about it: chase now, ask for partial upfront, send a reminder, or relax.

🔗 Live demo: https://arindewangan.github.io/latepay/demo/ (precomputed TabPFN outputs, clearly labeled simulated)
💻 Repo: https://github.com/arindewangan/latepay

What it does

Score an invoice — enter the amount, client history (tenure, prior late rate, average days to pay), contract strength, and payment terms. TabPFN returns P(paid > 30 days past terms) as a risk band: HIGH / MEDIUM / ELEVATED / LOW.
Get one clear action — HIGH → chase now and pause further billable work; MEDIUM → require 50% upfront before the next milestone; ELEVATED → send a polite nudge on the due date; LOW → normal terms.
Batch-score a CSV — upload your invoice list and download a scored risk report with a recommendation per row. Missing history columns fall back to an honest new-client baseline.
Explore offline — the static demo ships 4 real client profiles plus a what-if grid (late rate × contract × amount), every cell a real precomputed TabPFN prediction, build-dated and labeled simulated.

How it's built

A Python/Flask backend with a vanilla HTML/CSS/JS frontend. The pipeline:

data/build_dataset.py generates a SIMULATED invoice-history dataset (4,000 invoices, seeded RNG) with 12 features per invoice — amount, client tenure, prior invoice count, prior late rate, average days to pay, contract strength, payment terms, client size, international flag, invoice month.
At request time, TabPFNClassifier(device="cpu") — fitted in-context on that dataset in risk.py — predicts the late-payment probability for the new invoice. No gradient training, no API key, no proprietary models.
The GitHub Pages demo bakes real precomputed TabPFN outputs via demo/build_demo.py (build date stamped on the page) so it works with zero backend.

The honest hard parts

TabPFN's license gate. The latest tabpfn releases (≥2.1) demand interactive license acceptance at install time — a non-starter for a fully automated pipeline. So requirements.txt pins tabpfn==2.0.6 — the same version that proved itself in our Week 1 build (Frostwise). Same proven path, zero new surprises.

Attention is O(n²) on CPU. Our dataset has 4,000 simulated invoices, but fitting TabPFN in-context on all 4,000 rows made per-request inference painfully slow on CPU. The trade-off, documented in risk.py: a seeded, label-stratified 1,000-row subsample as the inference context — per-request scoring stays in the seconds range. The full 4,000-row CSV still ships as the data artifact; the demo's precomputed grid used the same setup.

Synthetic data means synthetic confidence. The model learned real, sensible patterns — a clean client scores 5.0% late risk, a serial late-payer 63.4% — but it has never seen a real invoice. That's why every demo screenshot, every CSV row, every UI badge says SIMULATED, and the README states plainly: these are risk estimates for prioritising follow-ups, not financial advice, not a credit score.

What I'm proud of

Real open-source-AI core: local TabPFN inference on real (simulated) tabular data, reproducible end-to-end from the repo — no API keys, no proprietary models, no fake "AI" labels.
An honest demo: every number on the static page is a real precomputed TabPFN prediction, build-dated and labeled SIMULATED.
CSV batch scoring that degrades gracefully — missing history columns fall back to a new-client baseline instead of erroring.
A UI a non-technical freelancer can actually use: one form, one gauge, one action.

What I learned

Technical: TabPFN genuinely collapses tabular ML to a one-liner — fit in-context, no training loop, no feature engineering — and the risk separation it produced was immediately sensible (5.0% LOW vs 63.4% HIGH). For a prioritisation tool like this, calibration across bands matters far more than any single accuracy number.

Process: honesty is a feature, not a tax. My first banner render shipped with an invented "94.2% accuracy" line in the artwork — I threw it out and regenerated it clean. Labeling simulated data visibly, pinning versions honestly, documenting the 1000-row trade-off: the write-up is stronger for every one of those, and this challenge weights writing most heavily.

What's next

Let freelancers import real invoice history (Stripe/Invoicely exports) so the context set is their own data, not simulated.
Per-client portfolio view: total at-risk revenue across all outstanding invoices.
Email reminder templates wired to the ELEVATED band's nudge schedule.

How it uses open-source AI

LatePay's risk core is TabPFN v2 (tabpfn, an open-source tabular foundation model). We generate a simulated invoice-history dataset locally, and TabPFN fits in-context on it and predicts P(payment > 30 days past terms) per invoice at inference time — all on local CPU. No proprietary models or API keys are involved anywhere in the pipeline.

Built with: Python, Flask, TabPFN (open-source), JavaScript. License: MIT.

Frostwise — know your frost dates, plant with confidence

Arin Dewangan — Thu, 08 Oct 2026 02:54:03 +0000

Frostwise — know your frost dates, plant with confidence

DEV Hacktoberfest AI Challenge — Week 1: Touch Grass.

Every gardener knows the heartbreak: a surprise late frost wipes out weeks of seedlings overnight. Frost dates are the single most important number in gardening, yet most people guess them from a vague zone map or a neighbor's memory.

So I built Frostwise — a hyperlocal garden planner that computes your frost dates from real climate history using TabPFN, the open-source tabular foundation model — then turns them into a planting plan you can actually follow.

Live demo: https://arindewangan.github.io/frostwise/demo/ (real precomputed TabPFN predictions, clearly labeled)
Repo: https://github.com/arindewangan/frostwise
Video: https://youtu.be/ZpVZ8wFglvg

What it does

Type any city — or tap a sample like Chicago, Berlin, Bengaluru, Sydney, Tokyo — and Frostwise:

pulls 20 years of daily minimum temperatures for your location from the Open-Meteo archive (ERA5 reanalysis),
runs TabPFN to predict whether your location gets frost at all, and if so, your last spring frost and first autumn frost dates,
generates a planting calendar for 12 common crops (tomatoes, peppers, kale, garlic, spinach…), with sow windows anchored to your predicted frost dates and honest notes per crop.

No frost where you live? It tells you that too — the model learned it from the data, and you get a year-round growing calendar instead.

How it's built

A Python/Flask backend with a clean single-page frontend. The pipeline:

data/build_dataset.py fetches 2005–2024 daily minimums for 80 stratified global locations and derives per-location labels — median first/last frost day-of-year (frost = daily min ≤ 0°C) — plus 17 climate features.
At request time, TabPFN performs the whole prediction in-context: a classifier for frost/no-frost, two regressors for the dates — a single forward pass per model, no gradient training.
The frontend is vanilla HTML/CSS/JS. The GitHub Pages demo bakes real precomputed TabPFN predictions (labeled with the build date) so it works without a backend.

The honest hard parts

The real challenge was making the AI genuine instead of decorative. A frost date isn't in any API — it has to be derived, so I built the entire label pipeline from raw reanalysis data and had to get the day-of-year statistics right across hemispheres (autumn frost in Sydney falls in a different part of the year than in Berlin). Tropical locations needed genuine "no frost" handling rather than a hardcoded hack — hence the two-stage classifier → regressor design. The other fight was practical: PyTorch's download servers kept timing out, so the environment setup needed patient retries and mirror fallbacks.

What I'm proud of

A real open-source-AI core: TabPFN inference on real ERA5 data, reproducible end-to-end from the repo — no API keys, no proprietary models, no fake "AI" labels.
The two-stage design (frost/no-frost classifier → date regressors) that handles everything from Chicago winters to Bengaluru's frost-free climate without special cases.
A static demo that stays honest: every number is a genuine precomputed inference, clearly labeled as such.
A UI clean enough that a non-technical gardener can actually use it.

What I learned

TabPFN's in-context learning is remarkably well suited to small, high-signal tabular problems — 80 locations were enough to learn a physically sensible climate→frost mapping. I also learned that the unglamorous half of "AI projects" is data plumbing: deriving trustworthy labels from raw observations mattered more than any model choice. And that honesty in demos (labeling precomputed vs live) costs nothing and buys trust.

What's next

Per-crop frost-damage risk (not just dates), user-saved locations with frost alerts, Southern-Hemisphere season handling in the calendar copy, and a TabPFN uncertainty readout (prediction intervals) so gardeners see the confidence behind each date.

How it uses open-source AI

Frostwise's prediction engine is TabPFN (Apache-2.0, PriorLabs) — an open-source tabular foundation model that performs supervised learning in a single forward pass. We derive frost-date labels from 20 years of open ERA5 reanalysis data (via Open-Meteo's free archive), and TabPFN learns the climate→frost-date mapping in-context at inference time: a classifier predicts frost occurrence and two regressors predict first/last frost day-of-year. No proprietary models or API keys are involved anywhere in the pipeline.

Built with: Python, Flask, TabPFN (open-source), Open-Meteo / ERA5, JavaScript. License: MIT.