DEV Community: Divyansh

Tuft: a nature quest that turns your screen black, judged by an open model on your own device

Divyansh — Sun, 11 Oct 2026 18:29:59 +0000

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

What I Built

I wanted an app whose best feature is that you stop using it.

Tuft gives you one small quest, like find moss or lichen, find sky between branches, or find a shadow with a shape. You pick 5, 10 or 20 minutes and tap Go outside. The screen goes pure black (off pixels on an OLED phone), the quest is read aloud, and the app disappears into your pocket.

When the timer ends the phone buzzes and talks to you. You take one photo, no retakes. A vision model decides whether it completes the quest, says what it saw, and drops the result into a small field log on your device, thumbnail included.

So the screen only matters for the first ten seconds and the last ten. Everything in between is you, outside.

I made it for anyone who needs a reason to look up for ten minutes, and for a school club or hiking group that wants a tool it can host on its own.

Demo

Live app: https://tuft.onrender.com. On a phone, use Add to Home Screen.

There's also a benchmark page at https://tuft.onrender.com/bench/ for testing the judge on your own photos.

Code

Divyansh0208 / Tuft

Tuft

A quest that ends outside. Tuft hands you a small nature quest, turns your screen black, and tells you to put the phone in your pocket. When time is up you take one photo, and an open-weight vision model on your own device decides if you did it.

Built for the Hacktoberfest 2026 Open-Source AI Challenge, Week 1: Touch Grass.

App: / (single page, no build step, no backend)
Benchmark: /bench/ (measure the judge on your own photos)

How it works

flowchart LR
  quest["Quest<br/>built-in pool, or written by a local model"] --> pocket["Black pocket screen<br/>wake lock, timer, voice cue"]
  pocket --> shot["One photo, no retakes"]
  shot --> judge{"Judge"}
  judge -->|"Ollama reachable"| vlm["Vision model via Ollama<br/>e.g. gemma3:4b"]
  judge -->|"otherwise"| clip["CLIP in the browser<br/>transformers.js, offline after first load"]
  vlm --> verdict["Spoken verdict"]
  clip --> verdict
  verdict --> log["Field log<br/>stored on this device only"]

