Releases, papers, and open source around May 28, 2026: the open-weights week nobody finishes covering

What the open side of the window actually shipped

People type a precise date into a search box because they expect a single headline launch behind it. For the back half of May 2026 there is not one closed-frontier headline. The interesting releases were open, and they are checkable. Here is the short list, each entry traceable to a public model page.

• HiDream-O1-Image (8B, MIT)

  A pixel-native image foundation model built on a Pixel-level Unified Transformer that encodes raw pixels, text, and task conditions in one shared token space, with no external VAE or separate text encoder. Open-sourced May 8, 2026, with a Dev-2604 refresh on May 14, and a debut at number 8 in the Artificial Analysis Text-to-Image Arena. Repo and weights.

• NVIDIA Nemotron 3 Nano (open weights)

  A compute-efficient open model aimed at agentic workflows, debugging, summarization, and retrieval, with both weights and training data published on Hugging Face. Nano is available now; NVIDIA lists Super and Ultra for the first half of 2026. This is open in the sense that matters for self-hosting: you can pull the weights and run them.

• The honest gap: no closed-API headline on the 28th

  If you were waiting for a closed frontier launch stamped May 28, it did not happen. That is not a dead end. It means the models worth your attention this week are ones you can actually host and steer yourself, which changes the question from when can I call the API to what do I point my agent at.

The part nobody writes down: an open model is just a download

Every guide on this stops at the same place. It tells you the model exists, links the Hugging Face page, maybe quotes a benchmark, and ends. What it never tells you is how to make that model the brain of the coding agent you already use every day. Open weights are a directory of tensors. To get work out of them through a tool like Claude Code or Codex, three things have to be true.

That second and third point are where most setups fall down. The raw CLI route is to export an environment variable and relaunch a terminal, and the moment you do that by hand you also have to remember to scrub your real key so it never reaches the open endpoint. fazm folds the whole thing into one field.

How a single setting routes the agent loop to an open model

fazm is a native macOS app that wraps Claude Code and Codex through the Agent Client Protocol. Its Settings screen has an advanced field called Custom API Endpoint, with the placeholder your-proxy:8766 (with an http or https scheme). Fill it with the address of whatever Anthropic-compatible front-end sits in front of your open-weights model, and the same agent loop, with the same persistent sessions and forking, runs on that model instead of the built-in path.

The wiring is small and you can read it in the open repo. When the endpoint is set, the bridge process is launched with three environment values: ANTHROPIC_BASE_URL set to your endpoint, FAZM_CUSTOM_API_ENDPOINT set to true, and ANTHROPIC_API_KEY set to a harmless placeholder. The bundled Anthropic key never leaves the machine.

// ACPBridge.swift, default path
// bundled credentials are used,
// calls go to the hosted endpoint
env["ANTHROPIC_API_KEY"] = bundledKey
// ANTHROPIC_BASE_URL unset -> default

That placeholder key, sk-fazm-custom-endpoint, is deliberate. Many Anthropic-compatible local gateways accept any non-empty key and use it to stay on the API-key path instead of triggering an OAuth flow. Sending a placeholder keeps a local open-weights bridge happy while guaranteeing the real bundled key is never forwarded to a proxy you control. The comment in the source says it plainly: a custom endpoint means you are routing your own model and provider, so the bundled key must not leave the machine.

What can sit behind the endpoint

The endpoint only has to speak the Anthropic API format. A raw Gemini or OpenAI key will not work directly, but any of these front-ends will, which is what makes a fresh open-weights release usable the day it lands.

None of this touches the parts of fazm you rely on. Persistent sessions, one-click forking, and a full chat history with no auto-compacting all behave the same whether the calls go to the built-in path or to your own endpoint. The endpoint decides only where the model lives. Everything around the model loop stays put.