DEV Community: Shreyas

git-catchup CLI Tool

Shreyas — Mon, 26 Oct 2026 06:39:05 +0000

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

What I Built

git-catchup is a command-line tool that gives you a short briefing on a git repository so you can pick up where you left off.

When you return to a project after some time away, it takes effort to remember where you stopped. You typically have to read through recent commits, check what is uncommitted, and look for the TODO comments you left, just to rebuild the context before you can continue.

git catchup reduces that to a single command. Run it inside any repo and it prints a short briefing on the project and where you left off, so you can start working without reviewing the history first. It shows:

Done so far: recent commit subjects
Uncommitted: what has changed in your working tree
Open: TODO/FIXME comments, grouped by file
Notes: from your README and TODO/NOTES/ROADMAP files
Start here: one concrete next step

It is useful for anyone who works on side projects, open-source contributions, or several repos at once, and who would rather run one command than reread the history.

Demo

Summary of the repo state.

git catchup --dry-run prints exactly what the model receives.

Code

kilqwe / hacktoberfest-week-3

git-catchup

Catch up on where you left off. Come back to any repo, finished or not, and one command tells you what the project is, what's done, what's still open, and what you'd planned next. It reads your commits, uncommitted work, TODO/FIXME comments, README and notes files (TODO.md, NOTES.md, ROADMAP.md...), and a local open-weight model writes the briefing. Nothing leaves your machine.

$ git catchup

 git catchup | branch: feature/discount-codes (base: main)
 Last commit: 10 days ago | uncommitted edits: 2 days ago
 Uncommitted files: 3 | secrets redacted: 1

**Where you left off** ...
**State of the work** ...
**Next step** ...

Dates, counts and branch names come straight from git. The model only writes the narrative, because small models are bad at facts they can simply look up.

Install (Windows / macOS / Linux)

Install Ollama and pull a model: ollama pull gemma3:4b
pip…

View on GitHub

How I Built It

Open-source AI used

Models: open-weight gemma3:4b by default. I also tested qwen2.5:3b and llama3.2:3b.
Local inference: Ollama, called over local HTTP.
Stack: Python 3.11+, standard library only, no dependencies. The model is selected with --model.

How the project is built around the model

The model has a deliberately small job, and everything that can be checked is handled by plain code:

Python collects the facts. Commits, uncommitted files, TODO/FIXME comments and notes are read from git and printed directly. None of that comes from the model.
Secrets are removed before prompting. Secret-looking lines are replaced with [line omitted], and .env, .pem and key files are dropped from diffs. This is regex-based and best-effort.
Python picks the "Start here" item. Priority is a failing test, then a TODO/FIXME (edited files first), then the first line of a notes file.
The model writes three short fields only: project, left_off and next_step. The prompt is built conditionally, so the model only sees instructions that apply to the repo.
The output is validated. It is checked against a JSON schema, retried once with the reasons if a check fails, and replaced per field by a Python fallback if it still fails. Checks include no secret-related words, no backticked filenames that don't exist in the repo, and next_step must be an action, not a question or a list.

git catchup --dry-run prints exactly what the model would see, so the prompt can be audited.

Comparing models

Same branch, three models, one flag. Everything above the divider is identical because plain code writes it from git. Gemma's briefing was cleanest, Llama's accurate but vague, and Qwen said a discount code had been added when it was already committed. Model quality also varies from run to run, which is why facts never come from the model.

In all three runs the guard log was empty, so no guard fired.

Why Does Open Innovation Matter?

git catchup runs on unpushed, half-finished work, which is the code you are least likely to want to send to a third party. Open-weight models run through Ollama made that possible:

Your code stays on your machine. The briefing is generated locally, so work in progress is never uploaded anywhere.
It works offline. There is no network dependency, so it runs on a plane or with Wi-Fi off.
Swapping models takes one flag. I compared Gemma, Llama and Qwen on the same branch with --model, with no new account, API key or billing.
It is free to run. There is no per-use cost, so it can be run every time you open a repo.
The prompt is fully visible. --dry-run prints exactly what the model receives, so nothing is hidden between the repo and the model.

Closed APIs can also do this task, and many support structured output. For a command you run often on private code, local open-weight models were the better fit.

The Lazy Payoff

On the demo branch I last touched 15 days ago, the manual route to get back into context is: read four commits, check git status, search for TODOs and open the notes file. git catchup gives all of that in one screen, plus a suggested starting point (discounts.py, the TODO about unknown codes).

The cost of running it is a single command.

Prize Categories

Best Use of Gemma. git catchup uses gemma3:4b as its default model, run locally through Ollama. In my three-model comparison on the same branch, Gemma's briefing was the cleanest: accurate, with a concrete next step taken from the TODO in the code.

Cred_Pred (A Credit Burn Analyzer)

Shreyas — Mon, 19 Oct 2026 06:37:26 +0000

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