Pocket screen: pure black (off pixels on…

View on GitHub

No backend, no build step, no framework. It's one index.html, a service worker, a manifest and the benchmark page. MIT licensed.

How I Built It

The judge has two modes. If Ollama is running and has a vision model, Tuft uses it. It picks up Gemma, LLaVA and similar models on its own, and the same model can write new quests. If there's no Ollama, it falls back to CLIP running in the browser through transformers.js.

CLIP compares the photo with the quest description and with six "not this" labels: a room indoors, a computer screen, a face, a plain wall, a road, a blurry photo. The quest passes if its description ranks first or scores above 25%. A second pass picks what the photo shows from eleven nature words, so the spoken verdict can say what it saw. If Ollama dies halfway through, Tuft switches to CLIP instead of showing an error.

The black screen. It's a black overlay plus the Screen Wake Lock API, because phones pause timers and audio when the screen locks. Phones also slow timers down in the background, so when the page comes back, Tuft checks the real clock instead of trusting the timeout.

Offline. A service worker caches the page, the CLIP library and its files the first time they load, and transformers.js caches the model weights. The idea is that after one online run, the judge works with no signal.

A benchmark page. At /bench/ you add photos, tag each one with its quest and whether it truly completes it, and run both judges. You get accuracy with 95% intervals. The page picks a threshold on one half of your photos and tests it on the other half. It also has a "can't tell" band, an exact paired test, and a gallery of every miss. I checked the paired test against counts from another entry in this challenge (19 vs 6 should give p = 0.015) and it matched.

A bug worth telling. An early decorative 3D layer put perspective on the page body. That quietly changes what position: fixed means, so the black screen would have covered the page instead of the whole phone. A black screen that's only partly black defeats the point, so it's fixed in the shipped version.

What I haven't tested

I haven't run a field study, so there are no accuracy numbers in this post. The benchmark page is there so anyone can measure it, including you. I also haven't checked the offline path in airplane mode on a real phone. CLIP matches photos to descriptions, it doesn't know species, and a photo that looks like the quest can fool it. The built-in pool has only ten quests.

Why Does Open Innovation Matter?

The judge should work where the signal doesn't. An app that wants you outside is going to end up somewhere with no bars. A closed vision API is a network call. Tuft's judge is open weights in your browser.
Your surroundings stay yours. Photos are resized and judged on the device. The only network traffic is the first download of assets, plus your own Ollama address if you set one.
Nothing to pay for. No keys, no per-photo cost, no rate limits, no accounts. Any static host works, so a club can run its own copy.
Swapping models is one text field. The CLIP weights are open too, so a hosted model getting retired can't break the app.
The trade-off. Closed frontier models are better at recognising species. I picked "good enough, private, and everywhere" over "best, sometimes", and I'm not claiming open wins on accuracy.

Prize Categories

Best Use of Render: Tuft is a static site on Render. The HTTPS it provides is what makes the wake lock, the service worker and Home Screen install work.

Building a cyclone impact forecaster with only 61 data points

Divyansh — Wed, 30 Sep 2026 19:26:09 +0000

Almost every year, India’s east coast—especially Odisha, Andhra Pradesh, and West Bengal—takes a hit from a cyclone. While plenty of tools show where a storm is heading, very few tell you how many people actually live inside the impact zone. Early on, that district-level exposure is what responders really need to prioritize resources.

I built Cyclone Impact Forecaster to bridge that gap. It combines a 6-hour intensity forecast with a district-level exposure ranking for the North Indian Ocean, rendered on a 3D satellite globe.

Live demo: https://cyclone-forecaster-s015.onrender.com (runs on a free Render instance that sleeps when idle, so the first load takes about 45 to 60 seconds)
Code: https://github.com/Divyansh0208/Cyclone

A simulated storm placed by hand at 17.2 N, 84.5 E (80 kt), taken on a quiet day when no real storm was active.

How the pipeline works

Ingesting storm state: Live storms in the North Indian Ocean are pulled from NOAA's IBTrACS ACTIVE file (using JTWC fixes). Because the basin isn't always active, I also built modes to replay historical cyclones or drop a custom storm onto the map by hand.
6-hour intensity forecast: An XGBoost model predicts the change in wind speed over the next 6 hours based on current position, wind, central pressure, and their recent trends.
District exposure model: To estimate human impact, I fitted a 2-parameter log-linear model on 61 historical Indian cyclone records from EM-DAT, combined with Census 2011 district populations and areas. It outputs expected people affected along with a 10-90% prediction interval for every district inside the impact radius.
3D visualization: Built on MapLibre GL with satellite imagery and terrain elevation. District markers scale with the estimated affected population, and clicking any district flies the camera down to inspect it.

All of this runs strictly on real datasets—IBTrACS (NOAA NCEI) for tracks, EM-DAT (CRED) for the 61 historical impact records, and the 2011 Census of India. I avoided synthetic data completely; even the test suite runs against a real track excerpt from Cyclone Fani.

Benchmarks

Metric	Model	Naive Baseline
Intensity MAE (6 h)	3.04 +/- 0.20 kt	3.49 kt (persistence / last value)
Impact log-MAE	2.50 +/- 0.41	2.69 (historical mean)

For the intensity model, I used 5-fold cross-validation grouped by storm, beating the persistence baseline across all 5 folds. For the impact model, I ran 5-fold CV with 20 repeats on the log scale.

Notes from working with 61 data points

Complex models overfit fast on small disaster datasets. When I first threw a RandomForest at the EM-DAT impact data, it performed worse than simply predicting the historical mean. Stepping back to a 2-parameter log-linear model actually generalized. I even ended up fixing the population density coefficient at 1 (letting it fit freely gave about 1.08, so locking it simplified the model with zero performance penalty). The improvement over the baseline is still modest, so I make that explicit in the UI.
Random train/test splits cheat on track data. Consecutive 6-hour fixes from the same cyclone look nearly identical. If you do a standard random split, adjacent points end up in both train and test sets, inflating your metrics. Grouping cross-validation folds strictly by storm ID is the only honest way to evaluate it.
Don't hide wide error bars. In the screenshot above, the top-ranked district's 10-90% range spans from roughly 17,000 to 2.2 million people. That looks massive, but that's the reality of training on 61 noisy historical events. Rather than pretending the point estimate is exact, the UI frames the output as a relative ranking across districts and keeps the error band front and center.
Be transparent about data lag. The upstream IBTrACS ACTIVE file only rebuilds about three times a week, meaning "live" data can lag by up to two days. The backend caches responses for 15 minutes, falls back to stale data if NOAA's upstream fails, and badges every fix in the UI with its exact age.
Keep training and serving feature logic in one place. Both the offline training scripts and the live API import from a single features.py module so feature engineering can't silently drift between the two.

Current limitations

No track or landfall forecasting yet: Every district inside the impact radius currently receives the same predicted storm wind rather than a distance-decayed wind field.
Outdated census boundaries: Relying on the 2011 Census means the population figures are 15 years old and several newly carved-out districts aren't represented.
Wind scale mismatch: JTWC reports 1-minute sustained winds, whereas the India Meteorological Department (IMD) uses a 3-minute averaging period, making storm category labels approximate.
Not an official warning system: This is an experimental decision-support project. IMD is the sole official authority for cyclone warnings in India.

Help wanted

I have 13 open issues on GitHub—several tagged good first issue—covering a proper distance-decay wind field, better calibration for the 10-90% interval, post-2011 district boundaries, regional language support (Hindi, Odia, Telugu, Bengali), and an accessibility audit.

If you work in disaster response, hydrometeorology, or geospatial ML, I’d really appreciate your critique on what would make this genuinely useful in the field.

Sahayak — An AI Legal Assistant That Says "I Don't Know" When It Should

Divyansh — Sun, 27 Sep 2026 19:54:40 +0000

Legal help is expensive, jargon-heavy, and often out of reach for people who need it most. For PromptWars: Virtual (Exclusive Edition) — a hackathon by Hack2Skill — I built Sahayak, a RAG-based legal assistant that answers questions and summarizes documents in plain language, grounded in real context instead of confident guesses.

🔗 Live: https://legal-ai-eight-liart.vercel.app/
🔗 Code: https://github.com/Divyansh0208/Legal-AI (MIT)

What it does

Ask — a tenancy, consumer-rights, or contract question. Answers are retrieved from indexed context, not hallucinated. No matching context? It says so, instead of guessing.
Upload — a PDF (scanned or native) → plain-language summary: what kind of document it is, what it obligates you to, what's worth double-checking.
Voice — ask by speaking, transcribed via Whisper. Every response is grounded in retrieved context and explicit about what it can't confirm — no confident guessing when the docs don't cover something.

Architecture

User (voice/text/doc)
      │
      ▼
React + Vite Frontend
      │  REST
      ▼
FastAPI Backend
      ├─► Groq Whisper API      (speech-to-text)
      ├─► PyMuPDF + pytesseract (parsing / OCR)
      ├─► sentence-transformers (embeddings)
      ├─► ChromaDB              (vector retrieval)
      ├─► Groq LLM API          (answer generation)
      └─► SQLite                (app data)

The RAG hot path is intentionally thin — no framework ceremony for a single retrieval + one chat completion call:

def answer_question(question: str) -> dict:
    hits = retrieve(question)
    context = "\n\n---\n\n".join(h["text"] for h in hits) if hits else ""
    completion = _client.chat.completions.create(
        model=settings.GROQ_LLM_MODEL,
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": RAG_ANSWER_TEMPLATE.format(context=context, question=question)},
        ],
        temperature=0.2,
        max_tokens=800,
    )
    return {"answer": completion.choices[0].message.content,
            "sources": [{"source": h["source"], "distance": h["distance"]} for h in hits]}

