DEV Community: tushar shah

Nishi Daak: an Arduino UNO Q that calls your name twice when you come home late (local Gemma, no cloud)

tushar shah — Fri, 30 Oct 2026 06:36:02 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

In Bengal they say that late at night, someone may call your name from outside in the voice of a person you love. Do not answer. Not the first time, not the second. The Nishi (নিশি, "the night one") only ever calls twice, and whoever answers follows it into the dark and is never seen again. A real person, the story goes, will always call a third time.

Nishi Daak ("the night call") puts that spirit on a shelf. It is an Arduino UNO Q that:

Watches the door, without a camera. It notices when a family member's phone rejoins the home Wi-Fi late at night after being away for a while.
Calls their name, twice. The 8×13 LED matrix spells the name letter by letter, like a planchette, then spells it again. Never a third time.
Writes what followed them home. Gemma, running on the board itself through llama.cpp, writes a short eerie (but harmless) tale and saves it to a night log.
Holds séances. Open the board's web page from any phone on the home Wi-Fi, ask the Nishi a question, and it answers in character while a short version is spelled on the matrix.
Stays awake all day as two glowing eyes. They blink, and their brightness ("spirit energy") follows how many Bluetooth devices are nearby.

No cloud, no accounts, no API keys. Nothing leaves the house.

Demo

The night call: the name, letter by letter, twice. Never a third time.

🎬 Watch the 74-second demo video (Google Drive)

The human scenes in the video are free stock footage from Pexels (a Kolkata evening, a walk home, a door at night). The board's behaviour, the timings and the numbers come from the real build. The tale typed out in the video is the few-shot example from the prompt; real ones from the board's night log are below.

This is the board's own web page, screenshotted live from the UNO Q on my home Wi-Fi. The eyes and the "2" show the spirit energy (5 Bluetooth devices nearby), the night log holds real tales Gemma wrote on the board, and the footer is the board's health check: presence ok, Gemma 3 1B ok, last reply 15 s at 4.7 tokens/s.

Three real entries from night_log.json, written by Gemma 3 1B on the board:

A single, crimson leaf drifted down the path, landing softly beside his feet. It mirrored a forgotten melody, a scent of rain and old roses. The Nishi smiles, a fleeting glimmer in the gloom.
(10.0 s, 4.7 tokens/s)

A single jasmine flower, bruised and drooping, drifted past the doorway. The rain smelled of dust and regret, a faint, silver light reflecting on it. It paused, a single tear falling: a beautiful sorrow, like a forgotten song.
(15.0 s, 4.7 tokens/s)

A single, pale moonbeam traced a path down the stairs. It watched a small, worn book open. A faded map, perhaps? The Nishi smiles, a fleeting shadow.
(12.6 s, 4.7 tokens/s)

Each log entry records the time the board caught the phone. Tap the small red icon next to a name (a flask for a test call, Wi-Fi for a real one) and a card shows how it was caught, how long the person was away, and how fast Gemma wrote the tale.

Code

tusharshah21 / Nishi-Daak

Nishi Daak

It calls your name twice. Never answer.

An Arduino UNO Q that lives on a shelf and behaves like a Nishi, the night spirit of Bengali folklore. Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 4 ("Ghost in the Machine"), Arduino category.

The folklore

In Bengal they say the Nishi comes late at night and calls your name in the voice of someone you love. It calls only twice. If you answer, you follow it into the dark and are never seen again. So if you hear your name at night, wait for the third call: a real person will always call a third time.

What it does

Idle: two glowing eyes on the board's 8x13 LED matrix. They blink and flicker, and their brightness ("spirit energy") follows how many Bluetooth devices are nearby. With no energy, only a faint stray light flickers now and then.
Night…

View on GitHub

Part	File	Runs on
Matrix eyes and planchette	`sketch/sketch.ino`	the UNO Q's STM32 microcontroller
App logic and web API	`python/main.py`	App Lab container on the Linux side
Web page (séance, night log)	`assets/index.html`	App Lab `web_ui` brick, port 7000
Presence scanner	`host/presence_service.py`	Debian host, systemd
The spirit's voice	llama.cpp `llama-server` + `gemma-3-1b-it` Q4_K_M	Debian host, systemd

How I Built It