What I Built

Cred_Pred tells startups and solo developers when their cloud credits will run out, before they do.

Founders on AWS Activate and similar programs get thousands of dollars in credits and then never track the burn. The credits vanish months early, or they expire half unused. cred_pred reads your Terraform (a file, a folder, or terraform show -json plan output) or a plain-English description. It prices the resources live through the Infracost API and reports monthly burn, runway in months, the run-out date, and how many credits will expire unused. A local open model writes a one-line cost saving tip.

A GitHub Action runs it on every pull request and comments with how the PR changes your burn and runway. For example, a PR that moved a t3.large to a t3.xlarge and added a load balancer got this comment:
burn $279.03 to $356.19 (+$77.16/mo), runway 17.9 to 14.0 months.

Who pays: the CLI and the Action are free and open source. The side hustle is a hosted or scheduled version (weekly runway emails, Slack alerts, live spend tracking) as the paid tier.

Demo

Github Actions Comment

Report Generated for the startup's terraform files

Code

kilqwe / hacktober-week-2

Credit burn predictor for startups and solo devs: feed it your Terraform, get live-priced monthly costs, how many months your cloud credits will last, and a cost-saving tip from a local open-source AI model. Runs in CI and comments on PRs. Hacktoberfest Week 2: Side Hustle.

Cred_Pred (A Credit Burn Analyzer)

Know when your cloud credits will run out before they do.

cred_pred reads your Terraform (or a plain-English description), prices the resources live through the Infracost API, and tells you your monthly burn, your runway in months, the date the credits run out, and how many credits will expire unused. A local open model (Ollama) writes a one-line cost-saving tip. A GitHub Action runs it on every pull request and comments with how the PR changes your burn and runway.

Built for startups and solo developers with cloud credits (for example AWS Activate) who never track the burn. Hacktoberfest Week 2, theme: Side Hustle.

Quick start

git clone <this repo>
cd <this repo>
pip install -r requirements.txt
# a free key from https://www.infracost.io
$env:INFRACOST_API_KEY = "your-key"      # or put it in a .env file

# local

…

View on GitHub

How I Built It

The rule behind the design: the model never does arithmetic and never prices anything. Every dollar figure comes from live Infracost pricing, a local cache, or a flat estimate labelled as one. Local open models (via Ollama) have two jobs only:

Turn plain English into a resource inventory. Python validates every entry (allowed kinds, instance-type pattern, sane quantity) before trusting it.
Write the advisor tip, behind a guard. The guard rejects a tip that contains a dollar or percentage figure that was not in the facts it was given, or that names an instance type the user doesn't have. The model gets one retry, then the tool falls back to a rule-based tip.
Models: Gemma 3 (gemma3:4b) is the default everywhere: the CLI, and the GitHub Action on the Actions runner. Swapping models takes one flag (--model) or one GitHub variable (CRED_MODEL). Temperature 0 and a fixed seed make runs repeatable.

I benchmarked three models on 8 plain-English descriptions with known answers, and 3 advisor tips each, with prices fixed so every model saw identical facts:

Model	Inventories exactly right	Item F1	Extraction errors	Avg extract time	Tip passed 1st try	Tip needed retry	Tip fell back to rules	Avg tip time
gemma3:4b	5/8	91%	0 failed, 3 dropped	3.4s	3/3	0/3	0/3	3.0s
qwen2.5:3b	8/8	100%	0 failed, 0 dropped	2.9s	2/3	0/3	1/3	3.6s
llama3.2:3b	4/8	86%	0 failed, 2 dropped	3.0s	0/3	3/3	0/3	6.0s

What I learned:

Same numbers, different tips. Costs were identical to the cent across models, because the model never touches the math.
The guard caught real hallucinations. Earlier in development, one model invented an instance size that doesn't exist (db.r5.xsmall), and another claimed a made-up size gives more power for the same cost. That is how the instance-name guard got added. In the final run, the guard rejected llama3.2:3b's first attempt on all three tips.
The guard doesn't catch bad advice. One tip said to upgrade to a more powerful instance to reduce costs. It had no invented figure or name, so it passed. A Gemma tip said shrinking database storage would "significantly lower" a bill where storage was $2.30 of $279. Guards check facts, not judgment.
Model size didn't predict quality. qwen2.5:3b was the most accurate at extraction. llama3.2:3b, also 3B, was the weakest and the slowest at tips, and its tips ran to two or three sentences when I asked for one line.
Where Gemma did well: gemma3:4b was the only model whose tips all passed the guard on the first try. It was second on extraction, and extraction is the weak spot: it got 5 of 8 inventories exactly right.
Limitations: flat us-east-1 estimates (labelled in the report) for EBS, RDS storage, NAT, load balancers, Elastic IPs, EKS and Fargate. Usage-based costs (data transfer, load balancer capacity, CloudFront and S3 traffic) are invisible to Terraform, so real burn is higher. Lambda, S3, CloudFront and ECR aren't priced, and the report names them. The .tf parser can't expand modules or for_each, so plan JSON is the exact route.