The part I'm actually proud of: the guardrails

Anyone can wire an LLM to a text box. The parts that took real effort:

Untrusted-context system prompt — uploaded documents and retrieved chunks are treated as data, never instructions. Prompt-injection resistant by design.
Real upload validation — python-magic sniffs actual file bytes; a relabeled .exe doesn't sneak through as .pdf.
Rate limiting — slowapi on query, upload, and voice endpoints.
Security headers — CSP, X-Frame-Options, HSTS in production.
5 CI workflows on every push — lint, pytest, bandit (SAST), gitleaks (secrets), pip-audit (deps), axe-core (a11y) — auto-deploy to Render/Vercel on merge to main. None of that shows up in a demo GIF. All of it is why the demo GIF is trustworthy.

Stack

Layer	Tech
Backend	FastAPI
LLM	Groq (`openai/gpt-oss-120b`)
Retrieval	ChromaDB + sentence-transformers (`all-MiniLM-L6-v2`)
Parsing	PyMuPDF, pytesseract
Speech	Groq Whisper
Frontend	React + Vite, Tailwind
DB	SQLite
Deploy	Render + Vercel

What's next

Multi-language support (deferred)
Persisted chat sessions (currently in-memory)
More jurisdiction-specific templates If you've hit a real legal-access gap, or want to poke holes in the grounding/refusal behavior — feedback welcome. MIT-licensed, issues/PRs open.

