DEV Community: Gaurav Sethi

Sloth Drawer: an offline agent that reads the manuals you already own and prints one maintenance card per device

Gaurav Sethi — Sat, 24 Oct 2026 14:37:36 +0000

I own 11 devices, and I could not tell you when any of them last needed cleaning — the manual PDFs
are in a drawer nobody opens, and "every 2 months" is information with no memory attached to it. So
I built Sloth Drawer: an offline, CPU-only agent that reads the manual PDFs you already have,
verifies every interval it finds against the manual's own text, and prints one maintenance card per
device — tape it to the thing, done thinking about it.

And the number that started the whole project: applied to a multi-interval page, a 291 MB model told
me the pre-carbon filter needed replacing "every 1 month" — and cited a sentence that contains no
interval at all. My verifier caught it automatically. That failure is why the tool exists.

What I Built

Sloth Drawer is a Python CLI + a one-page web UI. No API keys, no cloud model, no database you have
to rent. A cold install takes 3.66 seconds (uv with an empty cache, 19 packages) because the core
runs on pypdf and the standard library.

You drop a folder of manual PDFs in (from a checkout, every command runs through uv;
uv tool install . once and the bare sloth-drawer command does the same):

uv run sloth-drawer scan data/manuals      # 19 manuals in 10:14 on a 4-core CPU, unattended
uv run sloth-drawer card honeywell-hpa3000 # one card: HTML (print-ready A6) + 80-column terminal card
uv run sloth-drawer done honeywell-hpa3000 "Filter Replacement"   # you did it — due date moves, in code
uv run sloth-drawer report                 # the accuracy table you see below
uv run sloth-drawer serve                  # the same cards in a browser

The demo corpus is 19 air-purifier manuals across 7 brands — one device class, so one card layout
and one honest, comparable benchmark.

Demo

The live demo serves the actual verified intervals from the scan — a checked, committed snapshot
of the scan database ships inside the container image, and the web card is byte-identical to the CLI
card (there is a test that proves that).

Code

The source code and setup instructions are open source on GitHub:

Gaurav5189 / sloth-drawer

The offline agent that turns the manuals you already own into a maintenance card

🦥 Sloth Drawer

Offline agent that reads the manual PDFs you already downloaded and prints one maintenance card per device — the interval, the manufacturer's own sentence, the page number, and the next date it is due.

Status: the 19-manual air-purifier corpus runs unattended, offline, on the CPU — and the web demo is live at https://sloth-drawer.onrender.com/ (Render free tier built from deploy/, zero env vars). sloth-drawer scan data/manuals yields 35 intervals found · 22 verified · 13 repaired · 7 rejected in ~10 minutes, at $0, on a 4-core box with no GPU. The verifier (extract/verify.py) is the product; the report in out/report.md is the evidence. Built for Hacktoberfest Open-Source AI Challenge: Week 3 — Slow and Steady — post draft staged for review.

➡️ New here? INSTRUCTIONS.md is the complete setup-and-use guide — what to install, which models to pull and why, where…

View on GitHub

How I Built It

The pipeline is: ingest → chunk → regex pre-filter → (optional) 270M triage → 1B extraction → verification. Three decisions the benchmark forced:

1. One fact per call, flat schema — never an array. I benchmarked three models on 4 CPU cores,
7.5 GB RAM, no GPU. Under an array-of-objects schema, phi4-mini returned {"intervals": []} —
schema-valid, semantically empty. A flat has_interval / task / interval_months / quote / section
schema asked once per interval-shaped sentence passed on every model tested.

2. The model points, the code quotes, the code recomputes. The model returns a quote fragment.
Code then (1) locates the fragment in the page it came from, (2) expands it to the enclosing
sentence, (3) re-parses the interval from that sentence itself, and (4) compares it to the
model's number. Three verdicts: PASS, REPAIR (code value wins, disagreement recorded), REJECT.
Every date on every card is computed in storage/ from a service log you keep. Zero model-authored
dates. That is the whole trick, and it is why nothing below can be hallucinated into a wrong date.

