How to verify a release window

Open source AI projects and tool announcements, April 25-26, 2026

You searched a two-day window expecting a clean list. The pages that answer it confidently are mostly machine-written summaries with no link you can open to confirm a single date. This guide takes the other path: it shows one open source AI project's real April 25-26 release traced to the exact commit, then hands you the method to check any project yourself.

Matthew Diakonov, Written with AI

Published May 15, 20268 min read

Direct answer, verified 2026-05-15

There is no authoritative single roundup of every open source AI project announced on April 25-26, 2026. No one maintains a canonical dated index, and projects do not announce on a shared schedule. A fully verifiable example from that window is fazm, an open source macOS AI agent: it committed to its public repository on April 25 and 26 and tagged release 2.4.2 on April 26, 2026. To answer this for any project, read its GitHub releases page and its changelog file directly. The rest of this page shows how.

Why the roundups of that weekend do not hold up

Run the obvious search and you get articles that look thorough. They have headers, bullet lists, project names, sometimes a paragraph of context per item. What they do not have is a single link that lets you confirm a project shipped on April 25 or April 26 rather than on April 12 or May 3. The names are real often enough. The dates are decoration.

This is a structural problem, not a quality problem. A 48-hour window is too narrow for a human editor to cover and too specific for a model to know, so the model fills the gap. It writes a list that reads as authoritative because the format signals authority. The way to tell the difference is not to read more carefully. It is to ask one question of every claim: can I open the artifact?

A generated roundup says

✗"Project X launched late April 2026"
✗No commit hash, no tag, no release URL
✗A date inferred from the surrounding prose, not from a source
✗Cannot be checked, so cannot be trusted

A primary source says

✓Commit bdf57afd, dated 2026-04-26, in a public repo
✓Tag v2.4.2+2004002-macos points at that commit
✓Changelog entry sits in the same commit history
✓You can open every one of these right now

A worked example: one project's actual April 25-26

fazm is a native macOS app that wraps Claude Code and Codex through the Agent Client Protocol. It is open source at github.com/mediar-ai/fazm, which makes it a clean test case: every claim below can be opened and checked. Here is the entire April 25-26, 2026 window in its commit history, produced by filtering the log by date.

git log, April 25-26 window

That is the whole announcement for those two days. One tagged release, two supporting commits. The tag v2.4.2+2004002-macos points at commit bdf57afd, and running git show on the tag prints the commit date: 2026-04-26, 14:12 local time. No guessing. The date of the announcement is the date of the commit the tag points at. You can confirm it yourself on the commit page.

What release 2.4.2 actually changed

These four lines are the verbatim contents of the 2.4.2 entry in CHANGELOG.json. None of them is a headline feature. All of them are real, user-visible, and dated.

Smart (Opus) preference now persists

An earlier release moved the backend to an ACP model identifier. The stored string "opus" no longer mapped, so the Smart setting reset after an update. 2.4.2 maps the old value to the new ID.

Clearer workspace picker label

The button in the workspace directory picker changed from "Open" to "Select", so it reads as choosing a folder rather than opening one.

Custom API Endpoint help text

The help text for the custom endpoint field now names local LLM bridges as an example, so users routing through a local model know the field is for them.

Stripe cancellation redirect fixed

Returning to the app after cancelling a subscription checkout no longer lands on an error page.

The method: verify any project in four steps

The worked example used fazm because its repository is public and the trail is short. The same four steps work for any open source AI project. You are not reading articles about a project. You are reading the project.

Confirm what shipped in a date window

Open the project's GitHub releases page

Each tagged release shows the date it was published. If a release falls inside your window, that is a real announcement with a date you can cite.

Filter the commit history by date

On a clone: git log --since=2026-04-25 --until=2026-04-27. On GitHub, the commits view shows the same timeline. This catches work that landed without a tag.

Read the changelog file in the repo root

A CHANGELOG file records what each version changed, in the words of the people who shipped it. This is the source a roundup paraphrases, so go to the source.

Cross-check the tag against the commit

git show on the tag prints the commit it points at and that commit's date. The announcement date is the commit date, not the date someone wrote about it.

When a date does not resolve to a tag, a commit, or a changelog line, you have not found a fact. You have found a sentence. For a two-day window that distinction is the whole exercise: the noise is enormous and the signal is small, and only the artifact tells them apart.

Why a four-line patch counts as an announcement

fazm 2.4.2 will never appear in a weekend roundup. It is too small. There is no model, no benchmark, no demo video. But it is a genuine open source AI tool announcement, and reading it closely tells you more about how these projects work than any list of launch names.

Take the first line of the release. The fix exists because an earlier version moved fazm's agent backend to an Agent Client Protocol model identifier. The app had been storing the user's Smart model preference as the literal string opus. After the backend change that string no longer mapped to a real model, so the preference silently reset to default the next time the app updated. The 2.4.2 patch maps the stored value forward to the new identifier. That is the unglamorous reality of shipping an agent that wraps a fast-moving protocol: integration debt lands as small corrective releases, and those releases are most of what an open source AI project announces.

