DEV Community: Aditya Patkar

Sloth Valet: a local AI that tidies my Downloads overnight (and can undo everything)

Aditya Patkar — Sat, 24 Oct 2026 13:49:17 +0000

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

What I Built

Sloth Valet is a small Linux tool that tidies a messy Downloads folder while I sleep. It waits until files have been left alone for a while, asks a small open-weight model running on my own machine what each file is, then renames it cleanly and moves it into a sorted folder tree. In the morning there's a short report waiting.

The effort it saves is the one I keep dodging: opening Downloads, seeing 200 files called final_v2 (3).pdf, and closing the window again. Anyone with a permanently messy folder gets to be a little lazier.

Because it runs unattended, I designed it around not breaking anything:

Dry-run is the default. Nothing moves until you pass --apply.
It waits. Files must sit untouched for a settle period, and partial downloads are skipped.
It never guesses. Low confidence, bad JSON, a timeout, or a missing model sends the file to _review/ or leaves it alone.
Everything is undoable. Every move is journaled in SQLite with a SHA-256 hash, and valet undo --last puts files back.
It never deletes or overwrites. Name collisions get a suffix.

Code

Virtualord / sloth-valet

Sloth Valet

A slow, private file valet for a messy downloads folder.

Sloth Valet waits until files have settled, asks a small local open-weight model (through Ollama) for a category and a clean filename, and moves the files into a tidy destination tree. It runs offline, journals every move, writes a morning report, and prefers leaving a file alone over guessing.

Built for Hacktoberfest 2026: Slow and Steady — open-weight AI that rewards patience, privacy, and a recoverable filesystem.

Status

Version 0.1.0. The full pipeline is implemented: validated configuration, read-only scanning, bounded extraction, local classification, planning, journaled moves, review routing, crash reconciliation, undo, Markdown reports, optional desktop notifications a systemd user timer, and a model-comparison benchmark harness.

The default test suite uses mocked HTTP and fake classifiers. It does not need a network connection, a running Ollama, a real systemd session, or a notification daemon.

Why this shape

Offline…

View on GitHub

It's about 4,700 lines of plain Python (no agent framework), MIT licensed, with mocked-HTTP tests so CI needs no Ollama. Setup is ./install.sh, then valet config init, then valet run for a dry run. scripts/demo.sh <model-name> runs the whole flow against generated fixtures in a temp folder, so you can try it without touching real files.

How I Built It

Open pieces

Model: open-weight models served locally through Ollama. The code never assumes a model name. You put one in the config, or pass several to valet bench --models.
Harness: no LangChain, no framework. The agent loop is plain code: scan, extract, classify, plan, apply, report.
Building it: I built it phase by phase with opencode, driven by an AGENTS.md of safety rules, with a branch and checks per phase.

Pipeline

Scan watch folders. Protected paths, ignore globs, symlinks, size limits, and a settle check all run before any file is opened.
Extract a bounded snippet of text (text, code, PDF, DOCX). Images and unknown binaries contribute metadata only.
Classify through Ollama with a strict JSON schema. The category must come from an allowlist, and filenames are sanitized.
Plan collision-free destinations. Obvious extensions like .deb or .iso skip the model entirely, which saves compute.
Apply by journaling pending, revalidating the file, moving it, then marking done. A crash is reconciled on the next run.
Report in Markdown, with an optional count-only desktop notification.

It runs from a systemd user timer (valet install-timer --time 03:00) at low CPU and I/O priority. The timer is persistent, so a run missed while the laptop was asleep happens after it wakes.

Treating files as hostile. A downloaded file can contain text like "ignore previous instructions". The model only picks from an allowlisted category and returns JSON, and nothing it outputs is executed or used raw in a path. There's a test for exactly that case.

Why Does Open Innovation Matter?

Privacy was the whole point. Downloads are full of marksheets, ID scans, offer letters, and invoices. With a local model, file text only ever goes to localhost:11434. There's no telemetry and no hosted API. The only HTTP module is ollama.py, and an architecture test enforces that boundary.

It costs nothing to run. No per-token bill means it can scan every night without me thinking about cost.