The UNO Q is two computers on one board: an STM32 microcontroller that drives the LED matrix, and a quad-core Linux side (4 GB of RAM on mine) running Debian. App Lab connects them with a Bridge, so Python on the Linux side can call Bridge.call("spell", "TUSHAR TUSHAR") and the sketch fades the letters in and out on the matrix.

Gemma on the board

llama.cpp builds on the board itself (47 minutes with -j2; 3.6 GB of RAM was enough). llama-server runs as a systemd service with Gemma 3 1B instruct, Q4_K_M (a 769 MB file):

What	Measured on the board
Generation speed	4.7 to 4.9 tokens/s, 4 threads
One séance answer	8.5 to 9.1 s
A night tale	10 to 15 s
First reply after a restart	38.8 s (it processes the persona once)

A 1B model does not follow rules well, but it copies examples beautifully. So instead of a long list of "never do X", the prompt is a short persona plus two few-shot turns: one night tale and one dodged request for advice. A small tidy() pass then strips markdown, emojis and any "as an AI" talk, and keeps at most three sentences, so whatever Gemma says always fits the spirit. If Gemma is down, the Nishi falls back to a canned line, so the call never fails.

Catching a phone without a camera

From the demo video: the moment the phone rejoins the home Wi-Fi and the board decides to call. The footage is stock and the times are illustrative; the decision logic is the real code below.

The Nishi needs to know who came home, but I did not want cameras or an app on anyone's phone. Phones randomize their Bluetooth addresses constantly, so Bluetooth only feeds the "energy" count. Wi-Fi is different: Android and iOS keep one stable private MAC per network. A small root service on the host runs arp-scan on the home network and serves the result as JSON, and the app turns it into arrivals:

def arrivals(macs, now):
    """(name, seconds away) for known people whose phone reappeared after being away."""
    back = []
    for p in CFG["people"]:
        mac = p["mac"].lower()
        if mac not in macs:
            continue
        prev = last_seen.get(mac)
        if prev is not None and now - prev > away_seconds():
            back.append((p["name"], now - prev))
        last_seen[mac] = now  # first sighting after app start never counts as an arrival
    return back

Then reality got in the way, twice.

Locked phones vanish. A locked phone in Wi-Fi power save answers ARP after up to 2 seconds, and the default arp-scan gives up after 500 ms. With --retry=4 --timeout=1500 it went from 4 of 6 scans to 6 of 6. But during a 30-minute test with the phone locked on the table, it was seen once in 62 polls: a sleeping phone drops off Wi-Fi entirely, and no scan can see a disconnected phone. So the "away" threshold is 3 hours, not 20 minutes. Otherwise the Nishi would call my name every time my phone took a nap next to me.

The board kept dying after about 15 hours. Ping worked, SSH refused, and only a power cycle brought it back. The journal of the dead boot had the answer: The maximum number of active connections for UID 0 has been reached (max_connections_per_user=256). Each BLE scan used asyncio.run(), a fresh event loop every time, and bleak opened a new system D-Bus connection for each loop without closing the old one. The connections piled up until root hit the limit, and from then on nothing running as root could talk to D-Bus. The fix is one event loop for every scan:

BLE_LOOP = asyncio.new_event_loop()  # one loop for every scan: bleak keeps a D-Bus connection per loop

def scan_ble():
    found = BLE_LOOP.run_until_complete(BleakScanner.discover(timeout=BLE_SECONDS, return_adv=True))

Before the fix, the service's socket count grew by one with every scan. After it, the count stayed flat at 6.

Why Does Open Innovation Matter?

This project only makes sense with an open model running locally:

The data is my family's comings and goings. The core signal is which phone came home, and when. That is exactly the kind of data I do not want on someone else's server. With Gemma running on the board, the phone addresses, the timestamps and every tale stay in a JSON file on a shelf in my house.
It works with the internet off. Ghost stories are for power cuts and bad nights. The Nishi only needs the home Wi-Fi router; unplug the internet and it still calls your name and still tells you what followed you home.
It costs nothing to run. No per-request bill for a spirit that might speak a dozen times a night, and no API key to leak.
The spirit is mine to change. The persona is a few lines of text and two examples. I can swap the model for a smaller Gemma on a 2 GB board or a bigger one somewhere else, change the voice, or change the language in config.json, and nothing depends on a hosted model's mood that week.
It lasts. Folklore survives because it is passed down, not hosted. A Nishi that depends on a service that might shut down someday is a very short-lived ghost.

