You'll noticeTier: how much it should matter to you
3Useful: my rating, 1 to 5
2Signal: worth watching, 1 to 5
Model SettingsArea: what it touches
Bug FixesKind: in v2.1.267,
Bug FixesSection of the release
What
The validation logic for the availableModels setting, which restricts which models people can pick, had a bug: it was reading from and writing to internal variables that didn't match its own inputs, so it wasn't actually validating the list it was given. This has been fixed so it correctly checks the input array and only keeps valid string entries.
Why
This fixes a case where availableModels validation could behave incorrectly, for example failing to catch or properly report a non-string entry in the list. Anyone using this setting to restrict model selection should see it validated correctly now.
The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.
Added sinceA small documentation edit on Hooks reference touched a line naming availableModels after this was published.On a `completed` response, `resolvedModel` names the model the subagent started on, which can differ from the `model` value in `tool_input`, such as when `availableModels` or another override applies. On an `async_launched` response, `reso…hookssee the edit
Confirmed sinceAnthropic's documentation has since written up availableModels, on All settings.| Restriction allowlists | Takes the list whole from the highest source that sets it, without adding entries from lower sources. When the highest source doesn't set one, takes it whole from the next source down | [`availableModels`](#avail…settings-referencesee the edit
How sure we are
One source agreesOne thing we can check says the same as this entry.
Anthropic's documentation agreesAnthropic's documentation has since written up availableModels, on All settings.
