DEV Community: Vineet J Karni

CloudSea: a sunrise forecast for Nandi Hills

Vineet J Karni — Sat, 10 Oct 2026 10:12:35 +0000

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

What I Built

Every weekend, thousands of people in Bangalore set an alarm for 3:30 AM and ride 60 km north to Nandi Hills. The hope is to stand at 1,478 m as the sun comes up over a sea of clouds, with the plains buried under white and only the neighbouring hilltops sticking out. Some mornings you get that. Many mornings you get grey haze, a clear view of fields, or fog so thick you can't see the railing. Whether it's worth going is a coin you toss at bedtime.

I live in Electronics City, 80 km and an hour and a half from the hill, so I can't go every weekend to find out. Instead I built CloudSea, which makes the call the night before and lets the people who are at the top tell it whether it was right.

At 8:30 PM every night CloudSea publishes GO, MAYBE or SKIP for tomorrow's sunrise, with the chance of a cloud sea, the sunrise time, when to leave your area, and what to carry. At sunrise, people at the summit can upload one photo; an open model rates it and they confirm the rating with one tap. At 8:15 AM the app grades its own call against the airport's dawn reports and those photos, in public.

The live app on 10 Oct. The call shown is a daytime test run (issued 2:44 PM); the nightly job publishes the real one at 8:30 PM.

Demo

Live app: https://cloudsea-web.onrender.com. Install it as a PWA on your phone.
How it works and the backtest: https://cloudsea-web.onrender.com/#/how

The call is short enough to read half asleep, and it's written by Gemma in English, Kannada and Hindi:

Sharing is one tap. The server draws the card for WhatsApp and Instagram stories:

How I Built It

flowchart LR
  IEM["Airport reports<br/>(Iowa Env. Mesonet)"] --> N["nightly job<br/>20:30 IST"]
  OM["ECMWF run<br/>(Open-Meteo)"] --> N
  N <-->|features → probability| T["TabPFN"]
  N <-->|4 tools → call text| G["Gemma 4 E2B<br/>on CPU (Ollama)"]
  N --> DB[("Postgres")]
  P(("people at<br/>the summit")) -->|photo| A["API"] -->|rate| G
  A <--> DB
  GR["grader<br/>08:15 IST"] --> DB

Everything runs on Render in Singapore, from one render.yaml Blueprint:

a static PWA and a FastAPI service;
a private service running Ollama with Gemma 4 on CPU, with its weights on a persistent disk;
two cron jobs, one at 8:30 PM for the call and one at 8:15 AM for grading;
Postgres.

The cron jobs reach Gemma over Render's private network.

TabPFN makes the forecast. The training set is small: about 2,000 labelled days, and only two fog seasons have the forecast-model features that existed on the night. TabPFN is a tabular foundation model made for that size, with no tuning: rows in, probability out. It only sees what existed at 8:30 PM: airport reports up to 7:30 PM and the 00 UTC ECMWF run of that day. A test scrambles everything after the cut-off and fails if any feature changes. It caught a real bug when I moved the cut-off and forgot the rain window.

Gemma 4 does four jobs with one small model. It's the E2B variant at 4-bit, a 4.6 GB download:

The call. An agent with four tools (get_forecast, get_sunrise, get_leave_by, get_conditions) writes four short sentences.
A guardrail on the call. It checks every number against the tool results, and that each number sits in the right place. The sunrise time has to be in the sunrise sentence, the leave-by time in the leave sentence, and the probability on "chance of a cloud sea". A draft that fails is retried; after three failures a template goes out. The placement check came from reading golden-hour: a go-outside planner where a small local Gemma cannot invent numbers by @sansk_ya. It shows how "is this number somewhere in the facts" passes swapped values, and mine did too.
Photo rating. Gemma rates each summit photo into strict JSON: cloud sea, partial, clear, or socked in. It answers evidence questions first (are nearby trees hazy? is the ground visible below?), which took agreement with my reference labels from 3/11 to 7–8/11.
Kannada and Hindi. Every number must match the English before a translation is shown.

Open data feeds it:

Airport reports for Kempegowda airport (VOBL) back to 2008, from the Iowa Environmental Mesonet.
One archived ECMWF run per day since March 2024, from Open-Meteo.
Drive times from OSRM on OpenStreetMap.

Why open matters here

The model sits next to the data, with no per-token bill. The whole stack is about $150 a month on Render, and most of that is the Gemma box. A nightly call takes 12 seconds on 2 CPUs.
When Gemma got something wrong, I could see exactly what it was sent and what it said back. For a SKIP at 8% it once wrote "GO, 0%" three times in a row. The guardrail threw all three away. Reading the raw exchange is how I found the guardrail's own bug: the degree sign in "17°C" was escaped into a code ending in 00b0, which quietly made "0" and "00" allowed numbers.
One small open model covers text, tool calls, vision and two Indian languages, so one private service is enough.
Photos stay on my server. They're private by default, and all EXIF, including GPS, is stripped before storage. No photo goes to a third-party model.

The honest part: an airport is not a mountain top

There is no weather station on Nandi Hills. The nearest one that reports every half hour is the airport, 19 km away and 563 m lower. So "was there a cloud sea at Nandi at sunrise?" has to be estimated. I defined it as:

at least two of the airport's dawn reports show fog, visibility under 1,500 m, or cloud at or below 1,000 ft;
no rain;
the air at summit height isn't saturated. This last part separates fog below you from standing inside the cloud.

Then I checked it against real photos. Wikimedia Commons has 94 photos of Nandi Hills whose camera clock says they were taken between 5 and 9 AM. On 31 of those mornings you can see the view below.

