Zero-Budget Release Notes: A Case Study in Free-Tier LLM Automation

A developer built a release-notes bot that automatically converts raw git history into user-facing notes using only free-tier LLM tokens and a free server. The project, which runs unattended on a schedule, uses MonkeyCode's free model access and a single Python file to collect commits, summarize them via an OpenAI-compatible endpoint, and render Markdown notes. The design prioritizes resilience, ensuring output continues even when the free model tier fails.

The current wave of AI tooling pushes teams toward bigger agents, bigger context windows, and bigger monthly bills. The opposite constraint produces a more honest design. This case study walks through one small project built on free model tokens and a free server: a release-notes bot that turns raw git history into user-facing notes, end to end, from background to lessons learned. The project started with a familiar annoyance. A library shipped weekly, and every release required a human to read forty or fifty commit messages and translate them into something a user could understand. The messages were technical, inconsistent, and occasionally embarrassing. Automating the translation with an LLM was the obvious fix, but the budget was exactly zero: no paid API credits, no paid server, no tolerance for a recurring bill. The goal had three parts. Generate concise, user-facing release notes from the git history between two tags. Run unattended on a schedule. Cost nothing. A fourth constraint appeared during design: the job had to keep producing output even when the free model tier failed, because a release process that depends on a rate limit is a release process that breaks on a Tuesday. The project used MonkeyCode's free model access and its free server option for hosting. Disclosure: This article was prepared as part of MonkeyCode's product outreach. At the time of writing, the free tier includes a 10-million-token allowance, but quotas and terms change, so the current numbers should be verified before any team relies on them. The architecture below does not depend on those specific numbers; it works with any OpenAI-compatible endpoint and any free server that can run cron. The implementation is a single Python file with three responsibilities: collect commits, summarize chunks, and write the notes file. The collect step runs git log between the two refs and keeps only the subject line of each commit. The summarize step sends chunks of twenty-five commits to an OpenAI-compatible chat endpoint, asks for a JSON array of categorized bullets, and validates the response. The write step renders the result into a Markdown file. The only dependencies are the openai and tiktoken packages. bash /usr/bin/env python3 """Generate release notes from git history using a free-tier LLM. Usage: python release notes.py <from ref <to ref --out RELEASE NOTES.md Environment: LLM BASE URL provider endpoint OpenAI-compatible LLM API KEY provider key LLM MODEL model name from the provider dashboard """ import argparse import json import os import subprocess import sys import time from pathlib import Path from openai import OpenAI CHUNK SIZE = int os.getenv "COMMIT CHUNK SIZE", "25" MAX TOKENS = int os.getenv "LLM MAX TOKENS", "400" MAX RETRIES = 3 SYSTEM PROMPT = "You turn raw git commit subjects into concise user-facing release notes. " "Return a JSON object with one key, 'items', an array of strings. " "Each string must start with a category: Feature, Fix, Docs, or Chore. " "Do not invent details that are not in the commits." def git log from ref: str, to ref: str - list str : result = subprocess.run "git", "log", "--oneline", f"{from ref}..{to ref}" , capture output=True, text=True, check=True, return line.split " ", 1 1 for line in result.stdout.splitlines if line.strip def chunks items: list str , size: int : for i in range 0, len items , size : yield items i : i + size def summarize chunk client: OpenAI, commit chunk: list str - list str : response = client.chat.completions.create model=os.environ "LLM MODEL" , messages= {"role": "system", "content": SYSTEM PROMPT}, {"role": "user", "content": "\n".join f"- {c}" for c in commit chunk }, , temperature=0.2, max tokens=MAX TOKENS, response format={"type": "json object"}, payload = json.loads response.choices 0 .message.content return payload "items" def fallback summarize commit chunk: list str - list str : categories = {"feat": "Feature", "fix": "Fix", "docs": "Docs", "refactor": "Chore"} grouped: dict str, list str = {} for commit in commit chunk: prefix = commit.split ":", 1 0 .lower category = categories.get prefix, "Chore" grouped.setdefault category, .append commit return f"{category}: {commit}" for category, commits in grouped.items for commit in commits def with retry client: OpenAI, commit chunk: list str - list str : size = len commit chunk for attempt in range MAX RETRIES : try: return summarize chunk client, commit chunk :size except Exception: if attempt == MAX RETRIES - 1: return fallback summarize commit chunk size = max 1, size // 2 time.sleep 2 attempt def main - int: parser = argparse.ArgumentParser parser.add argument "from ref" parser.add argument "to ref" parser.add argument "--out", default="RELEASE NOTES.md" args = parser.parse args commits = git log args.from ref, args.to ref if not commits: Path args.out .write text "No user-facing changes in this release.\n", encoding="utf-8" return 0 client = OpenAI base url=os.environ "LLM BASE URL" , api key=os.environ "LLM API KEY" notes: list str = for chunk in chunks commits, CHUNK SIZE : notes.extend with retry client, chunk body = "\n".join f"- {note}" for note in notes Path args.out .write text f" Release notes\n\n{body}\n", encoding="utf-8" return 0 if name == " main ": sys.exit main Three design decisions matter more than the code itself. First, the chunk size keeps every request far below the model's context limit, so a large release window is processed as many small requests instead of one fragile one. Second, the retry loop halves the chunk on every failure, which handles both rate limits and context overflows with the same mechanism. Third, the fallback summarizer is deterministic: it groups commits by conventional-commit prefix, so the job always produces a file, even if the model never answers. If the model does not support structured JSON output, the validation step rejects the response and the fallback takes over, which keeps the pipeline honest about its dependency. Deployment is deliberately boring. The free server runs a weekly cron job that executes the script between the two latest tags and commits the resulting file back to the repository. 0 9 1 cd /opt/release-notes && /usr/bin/python3 release notes.py v1.2.0 v1.3.0 --out RELEASE NOTES.md A missed run is harmless, because the script is idempotent and the git range can be replayed. The file is written atomically, so a partial write never ships. The interesting results are the failure modes, because that is where free tiers reveal their personality. The table below maps each scenario to the behavior the script implements. | Scenario | Observed behavior | Mitigation | |---|---|---| | Endpoint returns 429 rate limited | Request fails | Exponential backoff, then fallback summarizer | | Chunk exceeds the context limit | API error or truncated JSON | Chunk size halves on retry | | Model returns malformed JSON | json.JSONDecodeError | Re-request once, then fallback | | Empty diff between tags | No commits | Writes "No user-facing changes" and exits cleanly | | Free allowance exhausted | 402 or 403 errors | Fallback path keeps the release notes flowing | A sample of the output, formatted by the script, looks like this illustrative : Release notes - Feature: Added exponential backoff for rate-limited LLM calls - Fix: Corrected chunk-size overflow on large release windows - Docs: Documented the LLM BASE URL environment variable Token accounting is the part most teams skip. The prompt for a chunk of twenty-five commits costs roughly 1,200 input tokens, and the response roughly 300, but those numbers vary with commit length. The honest way to measure is tiktoken, not a guess: php from tiktoken import encoding for model def estimate tokens text: str - int: return len encoding for model "gpt-4o" .encode text With a 10-million-token allowance, even a pessimistic 2,000 tokens per chunk supports thousands of chunks. The arithmetic matters less than the habit: measure the prompt, multiply by expected runs, and keep the projected consumption below ten percent of the allowance so retries never exhaust the budget mid-cycle. Three lessons carried over to other projects. First, the fallback path is the real product; the LLM is an enhancement on top of it. Second, free tiers are burst budgets, not baselines, so the schedule must assume occasional 429s and empty replies. Third, a free server is a fine home for a weekly batch job and a poor home for a latency-sensitive endpoint, which is why the design kept all heavy work off the request path. The approach is wrong for several teams. Anyone processing customer data should not point it at a free tier with unclear retention. Anyone with a user-facing, latency-sensitive endpoint should not host it on a free server. Anyone who needs a guaranteed SLA should buy one. The bot is a tool for internal, low-frequency, non-critical automation, and it is honest about being that. The full script is above; forking it into a weekly cron job takes an afternoon. The project is small, the failure modes are contained, and the next release notes will write themselves. MonkeyCode's free tier is one way to get the tokens and the server, but the script works with any OpenAI-compatible endpoint, which is the point: the design, not the provider, is what makes the cost zero.