DEV Community: Ayushya Ranjan

Stop opening the whole PDF: local summaries for reading debt

Ayushya Ranjan — Sun, 25 Oct 2026 11:56:25 +0000

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

What I Built

tldr-everything is a local reading-debt killer. You hand it a PDF, a Markdown file, or a paste. It gives back three layers, each from its own model call:

a 30-second summary, about 60–90 words, the claim and the outcome
a 3-minute explanation, about 350–500 words, the why, the how, and the jargon
detailed notes grouped by page, with citations like (p. 4), plus the top takeaways and the questions the document never answers

There is a second mode, "tell me only what I need." You type a goal, for example "I want to deploy this with Docker on a VPS." Each chunk gets a relevance score from 0 to 5. Chunks under the cutoff are dropped. From the rest you get prerequisites, practical steps, the pages that matter, what you can skip, and the gotchas. If nothing scores high enough, it says the document does not cover the goal and shows the closest sections. It does not invent a procedure.

The person who gets to be lazier is anyone with a folder of tutorials, docs, and papers they saved "for later." They can spend a minute on the summary, or ask one question, and only open the original when a page citation is worth it.

The default model is Qwen2.5-3B-Instruct through Ollama. It fits in about 8 GB of RAM, including CPU-only. A 3B model will wander if you ask it for five sections at once, so the pipeline never does that. One job per call. Short prompts. Chunks of about 1,500 tokens. If the chunk summaries still do not fit, they are reduced in rounds until they do. Python then checks the work: word counts, commands that must actually appear in the source, and numbers the document never stated. A fenced command that is not in the PDF is dropped. An inline command that is not in the PDF is marked [unverified].

Demo

Local only. Nothing is hosted, and the document stays on the machine unless you point the base URL at a remote server.

ollama pull qwen2.5:3b
ollama create tldr-qwen -f ollama/Modelfile
export LLM_MODEL=tldr-qwen
tldr summarize examples/docker-vps.md --layer 30s
tldr goal examples/docker-vps.md --goal "I want to deploy this with Docker on a VPS"
tldr ui

tldr-qwen is a one-line Modelfile on top of qwen2.5:3b that sets num_ctx 8192. Ollama's OpenAI-compatible endpoint often ignores a per-request context size and silently cuts the prompt. The derived model is how a small local model gets the whole chunk.

A hand-written sample of the shape of the output, taken from the Docker-on-a-VPS note in the repo, is in examples/sample-output.md. The practical steps from that note are the commands that are actually in the file:

sudo apt-get update
sudo apt-get install -y docker.io
docker compose up -d

Code

AyushyaRanjan / TLDR

tldr-everything

The Reading Debt Killer. Turn a PDF or a long paste into a 30-second summary, a 3-minute explanation, and page-cited notes, or ask for only the parts that match a goal.

The code in this repository is MIT. The default model weights are not. See Model licensing.

Demo

A GIF belongs in docs/screenshots/. Record the Streamlit app on examples/docker-vps.md, save it as docs/screenshots/demo.gif, and drop this line in once the file exists:

![tldr-everything summarizing a short Docker guide](docs/screenshots/demo.gif)

Until then, the sample output below is the shape of a result.

The problem

Tutorials, docs, papers, and long articles pile up unread. Opening one means paying the whole reading cost before you know if it answers the question you saved it for.

tldr-everything cuts that cost into layers. Each layer is its own short model call, because the default model is…

View on GitHub

MIT license. Python 3.10+. PyMuPDF for the PDF, a small Typer CLI (tldr), and a Streamlit UI. The model client is the OpenAI SDK pointed at any compatible endpoint, default http://localhost:11434/v1.

Tests never call the network. A fake client covers cleanup, chunk overlap, the injection guard, length retries, recursive reduce, scanned PDFs, and the "this document does not cover your goal" path.

How I Built It

The open-weight model is Qwen2.5-3B-Instruct, run locally with Ollama. The app talks to it through Ollama's OpenAI-compatible API, so LM Studio, vLLM, or a larger Qwen is a config change. llama3.2:3b is the other small option documented in the README.

The build is arranged around the fact that 3B is small:

Each prompt in prompts.py has one job, three to six rules, one tiny example, and a plain-text format. Relevance comes back as a single line, SCORE: 0-5, parsed with a regex. Garbage input scores 0, so the chunk is dropped.
Document text is wrapped in <document> tags and labeled untrusted. Literal tags inside the file are neutralized first, so a PDF cannot close the delimiter early.
Map calls run a few at a time (LLM_CONCURRENCY defaults to 2). The CLI and the UI share a progress callback and an ETA from the latency actually observed.
After generation, a post-processor strips "Sure! Here is..." and checks length. Outside a tolerant band, it retries once, then keeps the text and raises a warning badge.

