JUNE 12-13 2026 / DATE-HONEST LIST / THE CATALOG RESHAPE

A model can ship without moving. Sometimes the news is that a vendor relabeled it, and your picker quietly lost it.

Every roundup of these two days hands you model names and a column of context-window specs. None of them cover the thing that decides whether you can actually pick the model in your own tool: vendors reshape their catalogs as often as they ship weights. This page gives the date-honest answer first, then a concrete case from June 2026 where a catalog reshape made Opus disappear from a picker, and the thirty-line fix that put it back.

Matthew Diakonov, Written with AI

Published June 17, 20268 min read

Direct answer, verified 2026-06-17

No major model carries a precise June 12 or June 13, 2026 release date. The nearest dated drops bracket the window rather than landing on it, per llm-stats.com/ai-news:

Claude Fable 5 (Anthropic) on June 9.
DiffusionGemma 26B-A4B (Google) on June 10.
OpenAI's deployment-simulation method (replaying past conversations through a candidate model before release) on June 16.

Because no platform publishes a list keyed to a calendar day, the only date-honest sources for any 48-hour window are huggingface.co/models sorted by trending, huggingface.co/papers, and github.com/trending.

That is the literal answer. The rest of this page is the part the spec tables skip: a release is not always a new set of weights. Sometimes it is a vendor reshuffling how an existing model is advertised, and that reshuffle can quietly break the option you click.

A release is not always new weights

When you track this topic by calendar day you start to notice that a large share of the churn is not new architectures at all. It is renames, re-tiering, deprecations, and changes to the catalog that an API or agent SDK advertises. Those moves never make a roundup, because a roundup is built around model names and benchmark numbers. But they are exactly the changes that reach into your client and rearrange what you can select.

In June 2026 Anthropic did one of these reshapes. It folded Opus into a pseudo-model the catalog calls default, carrying a 1M-context label, and removed the standalone Opus entry from the catalog the agent SDK exposes. Opus did not go anywhere. It just stopped having its own line in the list a wrapper reads to build its picker.

What a naive wrapper does with that

The historical reason a wrapper would drop default is sound: it used to be a pure 1M-context entry that, if selected, would silently route you through a credit gate you did not ask for. So the old transform filtered it out. The moment Opus arrived only inside default, that same filter started throwing the one option users actually wanted into the bin.

model picker, before and after the catalog reshape

Nothing errors. The list just comes back one option short. A user who wants Opus opens the picker, does not find it, and concludes the wrapper does not support it, when in fact the wrapper is one filter line away from showing it correctly.

The fix that landed June 15: rescue, do not drop

Commit ac94f9ed rewrote the transform inside emitModelsIfChanged. Instead of blanket-dropping default, it checks whether that entry carries Opus, and if it does, remaps it to the canonical latest Opus id. The detail that makes this durable is that it matches on the word opus, not on a version string, because the advertised version text is stale.

acp-bridge/src/index.ts (commit ac94f9ed)

const LATEST_OPUS_MODEL_ID = "claude-opus-4-8";

const stripped = m.modelId.replace(/\s*\[1m\]/gi, "");
const haystack =
  `${m.modelId} ${m.name} ${m.description ?? ""}`.toLowerCase();
const isOpus = stripped.includes("opus") || haystack.includes("opus");

// Anthropic folded Opus INTO `default` (with a 1M-context label) and
// REMOVED the standalone opus entry, so blanket-dropping `default`
// silently strips Opus ("Smart") from the picker. Remap an Opus-bearing
// `default` to the canonical opus id instead. Sent explicitly via
// session/set_model this avoids the 1M credit gate, and the advertised
// version text ("Opus 4.7") is stale - the served model is 4-8 - so we
// match on the WORD "opus", not a version. A non-Opus `default` is dropped.
if (stripped === "default") {
  if (!isOpus) return null;
  return { modelId: LATEST_OPUS_MODEL_ID, name: "Opus", description: m.description };
}

The same commit keeps the legacy path alive for the case where the catalog still exposes a standalone claude-opus-4-7: it bumps that id to claude-opus-4-8 so selecting Smart does not write a version-older id back into your settings and silently downgrade you. Two shapes of the same problem, one transform.

model picker, after the fix

What a catalog-to-picker transform has to survive

Once you accept that vendors reshape catalogs, the picker logic stops being a one-line filter and becomes a small contract. Here is what the June 15 transform now holds to.

The transform contract

A model advertised under a stale version label still maps to the latest canonical id.
A capability folded into the `default` pseudo-model is rescued, not dropped.
Duplicate ids (the same model arriving with and without a [1m] suffix) are deduped.
A genuinely unwanted `default` entry is still dropped when it carries no real capability.
Selection is sent explicitly so it does not trip the 1M-context credit gate.

Why this belongs next to a release list

If you only read roundups, the story of mid-June 2026 is a handful of open-weight drops and a couple of frontier updates. If you run an agent loop every day, the story includes a quieter event: a vendor changed how it advertises a model you already pay for, and for a few days some clients stopped offering it. That second story is the one that actually affects your work, and it is invisible to a spec table.

The lesson generalizes past Opus and past Anthropic. Any tool that builds its model picker from a vendor catalog inherits that vendor's renames and re-tiering. The safe posture is to treat the catalog as something to be reconciled, not mirrored: match on capability words, rescue folded entries, dedupe across suffixes, and send selections explicitly. A roundup tells you what shipped. Whether you can click it is decided thirty lines deep in your own client.

