Free Models, Free Server: Building a Changelog Robot in 30 Minutes

I used to dread writing changelogs. Every release meant digging through two weeks of commits, separating the meaningful from the noise, and then rewriting it all into something a human would actually read. It was the kind of task I kept postponing until a release date forced me into an hour of copy-paste and guesswork.

Then I started using MonkeyCode, an open-source coding assistant that happens to ship with something I had never counted on: free models and a free server. The project is developed by a team that believes evaluation should be free, so every account gets access to a set of models and a managed server without a credit card. That is not a trial period; it is a standing resource for anyone who wants to measure an agent before paying.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

This article is a thirty-minute workshop. You will build a small robot that reads your git history, extracts the last ten commits, and uses a free model on MonkeyCode's free server to turn them into a clean changelog entry. You will also see exactly where the tokens go, because that matters more than the output.

Let me start with the artifact. Create a file called commit_reader.py in a fresh MonkeyCode project:

import subprocess
import json

SINCE = "HEAD~10"

def get_commits(since):
    result = subprocess.run(
        ["git", "log", "--oneline", since],
        capture_output=True,
        text=True
    )
    lines = result.stdout.strip().splitlines()
    commits = []
    for line in lines:
        if line.strip():
            hash_id, _, message = line.partition(" ")
            commits.append({"hash": hash_id, "message": message})
    return commits

if __name__ == "__main__":
    commits = get_commits(SINCE)
    with open("commits.json", "w") as f:
        json.dump(commits, f, indent=2)

Run that script once inside the terminal on MonkeyCode's free server. You will get a JSON array like [{"hash": "abc1234", "message": "fix: handle empty cache"}]. That output becomes the raw material for the model.

Now create a second file called changelog_prompt.md with this content:

You are a release notes writer.
Read `commits.json`.
Rewrite the commit messages into a cohesive changelog for end users.
Use present tense, group by change type, and do not mention internal refactors.
Output only the changelog markdown.

Here comes the interesting part. In MonkeyCode's chat, select both files and type:

Follow changelog_prompt.md, but use commits.json instead of running the script again.

Watch what happens. The free model reads the JSON, understands the structure, and produces a changelog that groups fixes, features, and chores. It may even catch the ugly messages and turn them into something a stakeholder would appreciate.

The whole cycle takes about three minutes and roughly three thousand tokens on a normal repository. That is the number you should remember. Three thousand tokens per release. If your repository has a busy main branch, you can bump SINCE to HEAD~20 and watch the cost climb to five thousand. The model is not reading the full diff; it is reading only the commit messages, which is why the input stays small.

But wait, I can hear someone complaining: "Why not use a regex to sort commits? Why involve a model at all?" Good question. A regex can split feat: from fix:, but it cannot rephrase a commit that says "update stuff" into a clear note like "Improved error handling on the login screen". That is the difference between a formatter and a writer. The model is not there to structure data; it is there to add judgment.

Now let me show you the decision matrix I keep in my head when relying on free infrastructure.

Situation	Use MonkeyCode free models?	Why
Internal tool, no sensitive data	Yes	Free server fits the load
A feature with a hard deadline	Maybe	Free tier has no uptime SLA
Code under NDA	No	Free server runs outside your control
One-off analysis	Yes	You pay nothing

The pattern is simple: if the data is safe and the task is bursty, the free server makes sense. If you need a guarantee or isolation, run the same setup locally with your own keys.

There are limits, and I want to be honest about them. The free models on MonkeyCode are powerful, but they are not the absolute frontier of reasoning. For a changelog robot, they are overkill. For a complex multi-file refactor, you may hit the context ceiling. The free server also gets restarted occasionally, so you should not host a production endpoint there. You can, however, schedule a daily cron job on your own machine that calls MonkeyCode's free server with a webhook, as long as you accept that the response may be delayed outside business hours.

Who should not use this? Teams that already have a rigorous release process with automated tooling will find little value in a model rewriting their notes. Developers who cannot upload even commit messages to a third-party server should stay away. And anyone who expects a permanent free tier to replace a paid subscription is going to be disappointed, because free resources are evaluation tools, not production promises.

Five minutes ago you did not have a changelog robot. Now you have a two-file script, a prompt, and a measured number. The next time you cut a release, run the script, paste the JSON, and let the free model do the rewriting. You will get a changelog that reads like a person wrote it, and you will know exactly what it cost you: nothing but three thousand tokens from a balance that resets with your account.

If you are curious about the boundaries of those free models and that free server, the only way to test them is to open a project and push them. That is what I did, and it turned my most dreaded chore into a thirty-minute experiment that now runs every Tuesday. Try it once, and you may start looking forward to the release notes too.