PyMuPDF extracts text page by page. Scanned PDFs, which come back nearly empty, get a clear "OCR is not supported" message. Encrypted PDFs are refused. Cleanup de-hyphenates prose and leaves fenced and indented code alone.

Why Does Open Innovation Matter?

The whole point of the tool is unread private reading: papers, internal docs, a tutorial you would rather not upload. A closed API would mean sending that pile to someone else's server, and paying for every chunk. Here the default path is localhost. Logs record call type and timing, not the document. If the base URL is not local, the CLI and the UI say so before the run.

A small open-weight model also forced the design. I could not hide a sloppy prompt behind a huge context window. The Modelfile, the chunk size, the recursive reduce, and the grounding checks exist because Qwen2.5-3B will invent a plausible docker command if you let it. Those checks are ordinary Python. They keep working if you swap the model later.

It also costs nothing to run after the weights are on disk. The same pipeline that summarizes one saved article can sit on a laptop with no key and no meter.

The Lazy Payoff

The app reports both clocks on every run: minutes to read the source at 220 words per minute, and minutes to read the summary. A 4,000-word article is roughly 18 minutes. The 30-second layer is about 80 words, well under a minute, and it cites the page if you want to check a claim.

A preflight log check a drone hobbyist can run on their own laptop

Ayushya Ranjan — Sun, 18 Oct 2026 12:53:19 +0000

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

What I Built

Drone Flight-Log Explainer reads an ArduCopter / Pixhawk .BIN flight log and turns it into a plain-English preflight report.

The person who would pay is a hobbyist who just had a rough flight and does not want to learn a log browser before they fly again. They want a yes-or-no on four things: did the battery sag, did the airframe vibrate hard enough to clip the sensors, did GPS lose a 3D fix, and did the autopilot throw a failsafe. A small repair bench or a club instructor would pay for the same check, so a pilot shows up with a written list instead of a raw file.

The report covers battery voltage, current, and drain; vibration and accelerometer clipping; satellite count and HDOP; autopilot messages, error codes, and mode changes; then a short "inspect before the next flight" list. Every number comes from the log. The wording is not allowed to invent a voltage, a time, or a cause.

A club could charge a few dollars per log, or a shop could include the report with a pack test. The check itself runs locally, so the cost of one report is not an API bill.

Demo

Run it from the project folder:

pip install -r requirements.txt
uvicorn app.main:app --reload

Open http://localhost:8000 and click Try demo flight. That flight is synthetic and already contains a battery sag, a vibration spike, a GPS fix loss, and a battery failsafe that ends in RTL. Uploading a real .BIN uses the same pipeline. No account and no API key are required.

Code

AyushyaRanjan / drone-log-explainer

Drone Flight-Log Explainer

A small web app for hobbyist ArduCopter / Pixhawk pilots. Upload a dataflash .BIN log, or run a built-in demo flight, and get a plain-English diagnostic report covering battery, vibration, GPS, and autopilot warnings.

The analyzer produces every number in the report. The language model only explains those findings. If ANTHROPIC_API_KEY is missing or the call fails, a template writes the same sections so the app still works offline.

Architecture

browser (index.html + Chart.js)
    |  POST /api/analyze  or  POST /api/demo
    v
FastAPI (app/main.py)
    |-- parser.py      pymavlink DF reader -> pandas DataFrame per message
    |-- analyzers/     battery, vibration, GPS, warnings, summary
    |-- report.py      verdict, checklist, downsampled timeseries
    |-- explainer.py   Claude, or the template fallback
    v
in-memory report store, plus JSON under data/reports/

No database. Reports are kept in process memory and written as JSON when the disk is writable.

Run it

pip install -r requirements.txt
uvicorn app.main:app --reload

…

View on GitHub

The app is a small Python service:

app/parser.py reads the dataflash log with pymavlink and builds one pandas table per message type.
app/analyzers/ applies fixed thresholds for battery, vibration, GPS, and warnings.
app/explainer.py writes the English report from those findings. If ANTHROPIC_API_KEY is unset, a template does it.
app/static/index.html draws the charts with Chart.js.

pytest -q covers the demo anomalies, a clean flight, a missing message type, a hand-built .BIN, and the HTTP routes.

