MAY 2026 / READ THE FIXES, NOT THE STAR COUNTS

New AI projects on Hugging Face or GitHub, May 2026. Skip the star counts. Read the bug fixes instead.

Every monthly roundup of new AI projects is a list ranked by attention. That list is wrong within a week and it cannot tell a launch-week demo from a tool people actually use. This guide gives the honest answer to where new projects surface in May 2026, then shows the one test that predicts survival. The worked example is a real project's complete month, read line by line from a public file.

Matthew Diakonov, Written with AI

Published May 17, 202610 min read

Direct answer, verified 2026-05-17

Neither Hugging Face nor GitHub publishes an official dated list of new AI projects for May 2026. Both order discovery by a rolling trending score, which is a popularity signal, not a calendar index. To see what is genuinely new, read individual projects on three live feeds: huggingface.co/models sorted by trending, huggingface.co/papers/trending, and github.com/trending.

The rest of this page is about what to do once you have a candidate: how to tell, in two minutes, whether it is real.

Why a list is the wrong thing to ask for

The query behind this page is a request for a list: tell me what new AI projects appeared in May 2026. The honest response is that the list you want does not exist, and the lists you can find are built on the weakest signal available.

A GitHub star is a bookmark. It records that one person, on one day, found a repository interesting enough to save. During a coordinated launch a project can collect thousands of them in a weekend. A star never decays. The repository can stop building, lose its only maintainer, and break against the current model APIs, and the star count keeps climbing on residual attention. Hugging Face download counts have the same problem in a different shape. The Spring 2026 State of Open Source on Hugging Face report found the catalog is heavily concentrated: the top 200 most downloaded models account for roughly half of all downloads, and about half of all models have fewer than 200 total downloads. Most of what gets described as a new AI project is a real upload that was never adopted past week one.

So a roundup ranked by stars or downloads is mostly noise sorted by how loud each launch was. What you actually want to know about a project is different and quieter: is anyone using it, and is anyone maintaining it. There is one artifact that answers both, and it is not the README.

The test: read 30 days of bug fixes

Feature announcements are written for attention. Bug fixes are written for users. Anyone can publish a feature list on launch day from an empty repository. Only a project with real users accumulates a stream of specific, reproducible fixes, because every fix traces back to a person who hit that exact problem and reported it. The test takes about two minutes per project.

The two-minute project test

1
Open the dated record
Find CHANGELOG.json, the Releases page, or git log. Ignore the README and the star count.
2
Count fixes against features
Over the last 30 days, tally how many items are bug fixes and how many announce new features.
3
Read what the fixes describe
A specific, reproducible bug is a fingerprint of a real user. Vague fixes or none at all are a warning.

A demo nobody runs produces no bug reports, so it produces no fixes. A changelog that is all features and no fixes is telling you the project has no users, or that the maintainer is not honest about what breaks. A changelog dense with small dated repairs is telling you the opposite. The next section runs this test on a real project, in full.

Worked example: one open-source project's entire May

Fazm is an open-source macOS app that wraps Claude Code and Codex in a native interface. It is the project I work on, so I can show its month with no guessing. Every number below comes from one file: CHANGELOG.json at the root of the public repository. You do not have to trust the summary. You can run the count yourself.

0releases shipped in May 2026

0of 16 calendar days had a release

0individual change-line items

0of those 89 were new features

Through May 16, Fazm shipped 26 releases, versions 2.7.1 through 2.9.22, on 15 of the month's first 16 days. Those releases hold 89 individual change-line items. Now apply the test. Of the 89 items, 50 begin with the word Fixed. Exactly 6 announce a new feature. The remaining 33 are removals, refactors, and behavior corrections. That is the shape of a healthy month: overwhelmingly repair, almost no headline features. Here is the command that produces the release count, run against the live file.

verify-fazm-may-2026.sh

That reproducibility is the part a roundup cannot give you. A list of project names is a claim. A dated changelog you can fetch and count is evidence. When you are deciding whether a new May 2026 project is worth an afternoon, you want evidence.

Read the fixes, one at a time