When the airport rule said "sea", the photos agreed 5 times out of 6.
It caught 5 of the 9 cloud seas in the photos.
It never fired on the 6 mornings when the summit was inside the fog.

That's a small sample, labelled by me, so it's a sanity check, not proof.

The proxy can't see how thick the layer is, valley fog north of the hill, or fog that forms after 7:30. That's why the app collects summit photos and grades itself every morning against both the airport and the photos. Once two or more people agree on what they saw, their answer replaces the airport's in the training data.

Results

Backtest on the 2025-26 fog season. The model never saw these 151 nights; there was a cloud sea on 35% of them.

	Brier (lower is better)	ROC-AUC
TabPFN, airport + ECMWF (live model)	0.147	0.87
Gradient-boosted tree, airport + ECMWF	0.144	0.87
TabPFN, airport only	0.177	0.80
Gradient-boosted tree, airport only	0.201	0.72
Monthly climatology	0.204	0.70
Persistence (tomorrow = this morning)	0.223	0.64
Hand rule (moist, calm, clear evening)	0.250	0.53
ECMWF's raw dawn low-cloud forecast	0.398	0.55

Going on all 43 Saturday and Sunday mornings would have meant 43 trips and 17 cloud seas. Going only when CloudSea said GO: 12 trips and 10 cloud seas. Staying home on SKIP would have missed 1.

What I didn't expect:

TabPFN and the gradient-boosted tree tie once the forecast-model features are in. TabPFN's advantage shows where data is thin. Season by season, each season predicted only from earlier data, it had the better Brier score every time (0.208 vs 0.260 in 2022-23, trained on 547 rows).
The latest season was the easy one. Earlier seasons scored AUC 0.72, 0.55 and 0.74, so I expect live skill below the headline.
The probabilities are a bit timid. Nights it gave 10–30% had a cloud sea only 3–7% of the time, and all 14 nights it put above 80% had one.

Gemma 4 E2B, same model and prompts on both machines:

	MacBook M2, 8 GB (Metal)	Render 2c-8g (CPU)	Render 4c-8g (CPU)
Generation	22–28 tokens/s	6.1 tokens/s	6.4 tokens/s
Nightly call (agent, 4 tools)	2–3 s	11.8 s	10.9 s
Rate one photo	~4 s	29.8 s	30.3 s
Cost	the laptop	$135/month	$175/month

Doubling the cores bought 5%, so the cheaper box is the right one.

Taking it outside, remotely

I couldn't get to the hill this weekend, and the app went live the day before the deadline, so nobody has used it at the summit yet. Instead I tested it against people who had already been up there and shared their photos.

Wikimedia Commons has Nandi Hills photos whose camera clock places them at dawn. For 30 mornings between 2012 and 2020 you can see what the view below looked like. I ran CloudSea's model on each of those mornings, using only the airport reports from the evening before. It was the airport-only version, because the archived ECMWF runs start in 2024, and it was trained only on 2021–2025, so it had never seen any of these days.

It ranked the mornings well enough to be useful: ROC-AUC 0.71. Cloud-sea mornings got 25% on average, the rest 12–15%.
It said GO once, and that morning was a cloud sea. It never said GO on a clear morning or one inside the fog.
It missed 4 of the 10 cloud seas with a SKIP. Most fell in months it treats as off-season (March, May, August). On one there was nothing at the airport at all, probably valley fog it can't see. That is the gap the photo uploads are meant to close.


6 Jan 2017, cloud sea. CloudSea: GO, 67%. Photo by RITWIK J, CC BY-SA 4.0	13 Jan 2019, cloud sea. CloudSea: MAYBE, 48%. Photo by Sidhant Soni, CC BY-SA 4.0

6 Mar 2016, cloud sea. CloudSea: SKIP, 11%, a miss. Photo by Sri chakra pranav, CC BY-SA 4.0	7 Jun 2016, inside the fog. CloudSea: SKIP, 2%. Photo by Shravan Kamath94, CC BY-SA 4.0

This morning, 10 Oct. Using only the evening of 9 Oct, the live model (airport + ECMWF) says SKIP, 7%. The grader, run this afternoon on this morning's airport reports, says no cloud sea: visibility 4 km in mist, no low ceiling, summit-level humidity 64%. One real call, and it was right. The first scheduled call goes out at 8:30 PM tonight, and the scoreboard at https://cloudsea-web.onrender.com/#/scoreboard fills from 8:15 AM tomorrow, right or wrong.

Things that went wrong

A sentence can be numerically right and still wrong. One draft said "Leave Electronics City by 03:40 from the parking area". Gemma had pulled "parking" from the what-to-carry list. The prompt now fixes the order of four sentences.
Translation needed a glossary. Without one, Gemma's Kannada turned "cloud sea" into "cloudy weather" and read "Sun" (Sunday) as "evening".
Visibility in miles. The archive stores visibility in statute miles, so a reported "1500 m" comes back as 1497 m and slipped under a "< 1500 m" rule. I found it by reading example days, not from a metric.
The forecast-model archive I first planned to use would have flattered the model. Open-Meteo's historical-forecast API stitches together the first hours of each run, which is close to what actually happened. I switched to the archive of single runs, which only goes back to March 2024.

Code

https://github.com/vineetjk/CloudSea (Apache 2.0)

make help lists every step, from data download to backtest to deploy.
71 Python tests (label, leakage, guardrail, translation, EXIF stripping, API) and 24 frontend tests.
BUILD_LOG.md has every decision, dead end and number with a timestamp.

What's next