Why Does Open Innovation Matter?

Privacy. Infrastructure files describe your network, databases and account layout. With a local model, they never leave your machine or CI runner. With a hosted API, every pull request would send them to a third party.
Cost. Inference is free, so the tool can run on every PR instead of once a month. A per-call fee would push you to run it less.
Swappable models. Changing models is one variable, which made the bake-off possible and let me see that the model with the best extraction (qwen) wasn't the one with the safest tips (gemma3).

My First User

A friend who works at a startup let me run the tool on a real Terraform project: 11 files covering an ECS Fargate service, an ALB, an EC2 instance, RDS Postgres, and CloudFront and S3. It's an older project, so I can't compare against a real bill.

cred_pred priced the stack at $81.37/mo, about 61 months of runway on $5,000 in credits. It named the four resource types it couldn't price (CloudFront, S3 and two ECR types), so the report flags the runway as an upper bound. The EC2 and RDS lines came back from live Infracost pricing. The biggest line, Fargate at 35% of the total, is a labelled flat estimate, and the report notes that Spot would make it cheaper.

Prize Categories

Best Use of Gemma: Gemma runs the advisor tip and plain-English parsing locally through Ollama. gemma3:4b is the default model in the CLI and in the GitHub Action on the runner. It was the only model whose tips all passed the guard on the first try in the bake-off.

Trail Echo: An Offline Bird Logger Built on BirdNET

Shreyas — Mon, 12 Oct 2026 06:03:19 +0000

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

What I Built

Trail Echo is an offline bird logger. It listens in 60-second chunks, identifies species with the open BirdNET model, throws away chunks where nothing was heard, and gives you a dashboard of every bird you passed once you're back.

The touch-grass idea: the screen is for afterwards. During a walk, the device sits in a bag or pocket and listens, so you can look up at the trees instead of down at an identification app. At the end of the walk you get a species list and a timeline of when each bird was heard. It's for casual walkers and city dwellers who hear birds all the time and never learned their names.

Current status: the live logger is tested with system-audio capture on PC and microphone. Also tested with microphones on phone that connects to the same pipeline after media type conversions (from .m4a to .wav); field audio to be recorded on a phone and run through the same pipeline.

Demo

Code

kilqwe / hacktoberfest-week-1

Offline bird logger built on BirdNET. Hacktoberfest 2026, Week 1: Touch Grass.

Trail Echo

Offline bird logger built on BirdNET It listens in 60-second chunks, identifies species locally, discards chunks with no detections, and shows everything heard in a Streamlit dashboard.

Built for Hacktoberfest 2026, Week 1: Touch Grass. The idea is to leave the device in your pocket during a walk and look at the results afterwards.

How it works

capture audio → BirdNET analysis → CSV per chunk → Streamlit dashboard

Chunks with no detections are deleted automatically (audio and CSV), so storage only grows when something is heard.
All inference runs locally. No audio leaves your machine.

Status

Tested: The microphone successfully captures the sound of the birds (captured using xeno-canto and youtube). Using BirdNET-Analyzer the app can successfully identify the bird species with confidence of >95% Not yet tested: outdoor field recording on a real walk.

Setup

python -m venv .venv
.venv\Scripts\activate          #

…

View on GitHub

How I Built It

Open model: BirdNET (TensorFlow, Cornell Lab of Ornithology and Chemnitz University of Technology), run locally through birdnet-analyzer. The species list it loaded had 6,522 species.
Capture: sounddevice for microphones and WASAPI loopback via PyAudioWPatch; soundfile writes the chunks.
Pipeline: record a chunk, call BirdNET, read the CSV, delete the audio and CSV if there are no detections.
Dashboard: Streamlit and pandas: species table, detections per minute, raw log.

What broke along the way:

BirdNET failed silently because I hid subprocess errors, so the script printed success while writing nothing.
The laptop mic was near-silent, and audio enhancements gated sustained sounds like chirping after about a second.
Some device paths returned garbage values in the billions, so I added level checks.
Storage: 60 s of WAV is about 5 MB, so chunks with no detections are deleted automatically.

Why Does Open Innovation Matter?

A bird logger hears everything around you, including conversations on the trail. Because BirdNET's weights are public, inference runs entirely on my own machine:
no audio leaves the device, nothing needs a signal on a hillside, and there are no per-request fees for hours of recording. I could also read the pipeline and tune it (confidence threshold, chunk length, and later location and week filters) instead of waiting for an API to expose those options. A closed cloud API would have meant uploading hours of ambient audio. One caveat: BirdNET's model is licensed CC BY-NC-SA, so this is a non-commercial project.