The count tells you a project is busy. The wording of the fixes tells you it is being used. Below are five real entries from Fazm's May 2026 changelog. For each one, the second line is what that fix reveals to an outsider who never saw the bug report behind it.

v2.7.12026-05-01

Fixed a memory leak from orphan ACP bridge processes that accumulated across crashes, each one consuming roughly 600MB.

What this tells an outsider: Nobody finds a leak this size in a demo. It surfaces only after the app has run for hours, crashed, and been restarted by a real person many times over.

v2.7.32026-05-03

Fixed an empty conversations tab and silently failing chat saves caused by a poisoned SQLite connection; the database pool now auto-reopens after persistent disk I/O errors.

What this tells an outsider: A disk I/O error on a specific machine, reported by a user who lost a save. You cannot anticipate this class of bug. You can only fix it after someone hits it.

v2.9.12026-05-08

Fixed a data-loss bug where legacy chat databases were deleted even when the merge into the active database failed; failed sources now move to a merge-failed quarantine folder.

What this tells an outsider: Data loss is the bug users report loudest. The fix being a quarantine folder, not just a patch, signals a maintainer who expects the failure to recur and is designing for it.

v2.9.202026-05-15

Fixed a CPU spike caused by the voice follow-up microphone indicator animating while its window was hidden.

What this tells an outsider: Someone profiled CPU usage, noticed a spike, and traced it to an animation running off-screen. That is the work of a team dogfooding its own product, not shipping and moving on.

v2.9.222026-05-16

Fixed pop-out chat losing conversation history when the workspace changed between turns; queued messages now carry their per-window workspace and the bridge replays history into the new session.

What this tells an outsider: This bug only exists for someone running multiple chat windows against different folders at once. It is a power-user report, which means the project has power users.

None of these are exciting. A 600MB memory leak from orphaned bridge processes, a CPU spike from an animation running behind a hidden window, a quarantine folder for chat databases that failed to merge. That is exactly the point. You cannot script these fixes from imagination. Each one is the residue of a real session on a real machine. A project whose changelog reads like this in May 2026 will still exist in July. A project with a glossy feature list and no fixes is a coin flip.

What the six features were, and why they matter less

Six of the 89 May items announced a new capability. The experimental Codex backend that routes GPT-5 family models through OpenAI's Codex CLI. Per-window pre-warmed sessions so a new pop-out chat answers its first message instantly. A Sign In button on the Claude account settings card. A sticky stack of recent prompts that stays visible as you scroll. Toggles to disable individual keyboard shortcuts when they clash with other apps. A three-dot typing animation replacing a spinner.

That is a modest list, and it should be. A project that ships six small features and fifty fixes in a month is spending its time where its users are. A project that inverts that ratio is either very young or is optimizing for a roundup rather than for the people running it. When you scan a new May 2026 project, do not be impressed by a long feature section. Be impressed by a long fix section with specific, unglamorous entries.

One of those fixes is worth a closer look because it points at a structural choice. Fazm keeps full chat history live in context instead of auto-compacting it, which is why several May entries are about pop-out windows replaying their complete transcript correctly across a session recovery. That design decision is covered in the guide on Claude Code auto-compacting and token waste. The reason it shows up in the changelog at all is that real users were running multi-window sessions long enough to expose the edge cases.

Where to actually look in May 2026

Hugging Face and GitHub are not competitors for your attention. They publish different halves of the same thing. Hugging Face publishes weights, tokenizer configs, chat templates, and quantized variants. GitHub publishes the agent harnesses, MCP servers, inference engines, and the apps that turn weights into something a person runs. A weight file does nothing on its own. An agent still needs weights to talk to. A genuinely useful project from May 2026 usually shows up in both places.

So the practical routine is three feeds, checked directly, not through a roundup. Sort huggingface.co/models by trending for new weights. huggingface.co/papers/trending surfaces research with linked code before it has a polished repository. And github.com/trending shows the code. For every candidate any of them returns, do not stop at the README. Open the Releases page or the changelog and run the two-minute test. The companion guide on Hugging Face or GitHub for new AI projects in April 2026 goes deeper on why the two platforms publish different things.