Collect summit photos through the fog season and retrain on photo-confirmed labels.
Web push for "GO tonight".
More hills with the same problem: Skandagiri, Makalidurga.
Check the Electronics City drive time and the gate opening time on a real trip. Both are marked as estimates in the app.

AI assistance

I built this with Claude Code, an AI coding agent, as my pair. I wrote the brief and its rules: open models and open data doing the real work, no closed model APIs, no invented data, and an honest account of what the proxy can't see. The agent wrote much of the code, did much of the research, and proposed the cloud-sea label and the GO/SKIP thresholds from the data when I asked it to run every phase; the reasoning is in BUILD_LOG.md. Every number above comes from code in the repo.

Partner tech: Gemma 4 (Google), TabPFN (Prior Labs), Render, Entire. Weather data by Open-Meteo.com; airport reports via the Iowa Environmental Mesonet. A forecast, not a guarantee.

I built a city on my GitHub profile. It grows every time I commit.

Vineet J Karni — Wed, 07 Oct 2026 19:12:23 +0000

My GitHub profile is a city now. It's called Commit City, it looks a lot like Bengaluru, and it gets a little bigger every time I commit.

vineetjk (Vineet J Karni) · GitHub

Best things need time! . vineetjk has 80 repositories available. Follow their code on GitHub.

github.com

Earlier this week I turned my contribution graph into a Namma Metro train. It ran on a viaduct past a flat skyline that didn't mean anything. A metro line needs a city around it, so I built one, and I made every piece of it out of my GitHub data.

What's in the city

Each named building is one of my public repos, with the repo's name on a sign on its roof.
Repos I pushed to in the last four months are glass towers. The ones from the last two years are apartment blocks with black water tanks on the roof, like most apartment blocks in Bengaluru. Older repos are small houses with red Mangalore-tile roofs.
The more I committed to a repo this year, the taller its building is and the more of its windows are lit at night.
The metro train is still my contribution graph: one coach per week and one window per day.
Every pull request I merged this year is a BMTC bus, with the repo and the PR number on its LED board. Each bus drives near the week it was merged, and the newest one waits at the bus stop.
My DEV posts fly over the city as banners towed by small planes.
Every week owns the stretch of road under its coach, and that stretch is as busy as the week was. A week with lots of commits has a crowded footpath and a cyclist. A week with none is nearly empty.

Next to the metro station there's a darshini, one of the stand-up coffee and tiffin places Bengaluru runs on, and the signs are in Kannada and English.

It grows

The city starts small and fills in as my all-time contributions add up. The first building cost 25 contributions, and each one after that costs 5 more than the one before:

export const buildingCost = (k, rules) => rules.buildingBase + rules.buildingStep * (k - 1);

let buildings = 0;
let spent = 0;
while (buildings < rules.maxBuildings && spent + buildingCost(buildings + 1, rules) <= contributions) {
  spent += buildingCost(buildings + 1, rules);
  buildings++;
}

So the city filled in quickly at first, and now it grows more slowly. When I took these screenshots I had 925 contributions since 2018, which buys 15 buildings. The 16th is a construction site with a crane and a board that said it needed 75 more. By the time I finished writing this post it needed 67. The busiest repos get the plots next to the metro station, and the rest line up further back along the line, so the ride goes from the outskirts into downtown.

Some things only show up at milestones: the darshini at 100 contributions, autos at 300, the BMTC buses at 500 and the planes at 600. There's a new tree for every 20.

The biggest one is the town hall, Commit Soudha, a mock of Bengaluru's Vidhana Soudha. Work on it starts at 800 contributions and it opens at 1,500. In these screenshots it's 18% built, so you see a blueprint of the whole building with the walls going up inside it, two cranes and a site board. The real Vidhana Soudha has "Government work is God's work" written over its entrance. Mine says ಕಮಿಟ್ ಕೆಲಸ ದೇವರ ಕೆಲಸ, "commit work is God's work".

Here's the same city at 300, 1,000 and 2,000 contributions. The last two are still ahead of me:

The city never shrinks. Every run saves the highest all-time total it has seen, so a repo going private or a count coming back a bit lower doesn't knock buildings down.

The sky follows Bengaluru

The light changes with the time in Bengaluru: dawn from 05:30, day from 07:00, dusk from 17:45 and night from 19:00. At night the windows light up, the streetlights come on, the cars get headlights and the cranes get red warning lights. Your GitHub theme doesn't change the sky. It only changes the frame around it.

The ride

Like the metro panel before it, the city loops every 90 seconds. It rests on Commit Street, fades back a year, and then the camera rides along the line to today, past every week of the year.

The city is drawn in three layers that move at different speeds. The far skyline moves at 30% of the camera's speed, the buildings at 75%, and the line and the street at full speed. That's most of what makes it feel like a real place instead of a flat picture. This is the last few seconds of the ride, arriving downtown:

How it works

Still one SVG

GitHub doesn't run JavaScript in a README, so like everything on my profile, the city is an SVG loaded through an <img> tag and animated with CSS. A Node script draws it from my data on GitHub Actions and commits it. It comes to about 270 KB and around 3,000 shapes. Anything that repeats along the street, like pillars, kerbs, hedges and streetlights, is an SVG pattern, so a longer street doesn't cost more.

The far layer moves by a fraction of the camera's offset. The buildings need one more step: they have to line up with the street exactly when the camera rests on Commit Street, so their offset is measured from there:

const pan = {
  near: (u) => panAt(u),
  mid: (u) => panAt(last) + PARALLAX.mid * (A - world(u)),
  far: (u) => panAt(u) * PARALLAX.far,
};

u is the week in focus and A is where Commit Street is. Each of these becomes a CSS keyframe animation with the same timing as the train, so everything stays in step.