How I Built It

The part that makes the product work is open and local. pymavlink decodes the .BIN. pandas and numpy compute the sag fit, the vibration runs, and the GPS fractions. FastAPI serves one static page. Those libraries are what turn a flight log into findings. A closed chat API cannot read a dataflash file, and it should not be the thing deciding that a cell hit 3.28 V.

The English layer is a template filled from the analyzer JSON, so the app works with no model and no key. An optional Claude call can rephrase that same JSON. It receives the summary, findings, and checklist, never the raw log, and the prompt forbids numbers that are not in the data. If the call fails, the template is what the pilot sees.

I used a coding agent in Cursor to build the pipeline. The agent is not in the product. The product a pilot runs is the parser, the rules, and the template.

Why Does Open Innovation Matter?

A flight log is a map of where someone flew, how long they were up, and how the aircraft failed. Uploading that file to a hosted model is a bad default for a hobby tool. Running the parser and the rules on the laptop means the log never leaves the machine, and a useful report does not depend on someone else's per-token price.

The thresholds are in the repo. A pilot can see that "critical" means a cell under 3.3 V, vibration above 60 m/s² for more than two seconds, or a failsafe subsystem. A closed model that summarizes a log in one paragraph can sound confident and still invent a cause. Here the open code produces the findings, and the words are only allowed to explain them.

pymavlink is also the reason this can exist as a side tool at all. ArduPilot's log format is documented and readable because the autopilot stack is open. A closed vendor log would have made the same preflight check a paid black box.

I Made a Game That Only Counts If You Leave the House

Ayushya Ranjan — Sat, 10 Oct 2026 22:42:39 +0000

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

What I Built

I spend most of my day on a screen. So I built Touch Grass, an app that gives me a reason to leave it.

Every morning, you get one outdoor task. "Find moving water." "Say hello to three people you pass." "Pick up ten pieces of litter." You can do it any time that day. Then you take a live photo as proof. A small AI on my laptop looks at the photo, and plain code decides if you passed.

The tasks are not only about nature. Some are about people: ask a shop owner how long they've been open, or ask someone for their favorite place to eat. The goal is to go out, look around, and talk to someone, not just count steps.

Today's task. Anytime today. No timer.

What it does:

40 hand-written tasks in six kinds: nature, movement, exploration, social, creative and community
Live camera only. No gallery, so the proof comes from really being there
If the AI gets it wrong, tap "Mark done anyway" for half points. The app never blocks your streak
Works with no signal. The photo waits on your phone and goes through when you're back online
XP, levels, a daily streak and a monthly count
You choose which kinds of tasks you want more or less of, and how bold the social ones are
Weather-aware tasks, a streak freeze, a daily reminder, a bad-day mode and a monthly recap
It counts its own screen time, because the screen should be the shortest part of the day

It's for people like me who want a small push to go outside, and a little game to keep it going.

No signal? The photo is saved on the phone and waits.

Back online. The laptop checked the photo and the task is done.

Demo

Code

AyushyaRanjan / TouchGrass

Touch Grass

Single-user app that gives you one daily outdoor task (nature, movement, exploration, social, creative, community). You submit a live photo as proof from a mobile app; a laptop server verifies it with a local VLM served by Ollama.

See AGENTS.md for the full spec, hard rules and game/verdict rules.

Prerequisites

uv (Python package manager)
Python 3.11+
Node.js 20+ (for the Expo app in app/)
Ollama running locally with a vision model
```
ollama pull qwen2.5vl:3b
```
Git
Optional: Tailscale so the phone can reach the laptop over HTTPS-grade WireGuard while the app still uses HTTP
Optional: an Expo account if you want a standalone APK (eas build)

Setup

# 1. Install dependencies (creates .venv and uv.lock)
uv sync
# 2. Configure environment
copy .env.example .env   # Windows; use `cp .env.example .env` on macOS/Linux
# Edit .env and set API_TOKEN to a long random string. Never commit .env.

…

View on GitHub

How I Built It

The AI in the app is open and runs on my own laptop. It's an everyday machine: an RTX 3050 with 4 GB of video memory and 16 GB of RAM.

The AI. I used Qwen2.5-VL (3B) through Ollama. It looks at the photo and answers small yes/no questions, like "Is a leaf visible?" It also writes a short note about what it sees, and that note becomes the hint you read in the app.

The rule that made it work: the AI never decides pass or fail. Small AI models like to say yes. So plain code makes the call. You pass only if every required question gets a "yes". That also means nobody can sweet-talk the AI into a pass.