The skill worth building is not finding more new projects. That part is trivial and the feeds never run dry. The skill is discarding, fast, the ones that will not exist in a month. A changelog and a fix-to-feature ratio do that in two minutes. A roundup never can.

Want to see a project's month from the inside?

Book a call and I will walk you through how Fazm gets built, release by release, and how the same lens applies to any AI project you are evaluating.

Questions about new AI projects in May 2026

Frequently asked questions

What new AI projects launched on Hugging Face or GitHub in May 2026?

There is no single canonical list, because neither platform publishes one. Hugging Face and GitHub both order discovery by a trending score, which is a popularity signal computed over a rolling window, not a calendar index of what shipped on a given date. In May 2026 the honest places to look were three live feeds: huggingface.co/models sorted by trending for weights and quantized variants, huggingface.co/papers/trending for research with linked code, and github.com/trending for agent harnesses, MCP servers, inference engines, and apps. A useful project usually has a presence on both platforms, the model on one and the code that runs it on the other. Rather than trust a third-party roundup, this guide shows how to read any project's own dated release record, using the open-source macOS agent Fazm as a fully verifiable worked example.

Is there an official list of AI projects released in May 2026?

No. There is no dated release index on either platform. The closest honest substitute is each project's own record: a GitHub Releases page, a CHANGELOG file, or the commit history with timestamps. Those are authored by the maintainer and tied to real dates. A roundup written by someone else is a secondary, lossy source. It goes stale within days, it cannot tell a launch-week demo from a maintained tool, and it usually ranks by star count, which is the weakest signal on the page.

How can I tell a maintained AI project from a launch-week demo?

Open the changelog or the Releases page and count two things over the trailing 30 days: how many releases shipped, and how many of the line items are bug fixes versus new feature announcements. A project that ships small, dated, specific fixes every few days is being used by real people who hit real problems. A repository with one large launch commit, a spike of stars, and nothing since is a demo that already peaked. Bug fixes are the highest-signal artifact in the whole repository, because a demo nobody runs produces no bug reports and therefore no fixes.

What did the open-source Mac agent Fazm actually ship in May 2026?

Through May 16, Fazm shipped 26 releases, versions 2.7.1 through 2.9.22, across 15 of the 16 calendar days of the month. Those 26 releases contain 89 individual change-line items in CHANGELOG.json at the root of github.com/mediar-ai/fazm. Of those 89 items, 50 begin with the word Fixed and only 6 announce a new feature. The rest are removals, refactors, and behavior corrections. That ratio is the point of this guide: a healthy month of an actively used project is mostly repair work, not headline features.

Why does the ratio of bug fixes to new features matter when vetting a project?

Because feature announcements are written for attention and bug fixes are written for users. Anyone can publish a feature list on launch day. Only a project with real users accumulates a stream of specific, reproducible fixes, because each fix traces back to someone hitting that exact problem and reporting it. When 50 of 89 May change items are fixes and only 6 are features, that is not a slow month, it is the signature of software that is in daily use and getting maintained. A project whose changelog is all features and no fixes has either no users or no honesty.

Does a high GitHub star count mean an AI project is worth using?

Not on its own. A star is a bookmark. It records that someone found the repository interesting enough to save, often during a coordinated launch, and it never decays even if the project is abandoned the next week. Stars measure attention earned on one day. They do not measure whether the project still builds, still works, or still has a maintainer. Hugging Face's own Spring 2026 State of Open Source report found the catalog is heavily concentrated, with the top 200 most downloaded models accounting for roughly half of all downloads and about half of all models having fewer than 200 total downloads. Most things described as a new AI project are real uploads that were never adopted. Cadence and bug-fix density tell you what stars cannot.

Where should I look for new AI projects day to day instead of a monthly roundup?

Three feeds cover most of it. huggingface.co/models sorted by trending shows model weights and quantized variants as they gain traction. huggingface.co/papers/trending shows research with linked implementations, which is where genuinely new techniques surface before they have a polished repository. github.com/trending shows the code. Check each candidate's Releases page or CHANGELOG before you invest any time. For the deeper split between what each platform actually publishes, see the companion guide on Hugging Face or GitHub for new AI projects in April 2026.