Hugging Face or GitHub for new AI projects on May 12, 2026: what actually shipped, and the small repo most people missed

On May 12, 2026 the AI news cycle was dominated by model weights on Hugging Face and another wave of agent framework commits on GitHub. The most useful artifact of the day for anyone running an AI agent on a Mac was two consecutive Fazm releases (v2.9.8 and v2.9.9) that fixed concrete session-recovery and pop-out routing bugs. Verifiable in CHANGELOG.json on the public repo.

Matthew Diakonov, Written with AI

Published May 14, 20269 min read

Direct answer (verified 2026-05-14)

On May 12, 2026, two consumer-relevant artifacts shipped from the public repo at github.com/mediar-ai/fazm: Fazm v2.9.8 and v2.9.9. Both are pop-out-chat reliability fixes for an agent harness that wraps Claude Code on macOS. The two entries are verifiable in CHANGELOG.json under the literal string 2026-05-12.

The Hugging Face side of the day was dominated by fine-tunes and incremental updates rather than a single must-pull weight; for a Mac agent loop the more useful artifact of the day was on the harness layer.

Why a harness patch is the headline, not the model drop

Every page that currently shows up for this kind of date-pinned question enumerates models. Granite, Qwen, Mistral, the usual orgs. That is not wrong, but it is incomplete in a specific way. New weights on Hugging Face are upstream. They do not do anything until somebody wires them into a real harness that talks to the operating system. The harness is what produces the user-visible behavior that anyone running an AI agent on a Mac is actually trying to debug.

On May 12, the harness that had a notable day in public was Fazm. Two releases in 24 hours, both narrowly scoped, both on the part of the stack that the model release notes never touch. If you typed the date into a search box because you wanted to know what actually changed in the AI ecosystem that day for someone running a coding or computer-use agent on a Mac, this is the more honest answer than another model roundup.

The two May 12 entries, exactly as the public file shows them

Both entries below come from the live CHANGELOG.json on the main branch of the open-source repo. The same JSON is signed into git at the moment the macOS app is signed and notarized, so the artifact a user downloads and the entry the website shows are the same file. You can fetch the raw JSON yourself with the command in the terminal block.

Verifying both 2026-05-12 entries

The placeholder-text leak (2.9.8)

When a long-running pop-out chat hits a Claude usage limit, the harness has to spawn a fresh subprocess and replay enough conversation context for the model to pick up where it left off. The replay used a preamble that contained literal placeholder text of the form (your response here). The model, doing what models do, occasionally completed the preamble verbatim, so the user saw the literal string streamed into the chat as if it were a real reply.

The 2.9.8 fix had two halves. First, the recovery preamble no longer contains placeholder text in any of the locations where the model might pick it up and complete it. Second, a streaming filter was added downstream so that if the same family of placeholder strings leaks from a future model version, the surface layer catches it before it reaches the user. The second half is the more interesting one. It is the moment when a harness team decides that the model can never be fully trusted to honor a meta-instruction, and that the fix has to live at the message-stream boundary instead of inside the prompt.

The same release also fixed a tool-call UI routing bug in multi-session setups (tool call output occasionally rendering in the wrong chat window when two windows were both mid-tool-call), and an input behavior where messages typed while a session was still responding had been silently queued until the session freed up. Now those messages appear in the conversation immediately.

The cross-window state bugs (2.9.9)

The second release of the day was smaller and also pop-out-specific. Two changes. One, follow-up choice buttons (the suggested-next-turn chips under a model response) were disappearing from one pop-out chat when a different pop-out submitted a query, because the chips were keyed on a shared state slot that the second pop-out was reusing. Two, the thinking indicator in pop-out windows and in the floating bar was going blank between tool calls inside a single query, so a long tool-heavy turn looked like the agent had stalled even though it had not.

Both are pure harness bugs. Neither has anything to do with the model. They are what happens when multiple long-lived chat surfaces share a single agent subprocess and the shared-state plumbing has not been audited for the case where two surfaces are actively producing output at the same time. The class of bug is generic to any product in this space and not interesting in isolation; what is interesting is the cadence. The bugs were not pretty, the fixes were not flashy, and they shipped the day they were found.

The week the patches lived in

May 12 was not an isolated day. The patches sit in a string of pop-out and session-recovery fixes that span the week. If you want the wider context, here is the order, all of it from the same CHANGELOG.json.

May 11: 2.9.5 and 2.9.6

Two prior pop-out fixes the day before, both about session bleed across windows. 2.9.5 invalidated every active session on credit exhaustion and replayed prior context; 2.9.6 stopped one chat completing a turn from wiping the 120-second tool watchdog on the other open pop-outs.

May 12: 2.9.8 ships

Recovery preamble rewritten so the model cannot complete placeholder text verbatim. Streaming filter added as a second layer. Tool call UI routing in multi-session setups fixed. Messages typed during a streaming turn appear immediately instead of being silently queued.

