DEV Community: Divyansh

Siesta: a post planner that tells you when to go back to sleep

Divyansh — Sun, 25 Oct 2026 20:30:04 +0000

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

What I Built

Siesta is a small local app that plans next week's posts while you sleep, and tells you honestly when your own history can't help.

Most "best time to post" tools hand you a confident answer whatever your data looks like. Siesta does the opposite. You give it your post history (a CSV, or public posts from DEV by username or tag). It trains a small logistic regression on your older posts, tests it on your newest 20%, and reports ranking skill (ROC AUC) with a 95% bootstrap range. If that range includes a coin flip, the verdict is "no signal", the drafts stay unranked, and it tells you to go back to sleep.

If there is a signal, you give it a brief (typed, or read from your recent git commits or a notes file) and it drafts a week of posts with titles, tags and outlines. Code, not the model, computes every feature and score. Drafts that don't score Strong get one revision, and the revision is kept only if it scores higher.

Who gets to be lazier: anyone who writes regularly and loses an hour every Sunday to "what do I write, and when?" One run answers both. And when your history shows nothing, it saves you from optimizing noise.

Demo

Siesta runs on your own computer, so there is no hosted link. I kept it local on purpose: your history and scores never leave the machine. The screenshots above come from the built-in demo data, which is made up and has a planted pattern, so the numbers in them are for trying the app only.

To try it in a couple of minutes:

git clone https://github.com/Divyansh0208/Siesta.git
cd Siesta
python -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate
pip install -r requirements.txt
python -m siesta

Then press "Just let me try it" in step 1. No key is needed; without one it uses plain templates for the drafts.

Code

Divyansh0208 / Siesta

Siesta 🌙

Plan next week's posts while you sleep, and find out honestly whether your own history predicts what works. If it doesn't, Siesta says so and tells you to go back to sleep.

Runs on your computer. Drafts come from Google's free Gemini API (free key, no card). No telemetry.

What it does