The third line is the same story from the other side. fazm 2.4.2 updated the help text on its Custom API Endpoint field to name local LLM bridges as an example. No code changed; a sentence did. But that sentence tells users routing an agent through a local model that the field is meant for them. For an open source, local-first tool that is a real product decision, shipped in a dated, tagged release. None of this is roundup material. All of it is verifiable, and verifiable is the only standard that survives a two-day window.

Want the open source AI agent from the worked example

Walk through how fazm wraps Claude Code and Codex on macOS, and where its release cadence is headed.

Questions about open source AI announcements

Frequently asked questions

Is there an official list of every open source AI project announced on April 25-26, 2026?

No. No organisation maintains a canonical, dated index of open source AI releases, and the open source world does not announce on a shared schedule. Projects ship when they ship. What you find online for a 48-hour window like April 25-26, 2026 is almost always a single AI-generated article that lists project names with no commit hash, no tag, and no link you can open to confirm the date. Treat any such list as a starting point for names to look up, not as an answer. The only reliable answer is per-project: open the project's own repository and read its release history.

How do I verify what a specific open source AI project shipped on an exact date?

Three primary sources, all public, all on the project's own repository. First, the GitHub releases page lists tagged releases with the date each tag was published. Second, the commit history can be filtered by date; from a clone the command is git log --since=2026-04-25 --until=2026-04-27, and on GitHub the commits view shows the same timeline. Third, the changelog file in the repository root records what each version changed. If a roundup claims a project shipped something on a date, you should be able to land on a tag, a commit, or a changelog entry that matches. If you cannot, the claim is unverified.

What did fazm ship on April 25-26, 2026?

fazm, an open source macOS AI agent, made three commits to its public repository in that window and tagged one release. On April 25 commit 2fbc891c distinguished silent from modal feedback in analytics. On April 26 commit bdf57afd tagged release 2.4.2 (tag v2.4.2+2004002-macos), and commit be29a3c7 updated an internal SQL tool description. Release 2.4.2 carried four changes: a fix for the Smart (Opus) model preference not persisting after an app update, a clearer label on the workspace directory picker, updated Custom API Endpoint help text mentioning local LLM bridges, and a fix for the Stripe checkout cancellation redirect. Every item is in CHANGELOG.json in the repository.

Why trust a project's changelog over a roundup article?

Because the changelog sits next to the code that implements it, in the same commit history, in a public repository anyone can clone. A roundup article is generated text written by someone who did not ship the change and usually did not read the diff. When the changelog and the article disagree, the changelog wins, because the changelog is part of the artifact and the article is a description of it. The check is mechanical: a changelog claim should resolve to a commit; a roundup claim often resolves to nothing.

A changelog entry is not dated. How do I find when a change actually shipped?

Run git log on the changelog file itself. The command git log --follow -p CHANGELOG.json shows every commit that touched the file, with the author date, so you can see exactly when each line was added. The release tag is the other anchor: a tag like v2.4.2+2004002-macos points at one specific commit, and git show on that tag prints the commit date. For fazm 2.4.2 that resolves to commit bdf57afd, dated 2026-04-26. The date of the announcement is the date of the commit that the tag points at, not the date someone wrote about it.

Why do small open source AI projects ship tiny patches and call them releases?

Because for an open source project the release is the announcement. There is no separate press cycle. fazm 2.4.2 is a four-line release, and one of those lines exists only because an earlier release changed something underneath it: the agent backend moved to an ACP model identifier, and the stored preference string opus no longer mapped to anything, so the Smart model setting silently reset after an update. The 2.4.2 patch maps the old string to the new identifier. That is a real, user-visible bug fixed in a dated, tagged release. It would never appear in a weekend roundup, because roundups index large launches, not the small corrective commits that make up most of what open source AI projects actually ship.

Does 'announcement' mean a blog post or a release?

For commercial AI labs an announcement is usually a blog post or a keynote, and the artifact follows later. For open source projects the order is reversed: the commit lands, the tag is pushed, the release notes are written, and that tagged release is the announcement. A blog post, if it exists at all, is downstream of the tag. So when you are looking for open source AI announcements in a date window, you are really looking for tags and commits in that window, not for press coverage. That is why the method in this guide starts at the releases page, not at a search box.

What is fazm, and why is it the worked example here?

fazm is a native macOS app that wraps Claude Code and Codex through the Agent Client Protocol, with persistent sessions that survive a restart, one-click chat forking, and no auto-compacting of context. It is fully open source at github.com/mediar-ai/fazm. It is the worked example in this guide for one reason: it is a real open source AI project that shipped inside the April 25-26, 2026 window, and every claim about what it shipped can be opened and checked in its public repository. The point of the guide is the method, and fazm is the case where you can run the method end to end.