May 12: 2.9.9 ships

Follow-up choice buttons no longer disappear from a pop-out when another pop-out submits. Thinking indicator stays visible in pop-out and floating bar between tool calls during a single query. Both pop-out bugs were specifically the class that only manifests when multiple chat surfaces are alive simultaneously.

May 13: 2.9.10 and 2.9.12

Pop-out chats getting permanently stuck after another pop-out hit a Claude usage limit (fixed by a clean ACP subprocess restart that resumes from the same session ID once your limit refreshes). Sign-in OAuth tab can now be cancelled with a Cancel button; stale subscription state after sign-out is cleared.

What was actually on Hugging Face that day

Honest version: the Hugging Face side of May 12 was a busy-but-not-headlining day. Fine-tunes under the usual orgs, incremental updates to existing families, several merges of community LoRA adapters, none of which by itself meaningfully changed what runs locally on a 16 or 32 GB M-series Mac. The pages that name a specific must-pull model from that exact date tend to overstate. If you arrived here looking for the one weight to download from May 12, the defensible answer is to save the bandwidth and watch the harness side.

The frontier for tool-calling reliability on M-series silicon at that moment was still the Qwen 3 family for the local case and the hosted Anthropic Claude line for everything else. Both have been the answer for weeks, and a single day of fine-tunes did not move that line.

If you want to plug a new Hugging Face model into a Mac agent

Fazm wraps Claude Code (and optionally Codex) over the agent client protocol, so by default it talks to whatever endpoint the underlying agent CLI is configured to talk to. For most users on May 12 that was the hosted Anthropic API. If you want a Hugging Face model in the loop instead, the integration path looks like this:

Run a local inference server that loads the GGUF or MLX weights. llama.cpp, mlx-lm, Ollama, or vLLM are the common picks.
Put an Anthropic-compatible translation layer in front of it. claude-code-router and LiteLLM both work; both translate the Anthropic Messages API shape (with tool_use blocks) into whatever the local server speaks.
In Fazm, open Settings and put the proxy URL into the customApiEndpoint field. That is the seam. Everything else in the harness, including the May 12 fixes, applies unchanged.

The point: new weights on Hugging Face show up in Fazm by changing one URL in Settings. The harness fixes that shipped May 12 are model-agnostic. They make the chat surface less brittle no matter which model is on the other end.

The takeaway

If you remember one thing from this date, make it this: a product that ships two patches in a single day for pop-out routing and session-recovery bugs is in a different operational regime than a product that ships once a month with a press cycle attached. The cadence is the signal. Model drops are easy to count. Harness fixes are harder to count, and they are where the day-over-day usefulness of a Mac agent actually lives.

The 2.9.8 placeholder-leak fix is also a small, generic lesson worth taking forward. If you build any kind of agent harness that does session recovery with a preamble the model sees, audit that preamble for any literal string the model might complete as if it were a template. Then add a streaming filter as a second layer, because the model will eventually surprise you anyway.

Want to see the May 12 fixes running on your Mac

Fifteen minutes, we screenshare the pop-out harness, the session-recovery preamble, and how to point Fazm at a Hugging Face model through a local proxy.

Frequently asked questions

What actually landed on Hugging Face and GitHub on May 12, 2026?

A mixed day. The headline traffic on Hugging Face came from updates to existing model families and a steady drip of fine-tunes under the usual orgs (ibm-granite, Qwen, mistralai, microsoft) rather than a single dominant launch. On GitHub the most heat was on agent-framework repos: a continued patch cadence on agentscope-ai/QwenPaw following the v1.1.x line, ongoing churn on the agent client protocol implementations under zed-industries and anthropic-experimental, and a quieter but more useful pair of releases on the consumer side: Fazm v2.9.8 and v2.9.9 (both shipped May 12) at github.com/mediar-ai/fazm. Two patches in a single day on a publicly downloadable Mac agent, both fixing concrete pop-out and session-recovery bugs that no model release note covers.

Why does a desktop AI agent's patch cadence belong in a Hugging Face or GitHub roundup?

Because weights are upstream and useless until somebody wires them into a real harness that talks to the OS. The pages that currently rank for this date enumerate models. The thing a Mac user actually feels on May 12 is not Granite or Qwen, it is whether the agent loop running on top of those weights drops messages, replies to the wrong window, or echoes the literal placeholder text from a session-recovery preamble. The Fazm 2.9.8 entry in CHANGELOG.json on May 12 is the only document on the public internet that describes how a real consumer agent reacted, in plain English, to one of the failure modes that comes from running an LLM-driven harness across multiple long-lived chat windows. That is the operational tax that downstream of every model drop, and it is what the harness layer is actually shipping fixes for, day by day.

How do I verify the May 12 Fazm releases myself?