History. Upload a CSV (a date, a title, a result such as reactions or likes), or pull public posts from DEV by username or tag (DEV's public API needs no key).
Reality check. A small logistic regression learns from your older posts and is tested on your newest 20%. You see ranking skill (ROC AUC) with a 95% bootstrap range, lift for its top 20% picks, and the measured hit rate of its Strong / Toss-up / Weak groups. If the range includes a coin flip, the verdict is "no signal" and drafts stay unranked.
Brief.…

View on GitHub

MIT licensed. Python 3.10+, with numpy, pandas and scikit-learn. The server is the standard library only.

How I Built It

The judge is not the LLM. A logistic regression (C=0.5) on weekday, 4-hour window, title length, question mark, number, tags, reading time and cover image. A gradient-boosting model runs on the same test for comparison and is never used to score. The method is fixed in advance: threshold, tag list and scaling come from training rows only, and seeds and settings are never tuned on results.
The writer is Gemini's free tier. Siesta calls the Gemini REST API over plain HTTPS with no SDK, asks for JSON that follows a schema, and then validates everything. Model output is treated as untrusted: it gets one retry, and nothing numeric is ever taken from it.
Without a key it still works. It falls back to plain templates, so the whole flow runs offline.
The free tier fought back. While testing I hit a 404 on gemini-2.5-flash even though it appeared in the model list, then 503s on an overloaded preview model, then a timeout. So Siesta now lists the models your key can use (stable ones first), retries on rate limits and overload, and moves on to the next model on a 404, 503 or timeout. Only then does it fall back to templates, and the run log says what happened.
Everything else is small. A tiny .env reader, a stdlib HTTP server bound to localhost, a single HTML file for the UI, and 12 tests that need no key.

Why Does Open Innovation Matter?

I want to be straight about this. The drafting step uses a hosted free API, not an open-weight model, so I'm not claiming the model itself is open. My first version used open-weight models through Ollama, and I switched to Gemini's free tier because that's what I could run.

What open innovation made possible here is the part that matters most:

The judge is auditable. A logistic regression you can read, with the same split and settings every run, can show you why it said no. A hosted black box can't.
The code is open and the model is swappable. The model sits behind one small file (siesta/draft.py). Everything the app decides, from the verdict to every score, lives in open code you can read.
Open tooling carried the project. scikit-learn, pandas and numpy do the real work, and DEV's public API needs no key.

The cost is privacy. Gemini receives your brief, your common tags and the draft being revised, while your history stays on your machine. Google may use free-tier prompts to improve its products, so keep secrets out of the brief. I put that in the README on purpose.

The Lazy Payoff

One press of "Draft my week" produces a full week of drafts, each already scored, slotted onto a day and hour, and revised once if it wasn't Strong. In my demo run, two drafts were revised and kept because they scored higher: one went from 61% to 78%, another from 57% to 73%. Those numbers come from the made-up demo data, so they show how the revise-and-keep rule works, not a promise about your posts.

I haven't claimed hours saved, because I haven't measured them on real posting history yet. The honest payoff is smaller and, I think, more useful: it either hands you a week of drafts, or it tells you in one run that your history can't predict anything and you can stop fiddling.

GigLift: Hinglish job requests in, clear briefs out (Gemma + Django)

Divyansh — Sun, 18 Oct 2026 20:01:44 +0000

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

What I Built

A shop owner in India doesn't write a job posting. They send a WhatsApp message: "logo bana do dukaan ke liye, 1500 tak, Friday tak chahiye".

GigLift is a small job board for students that starts from that message. It turns it into a proper brief: what has to be delivered, which skills it needs, a budget, a deadline, and the questions the owner forgot to answer. The owner fixes whatever is wrong and publishes. Nothing is public before that. Students see gigs ranked by how well they fit their profile and send a proposal, and the owner hires one. Phone numbers show up only after a hire, and payment stays between the two people.

The ones who would pay are small business owners, for a logo, a menu card, eight reels edited or forty pages typed. Usually ₹500 to ₹3,000. The side hustle belongs to the student.

I wanted to fix the brief because a message like that leaves out half of what a freelancer needs to know. The student guesses, quotes blind, and the two of them argue about it later. A clear brief at the start costs almost nothing and heads off most of that.

GigLift itself earns nothing. Nobody has paid through it and no real client has used it yet.

Demo

Live: https://giglift-aa4q.onrender.com

It runs on Render's free tier, so the first visit after a quiet spell can take up to a minute, and the data resets whenever I redeploy. The five gigs marked "(demo)" are seeded. The footer says AI: gemma when the model answered and AI: offline when the fallback did.

Two things worth trying:

Click Post a gig and paste logo bana do dukaan ke liye, 1500 tak, Friday tak chahiye. The budget and deadline in the brief should be exactly the ones you wrote.
Post another with no budget, like 4 posters chahiye shaadi ke liye. The price comes back labelled as a rough guess, and the brief asks for your budget and your deadline.

Code

Divyansh0208 / GigLift

GigLift

Small paid jobs for students, posted in plain language. A shop owner pastes a messy WhatsApp-style request ("logo bana do, 1500 tak, Friday tak"). GigLift turns it into a clear brief. Students pitch. The client hires. No accounts, no payment fees, free to run.

Django + HTMX, one stdlib-only AI module, MIT licensed.

Live demo: https://giglift-aa4q.onrender.com (free Render tier: the first visit after idle can take up to a minute, and data resets on each redeploy. The five gigs marked "(demo)" are seeded.)

Status: working prototype, deployed. The full flow, security pass and eval below are real and reproducible. Screenshots and a first real user are next. See the roadmap.

Try

…

View on GitHub

MIT licensed. The README has the setup steps, the eval, and a list of what's still missing.

How I Built It

It's Django with HTMX and SQLite, on Render's free plan. All the AI lives in one file, core/llm.py, standard library only, no SDK. The model is Gemma (gemma-4-26b-a4b-it), called through Google's hosted Gemini API with the same free key. If the key is missing or the call fails, rule-based fallbacks take over and the page says so.

Most of the design comes from one thing I learned early: ask a model for a price and you get a price, even when the client never gave one. So I stopped letting it decide numbers. If the client stated a budget or a deadline, a small set of rules in core/extract.py reads it straight out of the text and the model can't change it. The rules cope with English, Hinglish and Devanagari digits: 1500 tak, ₹१२००, parso, agle hafte, Friday tak. If nothing was stated, the model's number is shown as "Rough guess, not from real prices" and the client is asked. If the model writes a deliverable containing a number that isn't in the client's message, I drop that line. What's left for Gemma is the part rules can't do: understand a Hinglish request and write the deliverables and the open questions.

To check it, I wrote 30 briefs by hand (English, Hinglish, Devanagari) and built the rules on them. Then I froze extract.py, whose hash is in eval/FROZEN.txt, wrote 32 new briefs and scored them once.

Held-out, 32 briefs	Old regex	New rules
Stated budget read right (25)	11	22
Stated budget read wrong	14	0
Budget invented when none given (7)	7	0
Stated deadline read right (27)	8	25
Stated deadline read wrong	19	0
Deadline invented when none given (5)	5	0
Crashes	1	0

Then I ran the whole pipeline with real Gemma behind it, all 32 briefs served by the model: 22 of 25 budgets and 25 of 27 deadlines right, none wrong, none invented. That matches the rules alone, which is the point. Gemma can't change a number the client wrote.

The five misses were paanch hazar (an amount in words), 1800 mein ho jaye, due 25 Oct, and within 48 hours. A miss means the app asks the client. It never shows a wrong number.

What this doesn't show: I wrote both the rules and the test briefs, so the held-out score is optimistic. It also only measures numbers. I haven't scored Gemma's own output yet, meaning the open questions, the skills and the deliverables. That's next, along with real messages from real clients and a delivery check, where the student describes what they handed over and the model marks each deliverable done or missing.

Things that went wrong. My first offline regex crashed on "posters, 4" because it read the "rs" in "posters" as rupees. On Windows my scorer read the briefs with the wrong encoding and mangled the ₹ sign, and the budget score fell from 22 to 16 until I worked out why. Gemma's first replies didn't parse as JSON at all, so for a while every brief quietly fell back to the offline rules and I didn't notice. I rewrote the parser to take the largest valid JSON object in the reply, and the eval now prints which backend actually served the run. I also once posted a screenshot with my API key in it. I revoked it.

I spent an evening on the boring security parts too: a CSP with nonces, rate limits per session and per IP, and ownership checks on edit and hire. There are 24 Django tests, plus 7 more on the rules.

Why Does Open Innovation Matter?

I didn't run a closed model against Gemma, so I won't claim it did better. Here is what open changed for this project.

The design doesn't need a frontier model. Because code decides the numbers, the model only has to read a messy request and write a short brief, and a mid-size open model is enough for that. That makes the model replaceable. I can switch to a different one by changing GEMMA_MODEL.

The money is tight. A job is ₹600. Right now the free API key is what makes a brief cost me nothing, and open weights mean I'm not stuck if that free tier changes. I could run the same prompts on my own hardware.

Privacy matters most to me here, and it's the least finished part. These messages often have a phone number in them. Today the text goes to Google's API, so it leaves my server. With open weights, a shop's message doesn't have to end up inside a closed vendor's system. The Gemma call sits in one function, so pointing it at a model on my own machine means rewriting that function, not the prompts. I haven't built that yet.

Prize Categories

Side Hustle. Gemma is the model, so I'd also like to be considered for any Gemma-related partner category.

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.

DEV Community: Divyansh

Siesta: a post planner that tells you when to go back to sleep

What I Built

Demo

Code

Divyansh0208 / Siesta

Siesta 🌙

What it does

How I Built It

Why Does Open Innovation Matter?

The Lazy Payoff

GigLift: Hinglish job requests in, clear briefs out (Gemma + Django)

What I Built

Demo

Code

Divyansh0208 / GigLift

GigLift

Contents

Try

How I Built It

Why Does Open Innovation Matter?

Prize Categories

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

What I Built

Demo

Code

Divyansh0208 / Tuft

Tuft

How it works

How I Built It

What I haven't tested

Why Does Open Innovation Matter?

Prize Categories

Building a cyclone impact forecaster with only 61 data points

How the pipeline works

Benchmarks

Notes from working with 61 data points

Current limitations

Help wanted

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

What it does

Architecture

The part I'm actually proud of: the guardrails

Stack

What's next

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

🤔 The Problem

⚔️ What is Prompt Forge?

✨ Features

- Responsive — works on mobile and tablet

🛠️ Tech Stack

🧠 How It Works

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

📡 The Key: System Prompt Engineering

🎖️ Warrior Rank System

🚀 Run It Yourself

🔗 Links

- 💻 GitHub: github.com/Divyansh0208/Prompt_Forge

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

The Stack

- Deployed on: Render.com

The Three Pillars

Understand

Track

Reduce

The Hardest Part: LLM Hallucination Guard

htmx for the Category Dropdown

Deployment on Render

What I'd Do Differently

Results