Timing the buses

A bus can't drive forever. It has to loop, and if it jumps back to the start while the camera is looking at it, you see it teleport. So every vehicle drives a stretch of road around its spot, once per 90-second loop, and the loop is timed so the vehicle is in the middle of its stretch at the moment the camera passes:

/** A vehicle loop that is mid-stretch at time `at` (seconds), its spot being (x, y). */
function vehicle(kind, dir, x, y, at, extra = '', attrs = '') {
  const delay = (((at - DURATION / 2) % DURATION) + DURATION) % DURATION - DURATION;
  return `<g class="mv ${kind}${dir > 0 ? 'R' : 'L'}" style="animation-delay:${n(delay)}s"><use href="#${kind === 'cycle' ? 'cyc' : kind}${dir > 0 ? 'R' : 'L'}" x="${n(x)}" y="${n(y)}"${attrs}/>${extra}</g>`;
}

at comes from the camera's keyframes. The jump back happens 45 seconds later, when the camera is on the other side of the year. Walkers don't need any of this. They stroll a few steps one way, turn around and come back, so their loop has no jump at all.

It works. When the camera reaches July, the buses for the Alpha-Fin PRs I merged that week are right there under the gantry signs:

India drives on the left, so traffic on the far side of the road heads right and traffic on the near side heads left.

Kannada in an SVG

An SVG in a README can't load web fonts, so every font has to be embedded. Noto Sans Kannada is far too big for that, so I cut it down to the glyphs of the nine Kannada signs in the city. That's 18 KB. Kannada isn't monospaced like the rest of my text, so I measured each sign's width in Chrome once and keep the numbers in a table to lay the signs out.

The same picture every time

Everything that looks random, like which windows are lit, where the trees go and who's walking where, comes from a seeded random generator. The same data always draws the same SVG, byte for byte, so when nothing has changed, the workflow has nothing to commit.

GitHub's scheduler runs late

The sky depends on the workflow running when the light changes, and that turned out to be the weak spot. In its first two days the workflow had about 30 scheduled runs. GitHub started eight of them, every one late. On the day the city went live, the evening redraws, due at 17:50 and 19:05, started at 22:53 and 23:01. If I hadn't started one by hand, the city would have stayed in daylight until almost eleven at night. Scheduled workflows are best effort, and GitHub drops some of them when Actions is busy.

Runs started by a push, an issue or the API start within seconds. Only the schedule is unreliable. If you build something like this, don't count on the cron to run on time.

The stock market is still there

The $VJK stock market from my first post still runs right under the city, so you can still buy shares in me. Its price board is in the city too, hanging at Commit Street station.

Try it

Commit City is at the top of my profile. The code lives in the same repo, mostly in scripts/lib/render/city.js and scripts/lib/render/city/. Running node scripts/preview.js --phases draws the city in all four lights, so you can see it before you push anything.

My next goal is 1,500 contributions, so the town hall can open.

I turned my GitHub contribution graph into a Metro train

Vineet J Karni — Tue, 06 Oct 2026 18:45:30 +0000

My GitHub contribution graph is a metro train now.

vineetjk (Vineet J Karni) · GitHub

Best things need time! . vineetjk has 80 repositories available. Follow their code on GitHub.

github.com

A few days ago I listed my GitHub profile on the stock market. The stock, $VJK, gets its value from my commits, but the commits themselves were still only a number in a panel. I wanted the contribution graph on the profile too, drawn as something other than green squares.

Bengaluru's Namma Metro runs on long elevated viaducts across the city, so the graph became a metro line.

How the graph becomes a train

GitHub's graph is 53 columns by 7 rows: a column for every week, a square for every day. Turn it on its side and it's a train.

Every coach is a week. There are 53 of them.
Every coach has seven windows, Sunday to Saturday.
A window lights up with that day's commits. No commits, it stays dark. A busy day, it glows bright gold.
The oldest week rides at the tail. This week's coach is right behind the driver's cab, and today's window pulses.

My busiest repos hang on sign gantries over the line, each one above the coach of the week I committed to it the most. The line ends at Commit Street, the interchange where the green line carries $VJK, with a small LED board showing the live price.

The ride

The panel loops every 90 seconds:

It rests on today, with the driver's cab at the Commit Street platform.
It fades, goes back a year, and picks up the tail of the train.
The train runs along the viaduct while the camera moves along it a little faster, from the oldest coach toward the newest.
Under each repo gantry the train slows down and the camera zooms in. Between gantries it speeds up and the camera zooms out.
It brakes into Commit Street, and the loop starts again.

Passing under a gantry:

Arriving at Commit Street:

Zoomed out at full speed, months of coaches go by:

It follows your GitHub theme, so light mode gets a daytime version:

It took a few tries

The first version gave every week its own 7-coach train, with a coach for each day. The camera panned along a row of them, and they didn't move. It looked like a camera driving past parked trains.

So I fixed the camera and let the trains run through. That looked better, but now the stations had nowhere to go, because a station can't move along with a train.

The next version moved both, and that idea stayed: the camera moves faster than the trains, so they run forward while it overtakes them. Then I put gaps between the trains, because 53 trains nose to tail looked like one endless train.

And then the obvious question: why are 53 trains sharing one track? One long train fixed that, and it maps more directly onto the graph too, one coach per week.

The last change was the stations. A 53-coach train stopping with a coach from March at the platform looks wrong, because a real train stops with the driver at the front of the platform. So repos became sign gantries over the line, the train only slows down under them, and the one real stop is Commit Street.

How it works

It's still just an SVG