3. Three-tier cascade. A regex pre-filter scores interval-shaped language for free; on this
corpus only 84 of 1,325 chunks ever reach a model — 94% are filtered out at zero cost.
gemma3:270m (291 MB) is an optional yes/no triage gate; gemma3:1b (806 MB) does the extraction
at temperature 0 with a fixed seed and a structured-output format. Both models run locally via Ollama;
the core install never imports an SDK.

Unit conversions (90 days = 3 months, 720 hours = 1 month, ranges take the midpoint...) live in
one table, stated in the prompt and in the verification code, pinned together by tests — if the
model's rule and the code's rule ever drift, every "every 90 days" becomes a false REPAIR.

The Validator Is the Product

Small local models will lie to you; the job is making the lie unable to reach a printed date.
The verifier's verdicts, with measured examples from bench/ and the shipped run:

Model output	Verdict
hallucinated quote (`"...every 6 months"` — no such text on the page)	REJECT (`quote_not_in_page`)
real quote, wrong number (model said 3, the sentence says 12)	REPAIR — code value wins
cites a sentence containing no interval	REJECT (`no_interval_in_citation`)
invented task label — a task on the card that does not appear in the manual text	REJECT (`task_not_in_source`)

A real REPAIR from the run: Winix 5500-2, page 1 — the model said "Clean once every 3 months"
(the washable carbon filter line), but its quoting drifted into the neighbouring "...Last Approx. 12
months True HEPA Filter" line. The verifier re-parsed the cited sentence, got 12, wrote 12 with
the disagreement recorded. Both the 3-month and the 12-month tasks are on that card today, each
citing its own verified sentence.

The verifier is 554 lines of pure Python with no model calls and no project imports beyond
errors.py — the AST import test enforces that. If you take one idea from this post: an extraction
pipeline does not need a smarter model, it needs a verified quote. A recent DEV post
lands on the same shape — treat model output as an untrusted API response and gate it — and my
measured numbers agree, with one addition: re-derive the value from the source text the model can
only point at, so even a structurally perfect answer can fail against its own quotation.

The Benchmark

bench/final.py on a synthetic multi-interval page, exact printed output (out/bench-phase3.txt):

Model	Size	Latency	What the verifier did with its answer
`gemma3:270m`	291 MB	3.6 s	claimed 1 month, cited a non-interval sentence → REJECT
`gemma3:1b`	806 MB	9.1 s	months = 2, quote located → PASS
`phi4-mini`	2.5 GB	53.9 s	months = 2, quote located → PASS (6× slower, 3× RAM, uses swap)

gemma3:1b is the default; phi4-mini stays behind --model as a documented alternative. The
failure of the 270M here is not in a prompt somewhere — it is the measured, reproducible reason the
verifier ships with the tool.

Why Does Open Innovation Matter?

Not the generic paragraph — the concrete one:

The whole stack runs where you are. 291 MB and 806 MB Gemma weights, 4 CPU cores, no GPU, $0.00 for 22,401 tokens. I proved the full 19-manual run with the network off — inside a user+network namespace with only loopback configured, a second Ollama served inside it, and no route to anything external. Identical verdicts (out/scan-offline.txt). Basements, garages, air-gapped networks: the claim is a log line, not a promise.
Swap the model, keep the card. --model phi4-mini changes how the agent behaves with the same interface — deliberately, because open weights are the only thing that makes a model a configuration item and not a dependency.
Swap the retrieval backend, keep the card. The same card comes out of the local SQLite FTS5 trigram index and out of a Tiger Cloud hybrid index (pgvector + pg_textsearch BM25, fused with Reciprocal Rank Fusion). A parity run over the live corpus: 4/4 queries PARITY — every local top-5 hit reachable in the cloud top-20. The cloud index is an enhancement, never a prerequisite; the physics of a plane flight cannot break the default.
Privacy as a schema constraint, not a promise. The cloud table (manual_chunks) holds chunk text + embedding — it has no column that could hold a device name, serial number, purchase date or service log, and the code that fills it never sees one. Only manual text and embeddings ever cross the wire; the cards and the due dates stay on your machine.
The verifier also enforces locality of truth. Because a model must cite a verbatim substring of your own manual, the model can only ever point at text you already own — it cannot smuggle in a "fact" you do not have a reference for.
Open formats end to end: SQLite + JSON + Markdown reports, PDFs you already have. Uninstall the tool and you still have everything it extracted, with citations.