Choosing the model. I ran a quick test on 7 photos:

Model	Right answers	"Not sure" answers	Speed per photo
Qwen2.5-VL 3B	12 of 12	2	3 to 6 seconds
Gemma 3 4B	8 of 10	4	4.5 to 6.5 seconds, but 71 seconds on the first photo, and it crashed once

Gemma also gave "no" answers while its own note said the thing was visible. That's a tiny test, not a benchmark, but it was enough to pick Qwen. Swapping the model took one line.

The rest of the build:

Photo checks come first. Blurry, dark, tiny or repeated photos are stopped before the AI sees them.
Server: Python (FastAPI) and SQLite, running on my laptop.
App: Expo (React Native), built as an Android app.
The link between phone and laptop: Tailscale, a private network between my own devices.
Offline: the phone keeps a queue. It sends photos when it can reach the laptop, and it never sends the same photo twice.
Tasks are written by hand, because a small AI writes vague tasks. The AI only rewrites the wording a little.
Streaks and XP are worked out from my history each time, so they can't get out of sync.
The demo voice-over was made with ElevenLabs.

Being honest about how I built it: I used coding agents (OpenCode and Cursor) to write most of the code, from detailed prompts and a rules file. Those run on hosted models. The AI that runs inside the app is the local one. I built the Android file with Expo's cloud build.

What doesn't work well yet:

Social tasks are checked by the place only. The AI can see the cafe, but not the chat.
The AI is small, so it's sometimes unsure or wrong.
My laptop has to be on for photos to get checked.
Android only.

The app counts its own screen time. That 7 minutes was a testing day.

You decide which kinds of tasks you want more or less of.

Bugs I hit along the way

A tiny photo was stopped in 0.6 seconds. My test photo was only 30 KB. The photo check caught it before the AI even looked, and that's the point of checking first. The message said "move a little closer", which was wrong, because the problem was resolution, not distance. I changed it to say the resolution is too low.
Gemma disagreed with itself. One of the two models I tried said "no" to "is this outdoors?" while its own note said "sky is visible". It also took 71 seconds on the first photo and crashed once. Qwen got every question it answered right and was much faster. That's why I picked Qwen. It was a small test, but the difference was clear.
I typed the model name wrong, twice. My first try at a third model failed with a "not found" error. The tag had a typo. I fixed it and moved on, because Qwen was already doing the job.
A photo of a screen passed the "outdoors" question. I photographed a monitor showing a tree, and the AI said "outdoors". When I asked directly "is this a screen?", it got it right. So the model can tell, I just wasn't asking. For now, spotting screens is only logged. It's a clear next step.
The same note appeared for every question. The small model describes the photo once and pastes that note under each answer. So some hints are less useful than I'd like. A fix would be to ask one question at a time, which costs a few more seconds.
One extra retry made a check take 13 seconds instead of 5. My rule that every note must be at least four words sometimes made the model try again. It's a fair trade for better hints, but I watch it.
Uploads failed with "Unsupported FormDataPart". Expo's network code didn't accept the usual way of sending a photo. The server never saw a request. The app also said "couldn't reach your server" for every kind of error, which was misleading. I switched the upload to a different method and made the error messages say what really went wrong.
My history thumbnails were blank. The image requests didn't carry my token, so my own server said "401 unauthorized" to my own app. I now download each thumbnail with the token and keep a copy on the phone.
The app showed "done" when the server said it wasn't. When I deleted a test photo on the laptop, the phone still remembered it. Today's task showed as finished with no way to upload. I made the phone check with the server and drop items the server doesn't know about, and I added a button to clear the local cache.
The Close button did nothing after an "unsure" result. I tapped it three times. It only went away when I switched tabs. The cause was the screen being redrawn from fresh data, which brought the card back. Closing now takes effect immediately and stays closed.
Expo Go can't open the app in airplane mode. It loads the app from my laptop, so with no connection it can't start. The offline queue works once the app is open. For real use I needed a standalone app that doesn't depend on my laptop.

Why Does Open Innovation Matter?

My photos stay mine. They go from my phone to my laptop and nowhere else. No cloud service ever sees them.
It costs nothing per photo. I can check as many photos as I want, and nobody sends me a bill.
I could swap models in one line. I tried two, looked at the results, and picked the better one.
I set the rules myself: the questions, the exact format the model must answer in, and the code that decides. That's why the AI can't just agree with everything.
The small model made the design better. A bigger closed model might see more detail. But because mine is small, I had to break the job into simple yes/no questions and let code decide. That made the app fairer and easier to trust.