Swapping models was easy, and that mattered. Because the model is just a config value, I could benchmark it properly. I ran the same 50 labeled synthetic files through two tiny models on a CPU-only machine (8 cores, 7.6 GiB RAM; Ollama couldn't use my GTX 1050, so this is the no-GPU case):

Model	Valid JSON	Category accuracy	Mean latency	Peak RSS
`qwen2.5:0.5b`	100%	12%	936 ms	661 MiB
`llama3.2:1b`	100%	80%	1,490 ms	789 MiB

The surprise is that both models produced perfectly valid JSON, and one of them was still almost always wrong. A model that looks fine can quietly misfile your documents, which is why the review folder, the confidence threshold, and undo are core features, not extras. Being able to swap and measure models locally is what made that visible.

Where a closed model would have been better. I didn't benchmark a hosted model, so I can't give you a number. A large cloud model would probably be more accurate. For this job I'd rather accept some misfiling that I can see and undo than send my documents to a server I don't control. Those numbers are one run on synthetic files on one machine, not a general verdict.

The Lazy Payoff

Here's the honest accounting, using only what I measured. On my 50-file benchmark, llama3.2:1b averaged about 1.5 seconds per file on a CPU-only machine, so a full pass over 50 files costs roughly 75 seconds of machine time. That happens at 3 AM at low CPU and I/O priority, so none of it is my time.

The cost I'm really removing isn't the seconds spent moving a file. It's the decision cost: opening a folder full of final_v2 (3).pdf and deciding, file by file, where each one belongs. That's the part I never get around to.

I also ran it on a copy of my own Downloads: [N files scanned, X moved, Y sent to _review/, Z left alone because they were too new, in T minutes. Then valet undo --last restored all X.]

Prize Categories

Best Use of Gemma: Sloth Valet runs Gemma locally through Ollama as one of the models in its benchmark.

Localscout: an open-weight agent that audits a local business's website before it pitches them

Aditya Patkar — Sun, 18 Oct 2026 04:46:56 +0000

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

What I Built

Every freelance web developer knows the loop. You finish a project, and the next morning you are hunting for clients again: scrolling Google Maps, opening websites that take ten seconds to load, and sending messages that say "I can improve your website" to owners who have read that sentence fifty times. The pitch carries no proof, so it gets ignored.

Localscout flips the order: audit first, pitch second.

You type something like plumbers in Bhopal, and Localscout:

Finds matching businesses from Google Maps results.
Audits each website with real measurements: a mobile Lighthouse run (time to main content, layout shift, blocking time) plus plain HTTP checks for HTTPS, a mobile viewport tag, page title and description, and a tap-to-call link. Businesses with no website, or only a social page, are flagged too.
Scores every lead. A slow site on a busy, well-reviewed business scores highest, because that owner has the most to gain.
Drafts a short WhatsApp message in English, Hinglish, or Hindi that cites only what was measured, for example that the main content took 6.1 seconds to appear in a mobile speed test.
Hands it to you. You read it, copy it or open WhatsApp with the text prefilled, send it yourself, and log what happened.

It never sends anything on its own. There is no send button in the code at all.

Who would pay? Freelance web developers and tiny agencies, especially in India, where WhatsApp is how you actually reach a plumber, a salon, or a clinic. The problem it solves for them is twofold: working out which of two hundred listings is worth a message, and arriving with evidence instead of a claim. [FILL IN: your pricing idea, for example a flat fee per batch of leads, or "I haven't priced it yet, but one hour of manual prospecting is the benchmark".]

Demo

Live: https://localscout-5cvy.onrender.com/

The free Render instance sleeps when idle, so the first load can take up to a minute.

Things to try: click "Explore with demo data", move your cursor across the pixel map (each square is a business, colored by opportunity score), open a lead to see the audit evidence behind its score, and compare the three message languages.

Code

Virtualord / LocalScout

an open-weight agent that audits a local business's website before it pitches them

Localscout

Find local businesses, audit their websites with real measurements, and draft honest outreach that you review and send by hand.

Localscout never sends anything. There is no send code path. It finds businesses measures what is actually wrong with their site, writes a short message that cites only those measurements, and hands it to you.

Everything runs on your machine.

Quickstart

Three commands. No API keys, no Chrome, no Ollama, no network.

pnpm install
pnpm dev

Then open http://localhost:5173.

This is fixtures mode: discovery reads 35 recorded SerpApi responses from fixtures/serpapi/, auditing runs against local fixture sites, and drafting uses canned JSON. Everything is exercised except the three external services.

Run a batch from the terminal instead:

pnpm cli "plumbers" Bhopal --limit 20

How it works

Browser (React)  --HTTP/SSE-->  API (127.0.0.1:8787)
                                      |
                               Mastra workflow
  discover -> dedupe -> audit (x N) -> score ->

…

View on GitHub

How I Built It

What is open, and what isn't

Piece	What it does	Open?
Gemma (via Ollama or any OpenAI-compatible endpoint)	Turns structured findings into a short message	Open weights
Lighthouse	Measures speed and mobile readiness	Open source
Mastra	Orchestrates the workflow	Open source
SQLite	Stores leads, audits, drafts, outreach log	Open source
SerpApi	Google Maps discovery	Hosted service (the one closed part; responses are cached and the source is swappable)

The workflow. A Mastra workflow runs discover → dedupe → audit → score → draft → persist. Each step is a thin wrapper over a pure, tested function, so a framework quirk never traps the logic. One failing site never aborts a run: every external call returns a result marked ok, stale, or unavailable, and the UI says so instead of guessing.

Evidence before words. This is the decision I care about most. The model never reads a web page. Deterministic code produces the findings (for example "main content at 6.1 s, threshold 4.0 s"), and the model only turns that structured data into plain language. Then a grounding validator checks the draft: every number must match the audit evidence, it may not cite a finding that wasn't provided, and banned phrases like "guaranteed #1 ranking" are rejected. A bad draft gets one retry with the errors attached, and after that falls back to a deterministic template. A cold message with a made-up number is worse than no message.

Safety by construction. Websites come from search results, so the auditor treats them as untrusted: private and loopback addresses are blocked (including cloud metadata endpoints), redirects are re-checked, and page text never reaches the model. A contacted business or domain is never pitched twice.

A real hiccup. I planned to resolve the city to coordinates before searching. My SerpApi key is on the Free plan, and every geocoding engine returned "Unsupported search engine". The documented alternative, location plus z, worked and returned 20 real Bhopal plumber results. I built the map from the GPS coordinates each listing already carries, which turned out simpler and removed the need to know the city center at all.

The frontend. I modeled the look on the Hacktoberfest site itself: a teal canvas, coral buttons with hard offset shadows, and a pixel-grid map. Each business is a square colored by score, and a spotlight follows the cursor across the grid. The map is drawn on a canvas for smoothness, while the lead squares are real buttons so keyboard and screen-reader users get the same map.

Process. I wrote the build spec first (architecture, data model, scoring rules, design system, git workflow), then had a coding agent build it phase by phase. [FILL IN: anything that went differently from the spec, such as a Mastra API change or a Lighthouse quirk, and how you handled it.]

Deployment. Hosted on Render. [FILL IN: how it is deployed, for example a single web service serving the API and the built frontend.]

Why Does Open Innovation Matter?

It makes the unit economics work. Prospecting only pays if a lead costs almost nothing to process. With an open-weight model, drafting costs no per-token fee, so the only real cost per lead is the search itself. [FILL IN: your measured numbers from /api/metrics or the eval run, for example average audit time, average draft latency, and SerpApi calls per lead.]

It keeps a freelancer's pipeline theirs. A lead list, the notes on each business, and the outreach log are a solo freelancer's most valuable data. Localscout stores them in a local SQLite file, and drafting needs no third-party LLM, so none of it goes to a model provider.

It lets me fix the part generic models handle poorly. Romanized Hindi (Hinglish) written for a local shop owner is exactly where general-purpose models tend to sound stiff. Open weights mean I can swap models, evaluate them with the same fixtures, and fine-tune later without changing the product. The model sits behind a small provider interface, so moving between Ollama, another OpenAI-compatible endpoint, or a different Gemma size is a config change.

It makes the evidence checkable. Because the audit uses open-source Lighthouse, a business owner can run the same test and see the same number. That is a much stronger opener than "your site feels slow."

Prize Categories

Best Use of Render: the app is hosted on Render.
Best Use of SerpApi: live Google Maps discovery with a disk cache to protect the free-plan quota.
Best Use of Mastra: the discover-to-persist workflow runs on Mastra.
Best Use of Gemma: drafting runs on a Gemma model.

Garden Rounds: a 6 MB leaf classifier and a frost-date planner that work with the network off

Aditya Patkar — Sun, 11 Oct 2026 03:40:46 +0000

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

What I Built

Garden Rounds is a small offline-first web app that gets people into a garden once a week. It works out its own frost dates for wherever you are from thirty years of historical weather, tells you what to sow, plant out, inspect and harvest this week, prints that as a one-page card you can take outside, and gives a first-look read on a leaf you photograph with your phone.

The screen is the shortest part of the experience. The point is the card, and the leaf.

It's for the gardener with a phone and no signal in a raised bed, and for anyone who has ever wanted to know this week specifically rather than read a seed packet written for a different country.

Three things make it work:

It computes your frost dates instead of looking them up. Type a place name and the app pulls thirty complete calendar years of daily temperatures from the Open-Meteo archive and derives your own first-spring and last-autumn frost. Everything else follows from that. "Last frost is usually April, first fall frost is usually October" is not a fact from a table — it's computed from your location, and you can move the threshold in Settings and watch the whole season shift.

The model is a 6 MB file, not a service. MobileNetV3-Small, fine-tuned on 48,947 photographs of 37 leaf conditions, running in the browser through ONNX Runtime Web's WASM backend. No API key, no account, no upload endpoint — there isn't one in the codebase.

It keeps working with the network off. A service worker precaches the shell, the fonts, the ONNX runtime and the model. After one setup call, the app makes no further requests to anywhere.

Demo

garden-rounds.onrender.com

Run it with the network off after setup. That's the demo. Turn off wifi and add a plant, scan a leaf, print the card — all of it still works.

Everything the app does on the network, it does once: your typed place name goes to Open-Meteo geocoding, and a coordinate rounded to one decimal place — about 11 km — goes to the archive API. There is an end-to-end test that asserts no third-party request happens after that, rather than the README just claiming it.

This week	Garden	Leaf check

Code

Virtualord / Garden-Rounds

A small offline-first web app that gets people into a garden once a week.

Garden Rounds

A small offline-first web app that gets people into a garden once a week.

It works out its own frost dates for wherever you are from thirty years of historical weather, tells you what to sow, plant out, inspect and harvest this week, prints that plan as a one-page card you can take outside, and gives a first-look read on a leaf you photograph with your phone.

The screen is the shortest part of the experience. The point is the card, and the leaf.

What it looks like

This week	Garden	Leaf check

The printed card is the real output:

More in docs/screens/, including a frost-free climate, the setup flow and both colour schemes.

Running it

cd web
npm install
npm run dev

Then open http://localhost:5173.

npm run lint          # eslint
npm run format:check  # prettier
npm test              # vitest, 456 tests
npm run build         #

…

View on GitHub

MIT licensed. 10,730 lines, 492 unit tests and 30 end-to-end tests.

How I Built It

The model. MobileNetV3-Small (timm, Apache 2.0) fine-tuned on PlantVillage, grouped by leaf so that all four photographs of the same leaf land on the same side of the split. Eight epochs, CPU-only, about two hours.

That grouping was the whole ballgame, and it came from a mirror rather than the original dataset. The Hugging Face mirror geraldmc/plantvillage-full keeps a leaf_id column that upstream discards. 69% of eligible rows are one of just 5,910 leaves, shot four times over. Split those naively and the model sees the same leaf in both train and test. It was not a hypothetical: the audit caught a real bug on its first run, with 3,223 leaves assigned to both validation and test.

So ml/prepare_hf.py groups on leaf_id, and its audit() raises rather than printing reassurance. A split report that quietly says "looks fine" is how a leaked split gets shipped. Final leaf overlap between every pair of splits: 0.

Split	Images	Leaves	Images per leaf
train	34,096	14,663	2.33
val	7,411	3,195	2.32
test	7,440	3,223	2.31

The result: lab top-1 0.9957, macro recall 0.9950, 37 classes. All 32 errors are between two diseases of the same plant, and the correlation between class size and recall is +0.07 — indistinguishable from zero. The 37× class imbalance was the reason to check that rather than assume it, because the small classes are normally what breaks first.

I tried to make it 2 MB and it refused to be. The target was int8. All three quantisation routes produced near-constant output:

Precision	Size	Lab top-1
fp32	6.23 MB	0.9957	shipped
static QDQ, per-channel	1.90 MB	0.0887	refused, −90.7 pts
dynamic, per-channel	1.72 MB	0.1187	refused
dynamic + `reduce_range`	1.72 MB	0.0000	refused

So the export carries a gate: int8 ships only if it costs no more than 1.5 points. It refused, three times, and fp32 shipped. Two candidate causes were tested and eliminated — single-class calibration, and VNNI-less saturation. The wrong answer is still in ml/MODEL_CARD.md with both hypotheses, because I don't know what it is and 6.23 MB is the honest answer.

Everything else is deliberately not AI. There's no language model anywhere in this app. The planner is a pure function of your frost dates and the crop's own needs, with today injected so it's testable. A language model would have made it worse and less trustworthy, and the app's claim — "this is what your dates say" — is only worth making if the thing producing it is inspectable.

The app. React 19, Vite, Tailwind v4, react-router, ONNX Runtime Web, IndexedDB, Vite PWA. The design constraints that shaped it:

One animation runs forever, and a test asserts there's exactly one. That's what stops a second from being added without noticing.
One nav landmark. The bottom tab bar restyles into a left rail at ≥64rem rather than being duplicated, so there's never two navs.
No horizontal scroll at 320, 360, 390, 820, 1024 or 1440px — asserted.
The theme is System / Light / Dark, with each colour declared once via light-dark() and the three options only setting color-scheme. Setting color-scheme rather than repainting also fixes scrollbars, the caret and form controls.

Why Does Open Innovation Matter?

Because it runs in a garden with no signal, and because the photographs never leave the phone.

Both of those are consequences of the licence, not accidents. A closed API would have been easier: a bigger model, better generalisation, someone else's GPUs. What it could not have been is offline, or free of a server holding photographs of someone's plants. Those aren't features I added on top of the open approach. They're what the open approach is for.

Concretely, open weights let me do three things a hosted endpoint would have stopped me doing:

Find the leak myself. I could decode the dataset's structure, discover that 69% of rows were four shots of the same leaf, and fix the split. With an API I would have sent a photo, got an answer back, and had no way to ask why — so the leak would have stayed invisible and I'd have shipped a number I believed.

Set the gate and let it refuse. The quantisation table above is only meaningful because I could run the model locally, badly, a hundred times. The 1.5-point rule rejected all three int8 routes. A hosted service would have returned a working answer and I'd never have known there was a cheaper size I hadn't found.

Publish the failure. MODEL_CARD.md records the licence dispute, the int8 table, the 37× class imbalance, and the one wrong prediction I left in place rather than quietly fix. You can check any of it, because the pipeline that produced it is in the repo.

On privacy specifically: there is no upload endpoint in this codebase. Your leaf photographs are resized and classified in the browser and stored only as a thumbnail on your own device. The Content-Security-Policy in render.yaml makes that enforceable rather than aspirational — connect-src names Open-Meteo and nothing else, so a browser would block a third-party call even if someone added one.

Where this is genuinely worse than a closed approach

The project is an argument, so the argument needs its counter-argument, and I'd rather write it than have a judge find it:

No open questions. "What's wrong with this leaf and what should I do?" is the real question. This answers "which of 37 conditions does this resemble" — narrower.
No context across a season. It sees one leaf. It doesn't know the plant has been declining since June, or that the bed waterlogs.
No coverage outside the label set. Thirty-seven classes from two datasets. A strawberry problem that isn't leaf scorch isn't in the space, and the model will confidently offer the nearest thing it knows.
Worse photographs. It's trained on photographs most people don't take. A closed API trained on far more varied data would handle a phone-in-the-dark photo better.
No explanation. It can't tell you why, or what to do next. That's advice, not classification.

What I haven't done yet

Being straight about this, because a 0.9957 in a write-up invites the wrong conclusion:

There is no field test. The 0.9957 is on held-out lab photographs. docs/FIELD_TEST.md exists and is empty; I have not photographed a real garden with this yet.
No field split at all — metrics.json records "field": {"n": 0, "skipped": "no images in this split"}. The corpus is lab-only. This is a number on a test set, not a product claim.
The model isn't published yet. models/leaf.onnx is a gitignored Release asset, so the deployed Scan screen says plainly that no trained model is installed. The rest of the app is fully functional without it. It needs a GPU box to run the export properly — mine is sm_61, and PyTorch has dropped sm_61 from every wheel.
26 crop timings still need checking against a local extension guide. Every one is marked needs_review in the plan and on the card.
A licence question is unresolved. The HF mirror is tagged cc0-1.0; upstream PlantVillage is CC BY-SA 4.0. Those cannot both be right. No dataset is redistributed here, and the dispute is recorded rather than assumed away.

Best Use of Render — the app is a static Vite build deployed as a Render static site with a Blueprint, an SPA rewrite rule that doesn't swallow the wasm or the model, long-lived immutable caching for both, and a Content-Security-Policy that makes the no-third-party-requests claim something a browser enforces.

Hacktoberfest Weekend Challenge: Build for a Friend

Aditya Patkar — Sun, 04 Oct 2026 16:23:24 +0000

## What I Built

saaz-8d9d.onrender.com

I built Saaz, a subtitle tool for regional-language video. You upload a clip, and it returns timed Hindi subtitles plus an English translation. You can edit them in the browser and export .srt or .vtt. Everything runs on your own machine with open-weight models, and no closed AI API is called at any point.

I built it for Raashi, who edit reels they caption footage for clients, and uploading unreleased footage to a hosted captioning service wasn't an option.

That is the problem Saaz solves. When you caption someone's unreleased footage, the video, the transcript and the translation normally all end up on somebody else's server. With Saaz every byte stays local, and the offline claim is checkable: npm run prove:offline runs the pipeline with all outbound network poisoned.

It also doesn't pretend to be perfect. A translation often needs more characters than the on-screen time window allows, so a Fit stage escalates through five outcomes:

verbatim: it already fits
reflowed: a small model rewrites it inside the budget
extended: borrow time from the following gap
split: divide the cue deterministically and retranslate both halves
refused: nothing works, so flag it for a human and say why

The last outcome matters most. A subtitle file is something a client signs off on, so a tool that always outputs something is worse than one that tells you which lines need a person.

Code

https://github.com/Virtualord/saaz

How I Built It

The pipeline is: probe → decode → Whisper ASR → Silero VAD → align → segment → glossary → OPUS-MT → Fit.

Stage	Model	Licence
Speech recognition	`onnx-community/whisper-small`	MIT
Speech boundaries	`onnx-community/silero-vad`	MIT
Translation draft	`Xenova/opus-mt-hi-en`	Apache-2.0
Caption rewrite	`HuggingFaceTB/SmolLM2-360M-Instruct`	Apache-2.0

All four run through one runtime, transformers.js over onnxruntime-node, quantised to q8 so they fit in CPU RAM with no GPU. The app is TypeScript throughout, with a React + shadcn/ui + Tailwind v4 frontend, Vite, SQLite for jobs, and Vitest for the unit tests (segmenter, fit, align, glossary, export). I deploy it from a Docker image to Render, with the weights baked in at build time so the live service never contacts Hugging Face.

I chose every default from a benchmark rather than reputation:

Whisper-base emits Arabic script for Hindi audio (CER 1.00). whisper-small scores 0.165. I also tried whisper-large-v3-turbo, but at q8 it returned empty transcripts, so I removed it instead of shipping it broken.
Qwen2.5-0.5B and 1.5B couldn't do the caption task. Both failed to produce parseable JSON and degenerated into repetition. SmolLM2-360M returned valid JSON first try and ran 2.5× faster. Smaller model, better result.
The Whisper export has no cross-attention outputs, so it can't emit word timestamps. Its segment timings collapsed into uniform 3-second blocks that matched nothing in the audio. I found this by inspecting real output and fixed it with Silero VAD.
Open MT has vocabulary gaps. मालाई (the sweet) translated to "by Miley". I ruled out tokenisation bugs, so Saaz ships a user-pinned glossary that is substituted before translation.

There is deliberately no agent loop in the fit path. A subtitle deliverable has to be reproducible, so escalation is deterministic.

Honest limitations: Whisper quality on regional languages is imperfect (hence the editor), word timing is approximated by proportional alignment, and CPU inference runs at roughly 4× realtime for ASR. That is the price of keeping footage on a laptop.

Why Does Open Innovation Matter?

A closed API would have made this project impossible, because the whole point is that the footage never leaves the machine. Open weights let me run speech recognition, translation and caption rewriting in-process and prove it with the network unplugged.

Openness also made the work inspectable. I could open the Whisper export and discover it had no word timestamps. I could swap Qwen out for SmolLM2 when Qwen failed, and I could read every model's licence and put it in the UI. I even left Gemma out of the defaults because its licence isn't OSI-approved. With a closed API I would have had to trust whatever it did to my friend's footage. Here I can show exactly what ran and why.

Prize Categories

Best Use of Render: Saaz ships a render.yaml blueprint and deploys from a Docker image with weights baked in.