My Agent Session

I built this with Claude Code as a pair, running the board over SSH from my laptop. The session below is a curated slice of the real build: the board setup, the locked-phone tests, the crash that turned out to be a D-Bus leak, and the night log's details card.

Building Nishi Daak: an Arduino UNO Q night spirit with local Gemma

You

I haven't run any commands on the board yet. Instead of me copying outputs back and forth, I want you to run the board commands yourself over SSH from my Windows laptop.

Agent

▸ Bash adb shell: check OS, RAM, disk, Bluetooth and Wi-Fi on the UNO Q

Input

$ adb shell: check OS, RAM, disk, Bluetooth and Wi-Fi on the UNO Q

Output

Debian 13 (trixie), aarch64, 3.6 GiB RAM, hci0 present, wlan0 DOWN with no saved network

The board isn't on your Wi-Fi yet, and SSH is disabled out of the box, so I got in over USB with adb and put the laptop's SSH key on it. Two things need you: your Wi-Fi password and your sudo password.

You

ssh nishi "tail -5 ~/install.log" ... [100%] Built target llama-server ... Created symlink nishi-presence.service ...

Agent

▸ Bash check llama-server health and the presence service on the board

Input

$ check llama-server health and the presence service on the board

Output

nishi-presence active, nishi-llm active, llama-server listening on 0.0.0.0:8080 with gemma-3-1b-it Q4_K_M

The first install worked: llama.cpp built on the board in about 47 minutes and Gemma 3 1B (769 MB) is loaded. My cleanup then deleted libllama-server-impl.so, which is a real library, not a dev symlink, so the board is rebuilding. Lesson recorded: keep build/bin untouched.

You

Correction: my phone's Wi-Fi was ON the whole time. I never turned it off, so the off/on test result is invalid. I read my phone's address directly from its Wi-Fi settings.

Agent

Then the 'disappeared' MAC was a coincidence: devices on this LAN drop in and out of arp-scan on their own, so a single diff proves nothing. I've put the address you read from the phone into config.json and started a locked-phone test. Lock your phone now.

You

check now with the phone it is locked for some time now

Agent

▸ Bash 6 rounds a minute apart: default arp-scan, patient arp-scan, ping

Input

$ 6 rounds a minute apart: default arp-scan, patient arp-scan, ping

Output

default 4/6, --retry=4 --timeout=1500 6/6, ping 6/6

A drowsy phone in Wi-Fi power save answers ARP after up to 2 s, and the default scan gives up after 500 ms. With --retry=4 --timeout=1500 it is 6 of 6. But after a long lock your phone dropped off Wi-Fi completely, and no scan can see a disconnected phone.

You

phone locked now, check after 30 minutes

Agent

Over 30 minutes locked, the board saw your phone once in 62 checks. A locked phone is effectively invisible, so the scanner can't tell 'asleep at home' from 'away'. Options: a much longer away time, or a phone-side setting.

You

cool we can continue the build now

Agent

▸ Bash nmcli: static IP 192.168.1.200, ignore IPv6 DNS; arduino-app-cli app start us...

Input

$ nmcli: static IP 192.168.1.200, ignore IPv6 DNS; arduino-app-cli app start user:nishi-daak

Output

first start: fatal error: MsgPack.h: No such file or directory; second: lookup downloads.arduino.cc ... network is unreachable; third: running

Nishi Daak is running on the board. Fixes on the way: a static IP (DHCP had moved the board), the Bridge libraries missing from sketch.yaml, and IPv6 DNS servers the board couldn't reach. As you chose, someone counts as 'arrived' only after 3 hours unseen.

You

the UI is not loading can you check it

Agent

▸ Bash journalctl -b -1 on the board after the power cycle

Input

$ journalctl -b -1 on the board after the power cycle

Output

The maximum number of active connections for UID 0 has been reached (max_connections_per_user=256)

Root cause of both 'board stuck' episodes: the presence service ran every BLE scan with asyncio.run(), a new event loop per scan, and bleak opened a new system D-Bus connection for each loop without closing the old one. At 256 root connections D-Bus refused everyone. Fix: one event loop reused for every scan. Socket count before: grew by one per scan. After: flat at 6 across 8 scans. I also made Nishi Daak the default App Lab app so it starts on boot.

You