GitHub doesn't run JavaScript in a README. Like everything else on my profile, Commit Metro is an SVG loaded through an <img> tag and animated with CSS. A Node script redraws it from my contribution data every time the profile's GitHub Actions workflow runs, so new commits show up on their own.

Keeping each gantry above the right coach

The train and the camera move at different speeds, so how does a gantry end up exactly above the right coach? It's built there. If week u is the coach in focus, the camera looks at world(u), and the train has moved world(u) - centre(u):

const centre = (u) => coachX(u) + COACH / 2;  // coach u, in the train's own coordinates
const world = (u) => STRETCH * centre(u) + W;  // where the camera looks
const runAt = (u) => world(u) - centre(u);     // how far the train has moved along the line

With STRETCH = 3 the camera covers three times the distance the train does. The gantry for week i stands at world(i), so whenever the camera reaches it, coach i is right underneath.

Speeding up and slowing down without a jolt

Each stretch between gantries is two CSS cubic-bezier curves, one that speeds up and one that slows down:

const EASE = {
  speedUp: (from) => `cubic-bezier(.3,${0.3 * from},.7,${1 - 0.3 * PEAK})`,
  slowDown: (to) => `cubic-bezier(.3,${0.3 * PEAK},.7,${1 - 0.3 * to})`,
};

The slope at each end of a cubic-bezier is the speed at that end. So the two halves meet at the same top speed in the middle, and a stretch arrives at a gantry at the same slow speed the next one leaves with. Every stretch takes time in proportion to its length, so they all share one average speed. I sampled the motion to check it: under a gantry the train runs at 0.44 of its average speed, and it peaks at 1.62.

The zoom is one more keyframe animation with the same percentages and the same curves, zoomed in at the gantries and out where the train is fastest. Because every animated layer shares that timing, the camera, the train and the zoom stay in step.

A first frame that makes sense

Some places that show a README never play the animation, like screenshots and some apps, and people with reduced motion turned on don't get it either. So the resting frame, with the train at Commit Street, is also the starting state. Anything that doesn't animate still shows today.

The driver's cab

The nose is one cubic Bézier curve from the roof down to the tip, extended back into depth for the top of the nose. The rear cab uses the same curve, flipped. The front one also has a small horn on the roof and two headlights whose beams fade out down the track.

Where the gantries come from

GitHub's GraphQL API returns commits per repo per day:

contributionsCollection {
  commitContributionsByRepository(maxRepositories: 25) {
    repository { name isPrivate }
    contributions(first: 100) { nodes { occurredAt commitCount } }
  }
}

I group each repo's commits by week and keep my six busiest public repos. Private repos are left out, so their names never show up. If two repos have the same busiest week, they share one gantry and its board lists both.

Try it

Commit Metro is at the top of my profile. The code lives in the same repo, mostly in scripts/lib/render/metro.js, if you want a train of your own.

If your graph has a lot of empty windows, like mine does in August, that's what it looks like on a train too.

I IPO'd my GitHub profile. You can buy shares in me.

Vineet J Karni — Tue, 06 Oct 2026 03:12:20 +0000

My GitHub profile is a stock now. It's called $VJK, it trades in rupees during Indian market hours, and anyone with a GitHub account can buy or sell it. My commits decide what it's worth.

vineetjk (Vineet J Karni) · GitHub

Best things need time! . vineetjk has 80 repositories available. Follow their code on GitHub.

github.com

Where this came from

Over the last few weeks I kept running into posts here on DEV where people had turned their GitHub profile into something completely different. Giorgi built a cyberpunk console with a city made out of his contributions. Someone turned theirs into a roguelike dungeon, someone else into a spaceship mission console, and there's a Minecraft tree that grows from your commits.

I loved all of them. My own profile README at that point was empty. I had cleaned it up and never put anything back.

I wanted to make one too, but I didn't want to build another city or another game. What I liked about those posts is that each profile says something about the person who made it. So I asked myself what mine would say. The honest answer is that I spend a lot of my free time reading about markets and finance.

So I listed myself on the stock market.

What's on the profile

From top to bottom:

A ticker that scrolls the price, the fair value and the latest market news.
A quote panel with the price, the day's open, high, low and volume, and how far the price can still move today.
A daily candlestick chart. The dashed orange line is the "fair value" my commits give the stock.
Four buttons: buy 5, buy 25, sell 5 and sell 25.
The top shareholders and the latest trades.
My GitHub numbers, shown like a company's fundamentals. My languages show up as "sector allocation".

It follows your GitHub theme, so light mode users get a light version.

How a trade works

There's no website and no server. Trading happens through GitHub issues.

When you click BUY 5, GitHub opens a new issue in my profile repo with the title BUY 5 $VJK already filled in. You can change the number to anything from 1 to 25. Click Create, and that's your order.

Opening the issue starts a GitHub Actions workflow. It reads the title, checks the order and fills it. If it's your first trade, you get ₹10,000 of play money to start with.

Every share you buy pushes the price up 0.15%, and you pay the price after your own push. $VJK listed at ₹55.10, so buying 5 shares at that price goes like this:

the price moves from ₹55.10 to ₹55.50
you pay ₹55.50 × 5 = ₹277.50
you're left with ₹9,722.50 in cash and 5 shares

The bot then redraws the images on my profile, commits them, leaves a receipt on your issue and closes it. This is the receipt for that exact trade:

✅ Filled · BUY 5 $VJK @ ₹55.50


Fill price (after your own impact)	₹55.50
Order value	₹277.50
Your trade moved the price	▲ +0.73%
Your position	5 shares, avg ₹55.50
Cash	₹9,722.50
Portfolio value	₹10,000.00 (+0.00%)