I Built a Prompt Forging Engine with NVIDIA Llama 3.1 70B for Google Prompt Wars 2026

Divyansh — Wed, 24 Jun 2026 19:08:25 +0000

What if you could take any weak, vague prompt and instantly transform it into an elite, production-ready one — with a power score, technique breakdown, and warrior rank?

That's exactly what Prompt Forge does.

🤔 The Problem

Most people use AI wrong. They type something like:

"Write me a blog post about productivity"

And wonder why the output is generic. The secret isn't the model — it's the prompt. A better prompt unlocks dramatically better results.

But most people don't know how to write better prompts. That's the gap Prompt Forge fills.

⚔️ What is Prompt Forge?

Prompt Forge is a single-page web app that transforms weak prompts into elite, production-ready prompts using NVIDIA Llama 3.1 70B via the NVIDIA NIM API.

You paste a rough idea → hit Forge It → get back:

A rewritten prompt (3–8× more detailed)
Which of 8 prompt engineering techniques were applied
A Power Level score from 1–10
A Warrior Rank (Recruit → Bronze → Silver → Gold → Legendary)
A Warrior Analysis explaining every upgrade made 🔗 Try it live →

✨ Features

Prompt Forging Engine — rewrites weak prompts using Llama 3.1 70B Instruct
8 Technique Tags — Context · Specificity · Constraints · Output Format · Persona · Examples · Chain-of-Thought · Negatives
Power Level Meter — 10-bar visual indicator (1–10)
Warrior Rank System — gamified ranking based on power level
Warrior Analysis Panel — explains every improvement made
Typewriter Animation — forged prompt streams in dramatically
One-click Copy — instantly copy the result
Keyboard Shortcut — Ctrl+Enter / Cmd+Enter

- Responsive — works on mobile and tablet

🛠️ Tech Stack

Layer	Technology
Frontend	Vanilla HTML / CSS / JavaScript
Backend	Python + Flask
AI Model	NVIDIA Llama 3.1 70B Instruct
API	NVIDIA NIM API
Hosting	Render

Deliberately kept the stack simple — no React, no heavy frameworks. Just a single HTML file on the frontend and a lightweight Flask proxy on the backend.

🧠 How It Works

The architecture is straightforward:

User Input → Flask Server → NVIDIA NIM API → Llama 3.1 70B → Structured JSON → UI

User enters a weak prompt
Frontend sends POST /api/forge to Flask
Flask forwards to NVIDIA NIM API with a system prompt instructing Llama to act as a master prompt engineer
Model returns structured JSON:

{
  "forged_prompt": "...",
  "techniques_used": ["Context", "Specificity", "Persona"],
  "power_level": 8,
  "analysis": "Added role context, specified output format..."
}

5. Frontend renders with typewriter animation, technique tags, power meter, and warrior rank

📡 The Key: System Prompt Engineering

The magic is in the system prompt sent to Llama 3.1 70B. It instructs the model to:

Act as a master prompt engineer
Identify weaknesses in the input prompt
Apply specific prompt engineering techniques
Return a structured JSON response with the forged prompt, techniques used, power level, and analysis The model essentially uses prompt engineering to improve prompts — meta, but incredibly effective.

🎖️ Warrior Rank System

Power Level	Rank
1–2	🪖 RECRUIT
3–4	🥉 BRONZE
5–6	🥈 SILVER
7–8	🥇 GOLD
9–10	🏆 LEGENDARY

🚀 Run It Yourself

git clone https://github.com/Divyansh0208/Prompt_Forge.git
cd Prompt_Forge
pip install flask python-dotenv requests
cp .env.example .env
# Add your NVIDIA API key to .env
python server.py

Get a free NVIDIA API key at build.nvidia.com.

🔗 Links

🌐 Live Demo: prompt-forge-o970.onrender.com

- 💻 GitHub: github.com/Divyansh0208/Prompt_Forge

Built for Google Prompt Wars 2026. Try forging your weakest prompt and see what rank you earn ⚔️

How I Built a Carbon Footprint Tracker with Django + NVIDIA NIM

Divyansh — Wed, 24 Jun 2026 16:01:00 +0000