on the call can we see the time stamp too at what time does the arduino caught it?

Agent

▸ Bash python tests/test_main.py

Input

$ python tests/test_main.py

Output

ok

Each call in the night log now records the time of the presence scan that saw the phone, not when the slow spell and Gemma's tale finished (that could be a minute late). It also records how long the person was away and whether it was a test call. Checked with a real test call on the board.

You

the details should be seperate not there on the page have an icon for the same

Agent

The log now shows only time and name plus a small red icon (Wi-Fi for a real catch, a flask for a test call). Tapping it opens a native dialog, 'The call': name, caught at, how, away for, and how fast local Gemma wrote the tale.

The Spirit of It

The spookiest moment wasn't a ghost story. It was the board going silent after 15 hours: it still answered a ping, but nothing else. Something was still home, but it wouldn't come to the door. It turned out to be 256 D-Bus connections that never closed, which is a very modern kind of haunting.

It is an old story, living in a small board, made out of open pieces anyone can read and change.

It calls your name twice. Never answer.

Prize Categories

Best Use of Arduino: the whole project is an Arduino UNO Q acting as a physical agent that senses (Wi-Fi presence, Bluetooth energy) and acts (the LED matrix planchette), with the language model running on the board itself.
Best Use of Gemma: Gemma 3 1B instruct (Q4_K_M) runs locally on the UNO Q through llama.cpp and writes every night tale and séance answer, at 4.7 tokens/s, with no cloud.

Bahar: the best hour today to go outside, forecast by TabPFN and told by Gemma

tushar shah — Mon, 12 Oct 2026 06:20:40 +0000

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

Quick question before you scroll: when did you last step outside on purpose? Not to get to the car. Not to grab a delivery. Just to be outside.

If you had to think about it, this one's for you.

What I Built

Here's a morning you might recognise. You decide to go for a walk. You open the air quality app: PM2.5 is "Moderate", whatever that means for the next hour. You open the weather app: it'll feel like 38°C by noon. You open a third app to check for rain. Ten minutes later you're still on your phone, still inside.

That loop is worse in a city like Hyderabad, where air quality changes a lot over a single day, summer afternoons can feel hotter than 40°C, and the monsoon brings sudden rain. So I built Bahar ("outside" in Hindi and Urdu). It answers exactly one question:

When is the best hour today to get out of the house?

No charts to read. One time range, two sentences, and then it tells you to put your phone down.

Under the hood, four steps:

🌦️ Look back. Pull about 18 months of hourly weather and PM2.5 history for the city from Open-Meteo (free, no key).
🔮 Look ahead. TabPFN forecasts PM2.5 for every hour today from the weather forecast.
⚖️ Weigh it up. Score every hour: air quality by India's National AQI bands (55%), heat by the "feels like" temperature (30%), rain (15%). Pick the best 1 to 3 hour window between 5 AM and 7 PM.
💬 Say it like a friend. Gemma 4, running locally in Ollama, writes the plan in two or three sentences, and the app can read it aloud offline.

All of it runs on my laptop: Windows, an i7, 16 GB of RAM, no GPU. No paid API. The only network calls are the weather requests and TabPFN's license check.

Demo

Let's play a quick game first. Here's tomorrow's PM2.5 forecast for Hyderabad, hour by hour. Bahar only plans between 5 AM and 7 PM.

Which window do you think Bahar picked?

👉 Make your guess, then click to see Bahar's answer

5:00 AM to 8:00 AM. Not the cleanest air of the day, but cooler hours: it feels like 28°C at 5 AM and already over 32°C by 9. Bahar weighs heat too. Here's the plan, word for word as Gemma wrote it:

Wake up for your outdoor session between 5:00 AM and 8:00 AM when the air quality is Satisfactory. Go for a run, cycle, or play cricket before the worst stretch around 11:00 AM. Put your phone away and enjoy the Hyderabad morning.

Code

tusharshah21 / bahar

Bahar 🌿

The best hour today to go outside, then off your screen.

Bahar ("outside" in Hindi/Urdu) forecasts hourly PM2.5 for your city with TabPFN, combines it with heat and rain into a "go outside" score, finds the best window, and has Gemma (running locally) tell you the plan in two sentences. Everything core runs on a laptop with no paid API.

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

How it works