Open https://github.com/mediar-ai/fazm/blob/main/CHANGELOG.json in a browser. The file is a JSON object with two keys, unreleased and releases. The releases array is sorted newest first. Search for the literal string "2026-05-12" and you will find two entries in a row: 2.9.9 and 2.9.8. Each entry has a changes array listing the specific fix. The same JSON is read by the in-app updater, signed into git at the same moment the macOS app is signed and notarized, and embedded into the release page rendered at fazm.ai/changelog, so the artifact a user downloads and the entry the website shows are the same file.

What is the actual bug 2.9.8 fixed and why is it interesting?

It is one of the more instructive failure modes in this product class. When a long-running pop-out chat hits a Claude usage limit or any other forced restart, the agent harness has to spawn a fresh subprocess and replay enough conversation context for the model to pick up where it left off. The replay used a preamble that included literal placeholder text of the form '(your response here)'. The model, doing what models do, sometimes completed the preamble verbatim, so the user saw the literal string '(your response here)' streamed into the chat as if it were a real reply. Fazm 2.9.8 fixed both halves: the recovery preamble no longer contains placeholder text, and the streaming filter now catches the same family of leaks if they ever come back from a different model. It is the kind of failure mode that only shows up in a real consumer product running for hours.

And 2.9.9?

Two pop-out interaction bugs. First, follow-up choice buttons (the suggested-next-turn chips that appear under a model response) were disappearing from one pop-out chat when a different pop-out submitted a query. Second, the thinking indicator in pop-out windows and in the floating bar was going blank between tool calls during a query, so a long tool-heavy turn looked like the agent had stalled when it had not. Neither is a model fix. Both come from the harness layer juggling shared state across multiple independent chat surfaces that all happen to be backed by the same agent subprocess. That is the actual day-to-day work of running Claude Code (or Codex) on a real machine instead of in a clean benchmark environment.

Where does Hugging Face fit into Fazm's actual runtime?

Fazm wraps Claude Code (and optionally Codex) via the agent client protocol, so by default it talks to whatever endpoint the agent CLI is configured to talk to. Most users on May 12 were pointed at the hosted Anthropic API. For users who want a Hugging Face model in the loop, the path is to run a local inference server (llama.cpp, MLX, Ollama, vLLM) plus an Anthropic-compatible translation layer (LiteLLM, claude-code-router) and point Fazm's customApiEndpoint setting at the proxy. That is the seam. New weights on Hugging Face show up in Fazm by changing one URL in Settings; the harness fixes that shipped May 12 are independent of which model is on the other end.

Was there a model on Hugging Face on May 12 worth pulling for an agent loop on a Mac?

Honest answer: most of what dropped that specific day was either fine-tunes of existing families or incremental updates rather than a model that meaningfully changed what runs locally on a 16 or 32 GB Mac. The frontier for tool-calling reliability on M-series silicon at that moment was still the Qwen 3 family for the local case and the hosted Anthropic Claude line for everything else. If you arrived here looking for a single must-pull weight from May 12, the most defensible answer is no, save the bandwidth and watch the harness layer. The day-over-day usefulness of a Mac agent is bottlenecked on the harness, not the model.

Why does this page exist instead of being merged into a monthly roundup?

The monthly roundup is a different shape: it enumerates everything in a period and shows trends. A page about one specific date answers a different literal question, which is what happened on this date. Both pages have a role, and they should link to each other. For the May 2026 monthly view see /t/new-open-source-ai-projects-tools-updates-april-2026 and /t/open-source-llm-releases-may-2026. For a sibling single-day page see /t/hugging-face-or-github-new-ai-projects-april-29-2026, which uses the same structure for the previous big multi-release day.

What is the most useful thing for an actual developer to take from May 12?

Two practical things. One, if you run any kind of agent harness with multiple long-lived chat windows, audit your session-recovery preamble for placeholder text the model might complete. The Fazm 2.9.8 bug is a generic class, not a Fazm-specific class. Two, if you are evaluating an agent product on macOS, look at the cadence of harness fixes alongside the marketing. A product that shipped two patches in 24 hours for real pop-out routing bugs is in a different operational regime than a product that ships once a month with a press cycle attached.

How does Fazm's reach beyond the terminal change the relevance of new Hugging Face models?

Most agent CLIs talk to a terminal and a filesystem. Fazm drives the actual browser via an extension, native Mac apps via accessibility APIs, and Google Workspace via the OAuth lanes the user has already granted. That reach is independent of which model is generating the tool calls. A new Hugging Face model that is better at structured tool output makes the agent loop tighter, but it does not change what the agent can reach. The harness reach is the differentiator; the model is a swappable engine. On any given May 12 the right question to ask of a new model is not whether it benchmarks well, it is whether it produces clean Anthropic-shaped tool_use blocks under streaming load, because that is what the harness consumes.