Model entitlement check now resolves through model overrides

Model aliases pointing at models you lack access to are now correctly rejected.

You'll noticeTier: how much it should matter to you

3Useful: my rating, 1 to 5

0Signal: worth watching, 1 to 5

ModelsArea: what it touches

Bug FixesKind: in v2.1.223, 05 Aug 26

Bug FixesSection of the release

What

A model name that maps onto an unentitled API model via a configured override is now correctly recognised as unentitled, instead of passing the check because the alias itself was not in the set.

Details

in addition to the direct set lookup, the predicate walks the configured model overrides from settings and from the cached client data
a match is reported when any override maps the name onto an unentitled API model

Evidence

modelOverrides

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

How sure we are

One source agreesOne thing we can check says the same as this entry.

Anthropic's release notes agreeFixed modelOverrides keys that aren't Anthropic model IDs being treated as the session's canonical model ID; unknown keys are now ignored as…

See this entry in the whole of v2.1.223 →

The build it came inv2.1.223

5 Aug 2026 · 201 entries, this one is #141.

Use it now26
You'll notice99
Nothing to try yet21
Under the hood55

Either side of it

v2.1.222Older
v2.1.224Newer

Open the release →

Names in this entry

settingmodelOverrides
Map model IDs to your provider's IDs, such as Bedrock ARNs

Anthropic's note

Upstream's own release notes for v2.1.223 name something this entry names, so the two are probably about the same change. Probably: the pairing is made on a shared name rather than on the words around it.

Fixed modelOverrides keys that aren't Anthropic model IDs being treated as the session's canonical model ID; unknown keys are now ignored as documented

Is this right?