Selling is the same thing in reverse. Each share you sell pushes the price down 0.15%, and you get the price after your push. If you sold those 5 shares ten minutes later and nobody else had traded, the price would drop back to ₹55.10 and you'd get ₹275.50. You'd be down ₹2.

That's on purpose. If you could buy and sell straight away without losing anything, someone would write a script to pump the price and dump it.

A few other rules:

One order every 10 minutes per person.
If you try to sell more than you have, it sells what you have. If you have nothing, the order is rejected.
If you don't have enough cash, you get as many shares as you can afford.
Bots can't trade, and neither can I.

Market hours and limits

The market keeps Indian market hours: 09:15 to 15:30 IST, Monday to Friday. If you place an order outside those hours, it waits. The bot comments that it's queued, leaves the issue open, and fills it at the next morning's open. Indian brokers call this an after-market order (AMO). Closing the issue cancels it.

The price can't move more than 10% from the previous day's close. When it hits the upper limit, buying stops for the rest of the day, and when it hits the lower limit, selling stops. Indian exchanges call this a circuit. Here it also stops one person with ₹10,000 from doubling the price in an afternoon.

Prices move in steps of ₹0.05, and big amounts use Indian digit grouping, so you'll see ₹1,00,000.00 and not ₹100,000.00.

How my commits move the price

This is my favourite part. Every weekday at 15:33 IST, right after the close, the workflow looks at my contributions from the last 30 days and works out a fair value:

export function fairValue(contrib30, cfg) {
  const value = cfg.listingPrice * Math.sqrt((contrib30 + 10) / (cfg.baseline30 + 10));
  return snap(Math.round(value * 100), cfg.tickPaise);
}

A normal month for me is about 30 contributions, and that's worth ₹100 a share. A month with nothing drops it to ₹50. The square root is there so one crazy day doesn't make the number explode, and the + 10 keeps a quiet month from taking it to zero.

Then the closing price moves 20% of the way toward that fair value, still inside the 10% limit. So during the day you decide the price, and at the close my commits pull it back toward what they say it's worth.

Commits I make at night or on weekends still count. They stay in the 30-day window, so the next weekday close picks them up, and they keep counting for 30 days.

A chart from day one

A brand new stock would start with an empty chart. So when $VJK listed, it backtested the previous 70 trading days: start at ₹100 and run every close as if the market had already existed, using my real contribution history.

The chart is pretty honest about my year. I was busy in July, and the price climbed to ₹174. I didn't push anything public in August or September, and it slid all the way down to ₹50. Then I made 30 contributions on October 4th, and the last session before listing closed right at its +10% limit.

So $VJK listed at ₹55.10, with a fair value of ₹101.25. If I keep committing, it should keep climbing for a while.

Dividends

Every time one of my pull requests gets merged, everyone holding shares gets ₹2 per share. It's a small reason to hold instead of flipping.

What it looks like with traders

This one is from a local rehearsal. I ran two and a half weeks of made-up trading through the same code, with fake usernames, to see how the leaderboard and the chart look once people are actually trading. The real market starts empty.

How it's built

Everything on the profile is an SVG

GitHub doesn't run JavaScript in a README, and it strips <style> tags. But an SVG loaded through <img> can carry its own CSS, including animations. So every panel is an SVG. The ticker scrolls, the market status dot pulses, and the buy and sell buttons have a shine that sweeps across them. A link can only wrap a whole image, which is why each button is a separate file.

SVGs shown this way can't load anything external either, not even Google Fonts. So I embedded JetBrains Mono, cut down to just the characters I use. That comes to about 5 KB per weight. JetBrains Mono has no ₹ sign, so the rupee comes from a 628-byte cut of Noto Sans Mono, which has the same character width. Avatars get downloaded and embedded too.

For dark and light mode, the README uses <picture>:

<picture>
  <source media="(prefers-color-scheme: dark)" srcset="assets/dark/quote.svg?v=f3a9c1d2e0">
  <img src="assets/light/quote.svg?v=8b2e4a7c91" width="100%" alt="...">
</picture>

The ?v= part is a hash of the file. GitHub caches images, so when a panel changes, the README points at a new URL.

One workflow for everything

The workflow runs at the opening bell, at the closing bell, and every time someone opens an issue with VJK in the title:

on:
  schedule:
    - cron: "47 3 * * 1-5" # 09:17 IST
    - cron: "3 10 * * 1-5" # 15:33 IST
  issues:
    types: [opened]
  workflow_dispatch:

Every run does the same job: fetch my GitHub stats, ring whichever bell is due, settle every open order, redraw the SVGs, regenerate the README, then commit and push. The receipts only go out after the push works, so nobody gets a receipt for a trade that isn't in the ledger.

The ledger is just data/market.json in the repo, and its git history is the full record of every trade.

Things I had to work around

GitHub cancels queued runs. With a concurrency group, GitHub keeps one run going and one waiting, and cancels the rest. If ten people order at once, most of those runs never happen. So no run belongs to a single issue. Each run settles every open order, and whichever run survives does the work of the cancelled ones.

Queued runs start from an old commit. A waiting run checks out the commit from when it was triggered, which can be behind what the previous run just pushed. Checking out the branch name instead fixes that, and if a push still gets rejected, the job resets to the new tip and runs the tick again.

Bursts and rate limits. Every order costs two API calls, a comment and a close, and GitHub limits how fast a bot can create content. So each run settles at most 20 orders. If more are waiting, it triggers itself again with workflow_dispatch, one of the few events a workflow's own token is allowed to start.