My Agent Session

I built this in the open with agentic AI. The Phase 3 wrap-up — the offline proof, the CodeRabbit
triage round, and the documentation decisions — is saved publicly so you can watch the reasoning:

Sloth Drawer — Phase 3 wrap-up: offline proof, CodeRabbit triage, and honest docs

You

Continue Phase 3: finish the offline proof run and update the docs with the real numbers.

Agent

The offline proof completed: 19 manuals · 35 intervals found · 22 verified · 13 repaired · 7 rejected · 673s · 22401 tokens · $0.00 — identical verdicts to the networked run, inside a unshare -rn namespace with only loopback up and a local Ollama. Exit code 1 is expected (rejections count as partial success).

▸ shell (offline proof) unshare -rn bash -c 'ip link set lo up; ollama serve &; sloth-drawer scan dat...

Input

unshare -rn bash -c 'ip link set lo up; ollama serve &; sloth-drawer scan data/manuals --no-persist'

Output

19 manuals · 35 intervals found · 22 verified · 13 repaired · 7 rejected · 673s · 22401 tokens · $0.00 (log: out/scan-offline.txt)

▸ edit (.agents/MEMORY.md) record full corpus run 614s, resume pass 0.52s (19/19 skipped), benchmark re-...

Input

record full corpus run 614s, resume pass 0.52s (19/19 skipped), benchmark re-run, offline proof 673s, 281 pytest green (2 skipped)

Output

MEMORY.md updated with final Phase 3 numbers

You

Examine these CodeRabbit suggestions and make a plan whether to fix them or not and why. Also check for edge-case issues if the changes would affect our functionality.

Agent

Three findings. Plan after verifying each against the code:

INDEX.md stale (minor) → FIX. Phase 3 is complete but INDEX.md still says 'in progress' and 'Blocked: none'. It's the retrieval entry point for future agents, so a stale state actively misroutes.
--list with --resume shows a partial table (minor) → FIX WITH A NOTE, don't reject the flag combination. Traced it: outcome.candidates only holds this run's scans (batch.py builds it from extracted, which skips resumed manuals), so resumed manuals are silently absent. Rejecting --list --resume would break the legitimate 'resume then show me this run' flow. Instead, print a note when outcome.resumed > 0. Edge cases checked: resumed rows ARE in the DB and report (only the candidate dump is partial); --list --no-persist unaffected; outcome.resumed already exists so no new state.
Autocommit would break per-manual transactions (major) → NO FIX NEEDED — false positive for the current code, and the requested mitigation already exists. connect() uses plain sqlite3.connect() (legacy transaction control: no isolation_level=None, no autocommit=True), so the first DML in store_manual implicitly begins the transaction that with connection: commits/rolls back. And tests/test_batch.py::test_a_manual_is_written_in_one_transaction already monkeypatches the second interval write to fail and asserts nothing survived on reopen. The only cheap improvement: a load-bearing comment in connect() so a future 'modernization' to autocommit knows the invariant.

You

Yes, apply the recommended fixes.

Agent