An app that tells you to go outside shouldn't send your photos to a company on the way. This one doesn't.

I Built a Private "Open When" App for a Friend Who Feels Low at Night

Ayushya Ranjan — Sat, 03 Oct 2026 16:18:01 +0000

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

What I Built

OpenWhen is a private comfort app I built for "a close friend", who "often feels low and alone, especially at night".

When you feel low, generic motivational quotes don't help. What helps is hearing from people who actually know you. So the app works like digital "open when..." letters: people who care about my friend (including me) recorded voice notes and wrote messages, each tagged with a feeling. My friend taps how they feel, optionally types a few words, and the app brings back the right message from a real person. A small local AI model writes a one-line, gentle introduction, but it never tries to be the comforter. The comfort comes from people.

It also has:

Log a win: a place for my friend to save things they got through, which the app surfaces on harder days ("Remember this?").
I have a challenge: the AI breaks a problem into one tiny five-minute step.
Saved for later: favorite messages that stay available even when the server is offline. (remove if not built)
A safety layer: if my friend writes something that suggests self-harm, the AI is bypassed completely and the app shows a fixed message with one-tap buttons for Tele-MANAS (14416), my phone number, and 112.

It is a comfort tool, not therapy, and the app says so.

Demo

Code

AyushyaRanjan / OpenWhen

Open When...

Open When... is a small, private web app that keeps a few kind words close by for someone who is having a hard day. When they say how they feel, it shows them a message or voice note from someone who loves them, or one of their own logged wins. It runs entirely on one laptop and talks to no company's servers.

It is built to be read and changed by one person, not scaled. If you are looking for a product, this is not it. If you are looking for something warm, small and yours, it might be.

What it is, and who it is for

The person who uses it is one specific friend who often feels low or alone They open it on their phone or laptop, tap how they feel, and get back something human that already existed — a note from a parent,…

View on GitHub

How I Built It

Everything that touches my friend's feelings runs on my own laptop (i5-12450HX, 16 GB RAM, RTX 3050 with 4 GB VRAM).

Model runtime: Ollama for local inference.
Chat model: [MODEL YOU CHOSE, e.g. qwen2.5:3b], a small open-weight model. I compared [LIST THE MODELS YOU TESTED] on sample inputs and picked the warmest one.
Embeddings: [EMBEDDING MODEL, e.g. nomic-embed-text] for matching a feeling to the right message.
Backend: FastAPI and SQLite, with plain NumPy cosine similarity for retrieval. No heavy vector database was needed.
Frontend: a plain HTML/CSS/JS installable PWA with no frameworks, no CDNs and no external fonts, so it works with zero internet.
Phone access: [HOW YOU DID IT: e.g. Tailscale / Cloudflare Tunnel], with a passcode login (remove if not added).
Built with an open-source agent: I wrote the build as a sequence of prompts and used OpenCode as the coding agent. [MENTION WHICH MODEL POWERED OPENCODE, and note that it only wrote code and never saw my friend's data.]

Design decisions I'm proud of

Retrieval first, generation second. Because the comfort comes from real messages, a small model is enough, and it can't invent a memory it was never given.
Safety runs before the model. Crisis checks use keywords plus an optional model check, and a crisis match never reaches the model. The response is fixed and human-written.
Contributors are never blocked. I first screened loving notes from friends with the same filter, which falsely flagged them. I fixed it so the filter protects what my friend types, and only flags contributor notes for my review.

Honest limitations

A 3B-parameter model is less fluent than the biggest closed models, especially in [Hinglish/Hindi, if relevant].
A keyword safety filter is a minimum safeguard, not a guarantee.
It's only as good as the messages people record, and it can't replace real support.

Why Does Open Innovation Matter?

I couldn't have built this the same way with a closed API.

Privacy: my friend's most vulnerable moments are about as personal as data gets. With an open-weight model on my own laptop, none of it is sent to a third-party server.
Cost: it costs nothing per message, so there's no usage bill and no subscription that could disappear.
Control: I picked the model by testing several, wrote the system prompts myself, and wrote the safety rules myself instead of inheriting a vendor's policy. When the safety filter wrongly blocked a loving note, I could open the code, find out why and fix it.
It keeps working: it runs offline, and the messages and voice notes stay in a plain SQLite file and a folder I can back up. If any company changes its terms tomorrow, my friend's letters are still there.