fetch_data.py pulls ~18 months of hourly weather + PM2.5 for your city from Open-Meteo (free, no key).
model.py hands TabPFN a few thousand example hours (in-context learning, no training loop) and asks it to predict today's PM2.5 from the weather forecast.
planner.py scores each hour: air quality (India's AQI bands) 55%, heat 30%, rain 15%, then picks the best 1 to 3 hour window.
narrator.py asks Gemma via Ollama to write…

View on GitHub

python fetch_data.py        # once, about a minute
python evaluate.py          # accuracy charts
python bahar.py             # today's plan, printed and spoken
streamlit run app.py        # the one-screen app

🏙️ Try it for your city. Open config.py, change CITY, LAT, LON and TIMEZONE, and run the four commands above. I'd love to see what Bahar says about yours.

How I Used TabPFN

TabPFN is a foundation model for tables, and it works differently from what I was used to. There's no training loop. You hand it example rows at prediction time and it learns from them in context, a bit like showing a friend a few hundred past days and asking "so what about tomorrow?"

For Bahar, each row is one hour: temperature, humidity, wind (split into east and north components), rain, cloud cover, boundary layer height, time of day and season encoded as sine and cosine, and PM2.5 at the same hour yesterday. TabPFN sees 2,000 example hours, half from the most recent weeks and half sampled from the whole history, so it still remembers what last winter looked like.

The feature that helped most is one most people have never heard of: boundary layer height. It's the height of the air layer that pollution mixes into. On calm winter nights it drops to a couple of hundred metres, and PM2.5 has nowhere to go. That's the smog you can taste.

Plot twist: TabPFN lost. At first.

I'll be honest about how this went, because it surprised me.

My first test was the obvious one: train on everything up to three weeks ago, forecast the last three weeks. TabPFN lost to plain gradient boosting (6.90 vs 6.76 mean absolute error, in µg/m³). And it took 20 minutes on my laptop to get there.

The 20 minutes turned out to be an easy fix. Setting n_estimators=1 gave almost the same accuracy and ran about 20 times faster. A full plan now takes about a minute.

The loss was more interesting. When I re-ran the test with different random samples of history, TabPFN sometimes won and sometimes lost. Three weeks was simply too small a window to judge anything. So I asked a better question: how does each model do across a whole year of seasons?

I built a rolling backtest: ten 3-week windows spread from July 2025 to August 2026, each model trained only on the hours before its window, so nothing peeks into the future. Two opponents:

🌲 Gradient boosting (scikit-learn's HistGradientBoostingRegressor), trained on the full history, not just 2,000 rows.
🔁 Same as yesterday: predict that each hour will match the same hour yesterday.

Look at the shaded winter months on the chart. That's where it gets good:

Through the November to February smog season, TabPFN's forecast errors were 16% lower than gradient boosting's.

That's the stretch when choosing the right hour matters most for your lungs. Across the whole year TabPFN also had the lowest average error, about 5% better than gradient boosting, while only ever looking at 2,000 rows.

📊 See every window (for the numbers people)

Window starts	Hours of history	TabPFN	Gradient boosting	Same as yesterday
Jul 2025	2,160	5.51	5.80	6.30
Aug 2025	3,240	3.19	3.11	4.32
Oct 2025	4,320	12.14	11.98	9.76
Nov 2025	5,400	10.27	11.58	10.64
Jan 2026	6,480	7.90	11.30	10.06
Feb 2026	7,560	8.69	9.19	9.04
Apr 2026	8,640	7.76	7.61	8.72
May 2026	9,720	8.77	7.49	8.45
Jul 2026	10,800	3.56	3.31	4.33
Aug 2026	11,880	3.47	3.65	4.40
Average		7.13	7.50	7.60

Mean absolute error in µg/m³, lower is better. TabPFN's scores are averaged over three different samples of history.

It isn't a clean sweep, and I don't want to pretend it is:

Count the wins and it's a tie, 5 windows each. Gradient boosting's wins are small and come later in the year, once it has more than 8,500 hours to learn from.
October humbled everyone. In the first weeks after the monsoon, "same as yesterday" beat both models. The air shifts in ways last year's pattern doesn't capture yet.

How I Used Gemma

If TabPFN is Bahar's brain, Gemma is its voice.

Gemma 4 (gemma4:e4b-it-qat, the quantization-aware 4B-effective model) runs locally through Ollama and writes a plan in about 20 seconds on my CPU. I gave it a clear division of labour: the numbers come from the forecast, the words come from Gemma. The prompt hands it a short list of facts (the window, the air quality band and PM2.5, the "feels like" temperature, a suggested activity, the worst stretch of the day) and asks for two or three warm, direct sentences that end with "put the phone away".

Then Gemma taught me two things.

Lesson one: Gemma can overthink. Gemma 4 can reason before it answers. With a 120-token budget, it sometimes spent every single token thinking and handed back an empty reply. Passing "think": false to Ollama fixed it. A two-sentence nudge doesn't need deep thought.

Lesson two: Gemma is too nice. I'd written "do not invent other facts" in the prompt. Gemma still kept upgrading the air. Given "Satisfactory", it wrote "good", "perfect" or "best" in 5 of 6 test runs. That sounds harmless until you think about someone with asthma, who would plan their day very differently around "Satisfactory" and "perfect".

So I tightened the prompt: use the air quality label word for word, never upgrade it, and mention no times or numbers beyond the facts given. Same facts, 8 new runs: 0 of 8 broke the rules. The plans are a little less bubbly now, and a lot more trustworthy.

And if anything's missing, Bahar still shows up. No Ollama? A template sentence. No TabPFN? Gradient boosting. You always get a plan.

Honest caveats

The PM2.5 history comes from the CAMS atmospheric model via Open-Meteo, not ground sensors. It's free and has full hourly history, which makes it great for patterns. For ground truth, compare a few days against CPCB station readings for your area.
The size of the winter win depends on where the test windows fall. The single January window in the table shows 30%, but in an earlier run with windows a few days apart it was 10%. That's why I quote the 16% winter average rather than any one window.
With one winter in the data, I can't fully separate "TabPFN is better in winter" from "TabPFN is better when there's less history". Next winter will tell.
Recent TabPFN versions download their weights only after you accept a license with a free Prior Labs account.

Every run appends to data/plans_log.jsonl, so over time I can check whether the hour Bahar picked actually felt good outside.

Your turn 👇

I'd love to hear from you in the comments:

What's the worst hour for air in your city? Is it the morning rush, or the evening climb you can see in Hyderabad's forecast above?
If you try Bahar for your city, what window did it pick?

And now, the most important instruction in this post: close this tab and go outside. 🌿

I Built a $0 AI Code Reviewer Using GitHub Copilot CLI (No Vendor Lock-In)

tushar shah — Mon, 26 Jan 2026 11:09:03 +0000

This is a submission for the GitHub Copilot CLI Challenge

AI Code Reviews for $0.00? I Built a Provider-Agnostic Reviewer with GitHub Copilot CLI

What if AI code reviews didn’t cost $50/month—or lock you into a single model?

I ran into this problem while maintaining side projects, so I built an AI Code Reviewer that works with any LLM provider and can cost literally $0 per PR.

What I Built

AI Code Reviewer is an open-source GitHub Action that performs automated, AI-powered code reviews on every pull request.

In short:

🔌 Works with any OpenAI-compatible API (Groq, DeepSeek, Mistral, Gemini, Anthropic, OpenAI, etc.)
🧠 Uses a custom compression format (TOON encoding) to reduce token usage by 50–70%
💸 Supports free LLM providers → $0.00 reviews
⚡ Setup time: ~30 seconds
🔓 Fully open source (MIT)

This wasn’t just about building another AI tool—it was about giving developers back control over cost, models, and infrastructure.

Demo

📸 Github PR for sample:

“https://github.com/tusharshah21/ai-code-reviewer/pull/2”

📸 Screenshot:

“AI Code Reviewer leaving structured review comments on a GitHub PR”

Why I Built This

Most AI review tools today share the same problems:

Vendor lock-in
Opaque pricing
Closed source
Expensive for students, indie hackers, and OSS maintainers

I wanted the opposite:

You choose the model. You control the cost. You own the workflow.

My Experience with GitHub Copilot CLI (The Real Game-Changer)

I’m primarily a backend developer.

GitHub Actions, Octokit, and CI ergonomics were new territory for me.

Instead of tab-hopping between docs, blog posts, and Stack Overflow, I stayed inside my terminal and used GitHub Copilot CLI as a learning companion.

Concrete Examples

1. Fetching PR diffs with Octokit


bash
gh copilot suggest "how do i fetch pr diff using octokit"