Verify every claim here

For the release dates: open llm-stats.com/ai-news and check that Claude Fable 5 is dated June 9, DiffusionGemma 26B-A4B June 10, and OpenAI's deployment-simulation method June 16, with nothing major pinned to June 12 or 13.
For the live landscape: open huggingface.co/papers and github.com/trending. The trending order shifts hour to hour, but the submission and commit dates are stable.
For the Fazm change: open github.com/mediar-ai/fazm, read acp-bridge/src/index.ts for the emitModelsIfChanged transform and the LATEST_OPUS_MODEL_ID constant set to claude-opus-4-8, then check the git log for commit ac94f9ed, authored June 15, 2026.

Want a model picker that survives a vendor catalog reshape?

Fifteen minutes. I will walk through how Fazm reconciles the agent SDK catalog into the picker, so a relabeled or folded model still shows up and routes to the latest id.

Frequently asked questions

What AI model released on June 12 or June 13, 2026?

Nothing major is dated precisely to either day. The public release trackers show the nearest dated drops bracketing the window rather than landing on it: Claude Fable 5 from Anthropic on June 9, DiffusionGemma 26B-A4B from Google on June 10, and OpenAI's deployment-simulation method (replaying past conversations through a candidate model before release) on June 16. A calendar-day query rarely returns a clean answer because neither Hugging Face nor GitHub publishes a list keyed to a date. Both order discovery by a rolling trending score with no notion of when something shipped, so the date-honest feeds for any 48-hour window are huggingface.co/models sorted by trending, huggingface.co/papers, and github.com/trending.

Was the first half of June 2026 actually quiet for open weights?

No. MiniMax M3 landed June 1 as an open-weight coding model with a one-million-token context window, topping the open-weight SWE-Bench Pro slice at 59.0 percent. GLM-5.1 from Z.ai also posted June 1, NVIDIA shipped Nemotron 3 Ultra 550B-A55B on June 4, and Google posted DiffusionGemma 26B-A4B on June 10. The calendar simply does not pin a flagship to June 12 or 13 specifically. A vendor's own benchmark numbers are self-reported until an independent harness re-runs them, so treat any fresh drop as a thing to test, not a leaderboard fact.

Why would a brand-new model disappear from my tool's model picker?

Because vendors do not only ship models, they reshape the catalog that advertises them. In June 2026 Anthropic folded Opus into the `default` pseudo-model (which carries a 1M-context label) and removed the standalone Opus entry from the catalog the agent SDK exposes. Any wrapper that had been blanket-dropping the `default` entry (a reasonable thing to do when `default` used to be a pure 1M-context credit trap) suddenly strips Opus from its picker, because Opus now only arrives inside `default`. The model is still served; it just no longer has a visible option to select.

What exactly did Fazm change on June 15, 2026?

Commit ac94f9ed in acp-bridge/src/index.ts rewrote the model-list transform inside the emitModelsIfChanged function. Instead of unconditionally filtering out the `default` entry, it now inspects the entry's id, name, and description for the word opus. If `default` carries Opus, it is remapped to the canonical id LATEST_OPUS_MODEL_ID, which is claude-opus-4-8 (defined one line above, at acp-bridge/src/index.ts:3069), and relabeled simply Opus. A non-Opus `default` is still dropped. The selection is sent explicitly through session/set_model, which sidesteps the 1M-context credit gate that the raw `default` entry would have triggered.

Why match on the word opus instead of a version number like opus-4-7?

Because the advertised version text is stale. The adapter's static catalog still describes the entry as Opus 4.7, but the model the API actually serves is claude-opus-4-8. If the code matched on the literal string claude-opus-4-7 it would miss an entry advertised under any other version label, and it would have to be edited on every Opus bump. Matching on the substring opus keeps the picker correct across version churn: a relabeled or renumbered Opus still maps to the latest canonical id without anyone touching the code.

Was selecting Opus actually broken before, or just hidden?

Both failure modes existed. When the catalog still exposed a standalone claude-opus-4-7 entry, selecting Smart wrote opus-4-7 back into selectedModel and silently downgraded you a version below what was being served. Once Anthropic folded Opus into `default` and removed the standalone entry, the older blanket-drop logic made Opus vanish from the picker entirely. The June 15 fix handles both: it bumps a stale standalone opus id to the latest, and it rescues an Opus-bearing `default` so Smart maps to claude-opus-4-8.

How do I verify the Fazm change myself?

Open github.com/mediar-ai/fazm and read acp-bridge/src/index.ts. Find the emitModelsIfChanged function and the constant LATEST_OPUS_MODEL_ID set to claude-opus-4-8. The git log shows commit ac94f9ed, 'Fix missing Opus option by mapping default model to latest Opus ID,' authored June 15, 2026, alongside related model-routing commits from the same day. Everything is public, so none of this rests on faith.

Why does a model picker detail belong next to a release list?

Because a roundup that stops at model names answers half the question. The other half is whether you can actually select and run the new model in the loop you already use. When a vendor reshapes how it advertises a model, the news that matters is not only what shipped but whether your client still surfaces it correctly. That churn is invisible in a spec table and only shows up as a missing or downgraded option in your own picker.

Adjacent reading