▸ edit (DOCS/INDEX.md) phase → complete (2026-10-23); current task → Phase 4 (Tiger backend, parity ...

Input

phase → complete (2026-10-23); current task → Phase 4 (Tiger backend, parity run); blocked → Sentry screenshot needs a real SLOTH_SENTRY_DSN

Output

INDEX.md resynced with PHASES.md

▸ edit (src/sloth_drawer/storage/db.py) document in connect() that legacy sqlite transaction control is load-bearing ...

Input

document in connect() that legacy sqlite transaction control is load-bearing for store_manual atomicity

Output

comment added — after catching my own slip: the note initially went in as bare prose (a syntax error) and is now a proper # comment

▸ edit (src/sloth_drawer/cli.py) when outcome.resumed > 0, print a note that resumed manuals are not in the --...

Input

when outcome.resumed > 0, print a note that resumed manuals are not in the --list table; their intervals are in the report and database

Output

note added before _print_candidates

▸ edit (tests/test_batch.py) pin the contract: assert outcome.candidates == () in test_resume_skips_an_unc...

Input

pin the contract: assert outcome.candidates == () in test_resume_skips_an_unchanged_manual

Output

assertion added

▸ shell (verify) ruff check + format --check + mypy + pytest

Input

ruff check + format --check + mypy + pytest

Output

All checks passed; 281 passed, 2 skipped in 136s

You

Is MEMORY.md also updated?

Agent

It had Phase 3 completion and the run numbers from earlier, but not today's review round. Updated: the blocked line now names the Sentry screenshot (needs a real SLOTH_SENTRY_DSN, capture in Phase 5) instead of 'none', and a new Decisions Log entry records the triage — the INDEX.md resync, the --list/--resume note (and why a note rather than rejecting the flag pair), and the connect() comment documenting why legacy sqlite transaction control underpins store_manual's atomicity.

▸ edit (.agents/MEMORY.md) blocked line + new top Decisions Log entry for the CodeRabbit round 2 triage

Input

blocked line + new top Decisions Log entry for the CodeRabbit round 2 triage

Output

MEMORY.md fully current

You

Can you save this session (nicely edited format) to my dev account agent sessions?

Agent

Submitting this curated transcript to DEV as an agent session via DevRelay.

The Lazy Payoff

Reading a maintenance table by hand, for 19 appliances, is about 20 minutes per device when you
care enough to look, and — being honest — you never look.

Measured payoff instead: drop 19 PDFs into a folder. Walk away. Ten minutes and fourteen seconds
later you have 35 verified intervals, a print-ready card per device, and an accuracy report telling
you exactly which 13 extractions needed repair and why 7 were rejected. ≈37× less reading, $0 of
API cost, forever, offline. After that, maintenance is one tap (done) or one click in the browser
— and the code, not a language model, moves the due date.

Prize Categories

Best Use of Gemma — gemma3:270m triage + gemma3:1b extraction, the measured benchmark, and the 270M's honest failure, all running locally through Ollama.
Best Use of Tiger Data — the optional hybrid retrieval backend: pgvector + pg_textsearch BM25, fused with RRF on Tiger Cloud, plus the 4/4 backend parity run.
Best Use of Render — https://sloth-drawer.onrender.com/ on the free plan, zero env vars, the seed snapshot shipped in the image.
Best Use of Entire (DEV) — this post, and one embedded agent session above.

Repo: https://github.com/Gaurav5189/sloth-drawer · Live demo: https://sloth-drawer.onrender.com/

Touch Grass — A Bird ID App That Works When There's No Signal

Gaurav Sethi — Wed, 07 Oct 2026 06:48:02 +0000

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

What I Built

I built Touch Grass because identifying a bird call shouldn't mean uploading your life to someone else's server. Most nature apps work like this: you record audio, it ships to a cloud API, you wait, you get a result, and somewhere a company logs that you were near a lake at 7am. I didn't want any of that.

Touch Grass is a Progressive Web App that runs open-weight AI models entirely inside the browser. You record a 3-second bird clip, the app converts it to a mel spectrogram locally, and an ONNX model predicts the species — all without a network call after the initial download. The same approach works for plants and insects from photos. Once the model is cached in IndexedDB, the app works completely offline. No accounts, no tracking, no "please sign in."

It's for people who actually want to spend time outside. The whole philosophy is: identify quickly, then put the phone back in your pocket and enjoy the trees.

Demo

Live site: https://touch-grass-143.pages.dev

Install it like a normal app — the service worker caches the shell, the manifest is set up, and offline identification works after the first model download. I tested the PWA install on Android Chrome: add to home screen, open it, allow the mic, record 3 seconds, and you'll see results come back from the local BirdNET model with no signal required. I haven't done a long birding trip yet, but the whole point is that it works exactly where the map stops — on the trail with no bars.

Code

Gaurav5189 / touch-grass

A Progressive Web App that helps people identify birds, plants, and insects using open-weight AI models running entirely on-device. Works offline, keeps all data local, and minimizes screen time so you can get back to nature.

Touch Grass — Local-First Nature Identification PWA

A Progressive Web App that helps people identify birds, plants, and insects using open-weight AI models running entirely on-device. Works offline, keeps all data local, and minimizes screen time so you can get back to nature.

Philosophy: Identify quickly, then put the phone away and enjoy the outdoors.

Features

Bird Call ID — Record 3-second audio clips, identify species via BirdNET-ONNX (~20MB, quantized, 3000+ species), all on-device.
Plant & Insect Photo ID — Capture or import a photo, get top-5 matches from a MobileNetV3 model (~5MB), with descriptions and similar species.
Fully Offline — After initial model downloads, no internet required. Service worker caches the app shell; IndexedDB stores observations and model cache.
Private by Default — No accounts, no tracking, no server requests for inference. Optional GPS tagging is opt-in only.
Observation History — Auto-save after every identification. Filter, search, and export…

View on GitHub

Repo: Gaurav5189/touch-grass

Key parts worth looking at:

src/features/bird-id/ — AudioRecorder hook, BirdResults UI, RegionFilter
src/features/photo-id/ — CameraCapture, GalleryImport, MobileNet inference stub
src/features/history/ — Observation list, filters, CSV/JSON/iNaturalist export
src/workers/inference.worker.ts — ONNX Runtime Web with WebGPU preferred, WASM fallback
public/manifest.json + vite-plugin-pwa — full PWA setup

How I Built It

Stack is straightforward: React 18, TypeScript 5.3, Vite 5, Tailwind 3.4. Nothing exotic. The interesting part is what runs inside the browser.

Bird identification: BirdNET-ONNX (quantized INT8, ~20MB, Apache-2.0, 3000+ species). It runs in a Web Worker via onnxruntime-web, with WebGPU first and WASM fallback.
Plant / insect identification: MobileNetV3 + custom iNaturalist head (~5MB, Apache-2.0 / CC-BY data).
Offline storage: IndexedDB (idb) for observations and model cache; Cache API for the app shell.
Privacy: Zero server requests for inference. Optional GPS is opt-in only. No analytics, no telemetry.

I used OpenCode for the main structure — scaffolding the PWA, setting up the folder layout, and getting the build pipeline clean (CI with typecheck, lint, build). Then Antigravity helped with refinements and bug fixes — fixing TypeScript casting issues with navigator.gpu, cleaning up import paths for onnxruntime-web.d.ts, resolving build errors in useModelDownload, and fixing the Playwright / Vitest conflict so E2E tests could run separately.

The model strategy is open-weight all the way: BirdNET from the BirdNET-Analyzer repo, MobileNet weights fine-tuned on public iNaturalist data. All licenses documented in DOCS/RULES.md. No proprietary or GPL dependencies.

Why Does Open Innovation Matter?

If this was a closed API, you couldn't swap the bird model for a regional 8MB pack. You couldn't upload your own ONNX file for a custom species set. You couldn't verify that your audio isn't being stored somewhere else. And you definitely couldn't run it in a cabin with no signal.

Open-weight models make this possible because the weights are files you download, not services you call. The BirdNET team released their quantized model under Apache-2.0. The iNaturalist dataset is CC-BY. That means I can bundle them into a browser app without licensing anxiety or vendor lock-in. Open innovation here isn't a marketing line — it's the reason the app can work offline, stay private, and let users control which model they run.

Prize Categories

Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
Open Source / Open Weight Models
Open Source AI Challenge

LocalCommit: Offline Conventional Git Commits with Local LLMs

Gaurav Sethi — Sun, 04 Oct 2026 21:20:48 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend (https://dev.to/challenges/hacktoberfest-weekend-2026-10-01)

What I Built

I built LocalCommit, a lightweight CLI tool that inspects your staged git diffs and drafts concise Conventional Commit messages (feat(auth): add refresh token rotation) running entirely on your local machine using Ollama.
I built this for my friend Manish, a software engineer working under strict client non-disclosure agreements. Manish's team requires strict Conventional Commits for automated changelogs and semantic releases, but company policy strictly forbids piping source code or git diffs to proprietary cloud LLM APIs (like OpenAI or Anthropic). Whenever Manish makes multi-file changes across large codebases, writing detailed conventional commit messages by hand slows down their workflow.
LocalCommit solves this by reading git diff --staged and running inference on an open-weights model locally. Zero tokens leave the machine, no API keys are required, and the tool works even when working offline on a train or during an internet outage.

Demo

Here is how running LocalCommit looks in terminal:

$ git add src/auth/token.ts src/middleware/jwt.ts
$ npx localcommit
[localcommit] Checking staged changes...
[localcommit] Sending diff to qwen2.5-coder:3b...

Proposed commit message:
  feat(auth): implement refresh token rotation and validation

Commit with this message? [y/N/e (edit)/r (regenerate)]: y
[main 7f2a1b9] feat(auth): implement refresh token rotation and validation
 2 files changed, 48 insertions(+), 6 deletions(-)
You can confirm with [y] to commit immediately, hit [e] to edit in place, [r] to regenerate with a slightly different phrasing, or [n] to cancel without touching git state.

Code

The source code and setup instructions are open source on GitHub:

Gaurav5189 / LocalCommit

Local-first CLI for generating conventional commit messages via Ollama.

LocalCommit

Local-first CLI for generating conventional commit messages with Ollama.

LocalCommit reads your staged Git diff, generates a Conventional Commit message with the configured local model, and asks for confirmation before committing.

Requirements

Node.js 18+
Git CLI
Ollama
A model configured in the root model file (default: qwen2.5-coder:3b)

If Ollama is not installed, follow the platform-specific instructions in INSTRUCTION.md.

Setup

npm run setup

The setup command verifies Node.js and Git, checks that Ollama is running, downloads qwen2.5-coder:3b if it is missing, installs dependencies, and builds the project.

If setup reports that Ollama is unavailable, install it and start the Ollama service by following INSTRUCTION.md.

Usage

Start Ollama in a separate terminal if it is not already running:

ollama serve

Stage your changes in a Git repository, then run:

npx localcommit

Inside a checkout of this project, npx localcommit resolves the local package binary. To use it from…

View on GitHub

Repository link: Gaurav5189/LocalCommit

How I Built It

LocalCommit is written in TypeScript and connects to Ollama (https://ollama.com/) running locally:

Default Model: By default, it targets qwen2.5-coder:3b—a fast, open-weights code model capable of running with low latency on modest CPU or laptop GPU hardware without draining battery.
Context Auto-Detection: Instead of assuming a static token limit, LocalCommit queries Ollama's /api/ps and /api/show endpoints at runtime to discover the exact context window allocated by your environment.
Two-Stage Summarization for Large Diffs:
Small diffs fit in a single prompt and produce an immediate message.
For larger, multi-file changes exceeding the context window, it switches to a hierarchical strategy: it prioritizes source code files (src/, tests/), generates concise per-file summaries bounded by a strict 60-second budget, and feeds that synthesized context into a final commit prompt.
Deterministic Post-Processing: Small local models can occasionally output markdown fences or descriptive preambles. LocalCommit passes the raw output through a deterministic formatting engine that enforces standard type(scope): subject syntax, cleans generic scopes, and converts verbs into imperative mood (add, fix, refactor).
Cross-Platform Host Detection: Handles network boundary quirks across Linux, macOS, Windows, and containerized setups (like Docker) by probing OLLAMA_HOST, 127.0.0.1:11434, and localhost:11434.

Why Does Open Innovation Matter?

Open-weights models and local runtimes like Ollama make use cases possible that cloud AI endpoints fundamentally cannot support:

Complete Data Sovereignty & Privacy: Codebases under NDAs, proprietary IP, or internal air-gapped networks cannot send raw git diffs over external APIs. Open models let developers use AI assistance without ever leaking code.
Offline Reliability: You don't need active Wi-Fi, metered bandwidth, or cloud service uptime to commit your work.
Zero Ongoing Costs & No API Keys: Developers don't have to manage credit cards, rate limits, or monthly token bills.
Flexibility to Swap Models: You can drop in any local model (e.g. llama3.2, codellama, deepseek-coder) simply by editing the model file or setting the LOCALCOMMIT_MODEL environment variable.

My Agent Session

The development session where I debugged the container connectivity issues and fixed the Ollama host resolution:

LocalCommit: Fixing cross-platform Ollama connectivity for containers

You

The setup script and CLI are failing to connect to Ollama in GitHub Codespaces because localhost resolves to ::1 but Ollama binds to [REDACTED]. Need multi-host resolution and proper URL construction.

Agent

I'll create a shared Ollama client utility for host resolution and fix both the setup script and CLI.

▸ write src/ollama-client.ts

Input

src/ollama-client.ts

Output

Created shared utility with getOllamaHosts(), ollamaFetch(), checkOllamaReachable()

▸ edit src/llm.ts

Input

src/llm.ts

Output

Updated to use multi-host resolution for /api/chat, /api/show, /api/ps

▸ edit src/env-check.ts

Input

src/env-check.ts

Output

Updated to use shared checkOllamaReachable()

▸ edit scripts/setup.js

Input

scripts/setup.js

Output

Fixed double-slash URL bug (new URL('/api/tags', base)) and reordered host priority

You

Build succeeded but setup still fails - need to debug the http.get call in setup.js

Agent

Found the issue - urlObj.toString() + '/api/tags' creates double slash. Fixed with new URL(path, base).

▸ edit scripts/setup.js

Input

scripts/setup.js

Output

Fixed URL construction using new URL('/api/tags', base)

You

Setup now works. But when model in 'model' file doesn't match installed Ollama model, error message is unclear. Add guidance to run 'npm run setup'.

Agent

Added special case handling for 404 'model not found' error with actionable message pointing to 'npm run setup'.

▸ edit src/llm.ts

Input

src/llm.ts

Output

Added model-not-found error handling with setup guidance

You

Now help me write a DEV post for Hacktoberfest Weekend Challenge submission.

Prize Categories

Hacktoberfest Weekend Challenge: Build for a Friend
Open-Source AI / Open Weights Integration (Llama 3.3, Qwen 2.5, gemma 4)
Local Inference & Edge AI (Ollama 100% offline laptop execution)

LICENSE

This project is open source and available under the MIT License.

Building LinkCut: A Sub-20ms URL Shortener with Next.js, FastAPI, and Redis

Gaurav Sethi — Mon, 24 Aug 2026 19:29:42 +0000

Hi, i'm Gaurav. This is my first post to dev.to

What is LinkCut?

LinkCut is a free, open-source URL shortener with no signup required — paste a link, cut it, share it. No accounts, no tracking cookies, no dashboard bloat.

🔗 Live app: https://linkcut-nine.vercel.app/
💻 Repo: https://github.com/Gaurav5189/url-shortener

Why I built it

I wanted to design a system where redirect latency actually mattered, not just a CRUD app with a UI wrapper. That meant thinking about caching, write-amplification, and decoupling reads from writes — not just "shorten a string and save it to a DB."

Architecture

The core idea: separate the fast path from the slow path.

Fast path (Edge Middleware): checks Redis first, returns a 302 redirect directly from the edge, and fires a non-blocking INCR for click tracking.
Slow path (Backend fallback): on a cache miss, FastAPI decodes the Base62 short code to an integer ID for an O(1) indexed lookup in SQLite, then repopulates Redis with a 12-hour TTL.
Background path (Cron): flushes Redis click counters into SQLite periodically using an atomic Lua script — read-and-delete in a single Redis transaction, so counts never get double-counted or lost.

This keeps redirects fast (sub-20ms) while analytics writes stay off the hot path entirely.

Tech stack

Frontend/Edge: Next.js (App Router) on Vercel Edge Middleware
Cache/Counter: Redis
Backend: FastAPI
Database: SQLite
Encoding: Base62, 5-character codes from auto-incrementing IDs (~916M capacity)

What I learned

I underestimated this going in. The URL shortening part is trivial — the interesting engineering is in the caching strategy, avoiding database write-amplification on every click, and making sure the analytics counter flush is atomic so nothing gets lost or double-counted under concurrent traffic.

Feedback on the caching strategy or architecture decisions welcome — always looking to improve it.