Issue titles are user input. Anyone can open an issue with any title. Here the title only ever gets matched against a regex in Node. It never goes into a shell command and never gets written into the README. rudratosh wrote a good post on what profile automation workflows can expose, and it's worth reading before you build one of these.

No empty commits. Rendering is deterministic. If nothing changed, the files come out byte for byte the same and the workflow skips the commit.

The bot's commits aren't mine. They're authored by github-actions[bot], so trading can't inflate my contribution graph, and through it, my own stock price.

No dependencies

It's plain Node with no npm packages. The market itself is a pure function of the current state, my stats and the time, which made it easy to test. 29 tests cover the rules, the rendering and a full run of the workflow script against fixtures.

Try it

Go buy some $VJK on my profile. The market's open 09:15 to 15:30 IST on weekdays, and orders placed outside those hours wait for the next morning.

If you want your own stock, the code is in the same repo. scripts/README.md has the steps: change the symbol and the username, and set how many contributions a normal month is for you.

I'm curious who ends up as the biggest shareholder.

A Food Companion I Built for My Friend Living in a PG

Vineet J Karni — Sun, 04 Oct 2026 09:24:03 +0000

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

What I Built

My friend Prithvi lives in a PG (paying-guest accommodation). If you've lived in one, you know how food works there: the mess decides the menu, the kitchen isn't yours, and when the mess food doesn't work for you, the fallback is ordering in or grabbing something nearby.

For most people that's just boring. For Prithvi it's hard, because her body has a few rules of its own:

Lactose bothers her, but only sometimes. A little ghee is fine; a bowl of paneer in cream might not be.
She has a sensitive gut. Deep-fried, very spicy, or fizzy things can ruin her day.
Her TSH is high (thyroid). Soy and some millets are best limited.
She's working on losing weight. Fried snacks, sweets, and refined flour quietly add up.

Each of these is manageable on its own. The trouble is keeping all four in mind at once, every meal, with food she didn't cook. A mess dal is probably fine. The paneer butter masala on Sunday? The chole bhature someone orders for the floor? The masala chai? She can't always eat good food, so she needs a quick way to know which options are okay, which are okay in moderation, and how to make them better.

So I built AllergySafe Table, a small app that answers one question in plain words: "Can Prithvi eat this?"

Ask in plain language by typing, speaking, or sending a photo: "Can Prithvi eat paneer butter masala?" or "What can she have for breakfast?" The answer comes back as a clear verdict, the reasons, easy swaps, and better options. It can also be read aloud.
Scan a mess menu, a recipe, or a packaged-food label to see exactly which ingredients to watch.
Remix a dish she loves into a version that suits her, swapping only what's needed.
Plan dinners that suit her, with a shopping list, for the days she gets to cook or eat out with friends.
Notes keep track of what she loved and what didn't sit well, so her own experience builds up over time.

Under the hood, two open pieces work together: Google's open-weight Gemma 2, running locally through Ollama, works out what's in a dish the app has never heard of, and a set of open, readable food rules decides whether that suits her. The model fills in the recipe; it never gets to say "safe".

It doesn't try to be a doctor. It's a friend who remembers all four of her rules, every single time.

Demo

Ask anything. Her conditions are always visible, and the answer explains itself.

Ask	Answer	Dark mode

A dish the app has never seen. Dabeli isn't in its recipe list, so Gemma 2 (on the same laptop) guesses the ingredients. The rules spot the butter and suggest a swap, and the app shows exactly what Gemma guessed so Prithvi can correct it.

Check a menu or a photo, remix a dish, plan dinners, and keep notes.

Ingredient check	Recipe remix	Dinner plan	Food notes

Her profile explains what each condition means in everyday terms. It's editable, so the app also works for anyone else, including people with real food allergies like gluten or nuts.

Code

vineetjk / AllergySafe

A friendly food companion built for a friend.

AllergySafe Table

Can Prithvi eat this? A friendly food companion built for a friend.

My friend Prithvi is sometimes lactose intolerant, has a sensitive gut, has high TSH (thyroid), and is trying to lose weight. Keeping all four in mind every time we cook or order food is hard. AllergySafe Table answers the everyday question "can she eat this?" in plain language, suggests easy swaps, and plans meals everyone can share.

Built for the Hacktoberfest Weekend Challenge: Build for a Friend (HF26).

Live demo: https://allergysafe-table-web.onrender.com (free Render plan, so the first visit can take up to a minute to wake up. The hosted version uses the rules only; Gemma runs when you run the app locally.)

Features

Ask in plain words

Type, speak, or send a photo, for example "Can Prithvi eat paneer butter masala?" or "What can she have for breakfast?". Each answer gives a clear verdict, the…

View on GitHub

git clone https://github.com/vineetjk/AllergySafe.git
cd AllergySafe
python3 -m venv backend/venv && backend/venv/bin/pip install -r backend/requirements.txt
(cd frontend && npm install)
cp backend/.env.example backend/.env   # optional: add an ElevenLabs key for voice

# Optional, for dishes the app doesn't know: local Gemma 2 (about 1.6 GB)
brew install ollama && ollama serve &
ollama pull gemma2:2b

./start.sh

How I Built It

The stack: a Next.js 16 frontend, a FastAPI backend, Gemma 2 (2B) through Ollama for unknown dishes, ElevenLabs for voice, and a Render Blueprint that deploys both services.

Rules, not guesses

The heart of the app is a small, readable food engine, not a chatbot. When you ask about a dish, it:

Works out what you mean. It tells apart a dish ("can she eat rajma chawal?"), a list of ingredients, a request for ideas ("what can she have for breakfast?"), and a follow-up to its own question.
Looks up typical ingredients from a library of about 80 common Indian and international dishes, from dal makhani and masala dosa to pizza.
Checks each ingredient against her profile. Allergies (gluten, nuts, and so on) are marked not safe. Her conditions (lactose, gut, thyroid, weight goal) are marked in moderation, because that's what they are: things to limit, not things that will hurt her.
Explains itself: which ingredient caused each flag, a swap for each one, and a couple of healthier options.

Gemma fills in the dishes the rules don't know

A library of 80 dishes will never cover everything a PG mess or a street stall serves. Before Gemma, asking about dabeli or misal pav got "I don't know, tell me the ingredients", which is the last thing you want to type at the counter.

Now the backend asks Gemma 2 (2B), running locally in Ollama, one narrow question: what usually goes into this dish? It replies in strict JSON, and the backend validates it (2 to 12 short ingredient names, or {"known": false} for anything that isn't food, so "can she eat my laptop" doesn't get a recipe). Those ingredients then go through the same rules as everything else.

ingredients = await open_llm.suggest_ingredients(dish)   # Gemma 2: "what's in it?"
if ingredients:
    answer = FoodAssistant._analyse(profile, dish, ingredients, assumed=True)  # rules: "is it okay?"
    answer.ingredients_source = model                    # shown to her in the app

That split is deliberate:

The model only guesses ingredients. It never decides whether something is safe. The verdict always traces back to a rule anyone can read.
The guess is shown, not hidden. The app says "Ingredients guessed by gemma2:2b on this device: ...", so Prithvi can see what it assumed.
She can correct it. If Gemma is wrong, she types the real ingredients and the rules check again.

A 2B model is wrong sometimes. It left the fried farsan off misal pav, and it thought malai kofta had meat. That's exactly why it doesn't get the final say. When Ollama isn't running, the app quietly falls back to asking her for the ingredients.

Where it runs: Gemma runs on the same machine as the backend: a laptop on the same Wi-Fi, opened from a phone (start.sh prints the address to open). The free Render demo has only 512 MB of RAM, too little for Gemma, so the hosted demo uses the rules only. To get the Gemma step, run the app locally with the commands above.

Indian food needed its own care

Paneer, curd, malai, and lassi count as dairy. Ghee is nearly lactose-free, so it isn't flagged for an intolerance. "Peanut butter" and "coconut milk" are not dairy, and "stir-fried" is not "deep-fried". When neither the library nor Gemma knows a dish, it says so and asks what's in it, instead of pretending. For photos without an image model, it asks for the dish name rather than guessing.

Voice that sounds like a person

Prithvi can ask by voice and hear the answer, which matters when your hands are full or you're standing at the mess counter. Questions are transcribed with ElevenLabs Scribe. Answers are spoken with Eleven v4 Turbo, which is only available over a realtime websocket, so the backend streams the text, collects the audio, and returns a single clip. If that ever fails, it falls back to Turbo v2.5, so she still hears a real voice and not a robotic one.

iPhones block audio that starts after a network request, so the app starts a tiny silent clip at the moment you tap and reuses it for the real answer. Small detail, big difference on a phone.

Built for a phone

Prithvi will use this on her phone, so the whole app is a phone-first shell: a bottom tab bar where every section is always visible, a chat where only the conversation scrolls and the input stays put, and light and dark themes.

Production details

The browser only talks to the Next.js server, which forwards /api/* to FastAPI, so there are no cross-origin or mixed-content issues on phones.
Her profile and notes are stored only in her browser, never on a shared server.
Endpoints that spend ElevenLabs credits are rate-limited, and every input has a size limit.
If the server is slow or down, the app shows a clear error. It never invents a "safe" verdict.
GitHub Actions runs the backend tests on Python 3.11 to 3.13 and builds the frontend on every push.

Built with an agent

I paired with Claude Code, connected to DEV through DevRelay. This curated session shows the moment we found that Gemma was configured but never actually called, and how we wired it in so the model guesses ingredients and the rules make the call:

Why Does Open Innovation Matter?

Health details are personal. Lactose, gut trouble, thyroid levels, and weight are things Prithvi shares with friends, not with an ad network or a model's training data. Gemma runs on the user's own machine, and it only ever sees a dish name, never her profile. The food checks use open rules, and her profile never leaves her browser. The only outside service is ElevenLabs, and only when she chooses to use voice.

Every answer can be checked. A closed chatbot might say "a little cream is fine" with total confidence. In this app, every verdict traces back to a rule in a plain Python file that anyone can read. If something is wrong for her, like "curd is actually fine for me", it can be fixed in one line, by anyone.

It's free to run and easy to extend. Nobody living in a PG should need a monthly AI subscription to figure out dinner. Gemma 2 2B is a 1.6 GB download that runs on an ordinary laptop with no internet and no API key. Anyone can swap in a bigger open model with one setting (OLLAMA_MODEL), add their own dishes or their mess's menu, or add another condition, and share it back.

A closed API would have given me a clever chatbot that decides on its own what's safe. An open model plus open rules gave Prithvi something she can trust, understand, and change.

Prize Categories

Gemma: Gemma 2 (2B), running locally through Ollama, works out the ingredients of dishes the app doesn't know, as validated JSON. The open food rules then decide the verdict, so the model fills in knowledge but never makes the safety call.
Render: the whole app ships as a Render Blueprint (render.yaml). It deploys the FastAPI backend and the Next.js frontend as two services, with the frontend proxying API calls to the backend.
ElevenLabs: voice questions use ElevenLabs Scribe for speech-to-text, and answers and recipe steps are read aloud with Eleven v4 Turbo over the realtime websocket, with a Turbo v2.5 fallback.

Built with open source and a lot of care for a friend who deserves good food.