I wanted to build something that mattered. Climate change is one of those topics where awareness is the first barrier — most people don't know their actual footprint. So I built Carbon.Ledger: a full-stack web app that lets you log activities, see your CO₂ impact, and get AI-powered tips to cut back.

Here's how I built it, what went wrong, and the one engineering decision I'm most proud of.

The Stack

Backend: Django 5
Frontend: Tailwind CSS + htmx + Chart.js
LLM: NVIDIA NIM — mistralai/mistral-large-3-675b-instruct-2512
Database: SQLite (dev) / PostgreSQL (prod)
Cache: Redis (prod)

- Deployed on: Render.com

The Three Pillars

The app is built around one simple loop:

Understand → Track → Reduce

Understand

Users can read lesson articles, browse a glossary (CO₂e, Scope 1/2/3, Net Zero), and ask free-text climate questions via an LLM-powered Q&A — rate limited to 10 questions/day.

Track

An activity logging form lets users log transport, energy, food, and goods. CO₂ is auto-computed on save using emission factors stored in the database — no LLM involved here. The dashboard shows a 30-day breakdown with a Chart.js donut chart and progress against a monthly goal.

Reduce

Rule-based insights compare the user's totals against national average benchmarks. The top emission category drives filtered recommendations. And once per day, the LLM generates a personalized tip — cached 24h per user.

The Hardest Part: LLM Hallucination Guard

This is the part I'm most proud of.

LLMs make up numbers. That's a real problem when you're talking about emissions data — if the model says "beef produces 5 kg CO₂ per kg" when the real figure is 27, that's actively harmful misinformation.

My solution in services/llm.py:

def _contains_hallucinated_numbers(response: str, context: str) -> bool:
    """
    Extract all numbers from the LLM response.
    Check every one of them exists in the context we provided.
    If not → hallucination detected.
    """
    import re
    response_numbers = set(re.findall(r'\d+\.?\d*', response))
    context_numbers = set(re.findall(r'\d+\.?\d*', context))
    return not response_numbers.issubset(context_numbers)

The flow:

Call LLM with context (user's actual data)
Extract all numbers from the response
Check every number exists in the context
If not → retry with explicit "do not use numbers" instruction
If still fails → return a safe static fallback message On top of that: timeout=10.0 and max_retries=1 are explicitly set to prevent hung Gunicorn worker threads on slow LLM responses.

Key principle: the LLM is never used for calculations. All math is Python/DB.

htmx for the Category Dropdown

The activity log form has a dependent dropdown — selecting a category dynamically loads the relevant emission factors. I used htmx for this instead of writing custom JavaScript:

<select name="category" 
        hx-get="/factors/"
        hx-target="#factor-select"
        hx-trigger="change">

One attribute. No JS file. The server returns a partial HTML snippet with the filtered factors. This is exactly what htmx is built for.

Deployment on Render

Render makes Django deployment straightforward. A few Django-specific things worth noting:

# settings.py
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
SECURE_SSL_REDIRECT = not DEBUG
SESSION_COOKIE_SECURE = not DEBUG
CSRF_COOKIE_SECURE = not DEBUG

Render terminates TLS at the proxy level, so SECURE_PROXY_SSL_HEADER is essential — without it Django won't recognize HTTPS requests and will redirect loop forever.

Also: randomize your admin URL via env var:

ADMIN_URL = env('ADMIN_URL', default='admin/')

Stops bots from hammering the default /admin/ endpoint.

What I'd Do Differently

Async LLM calls. Right now the LLM calls are synchronous — a slow NVIDIA NIM response blocks a Gunicorn worker. The fix is Celery + Redis for background tasks. I skipped it for the MVP but it's the first thing I'd add.

Audited emission factors. The 22 factors I seeded are approximations from public sources, not peer-reviewed figures. For a production app, you'd want to integrate a verified dataset like the UK Government GHG conversion factors.

Email verification. Currently anyone can sign up with any email. Not a problem for an MVP, but a real gap.

Results

146 tests, 99% coverage
Deployed and live
Built in under a week

🔗 Live demo: carbon-footprint-awareness-4qpf.onrender.com

🐙 GitHub: github.com/Divyansh0208/Carbon-Footprint-Awareness

If you're building something with Django + LLMs, the hallucination guard pattern is worth stealing. And if you have thoughts on better emission factor datasets, I'd love to hear them in the comments.