Under the hoodTier: how much it should matter to you
2Useful: my rating, 1 to 5
3Signal: worth watching, 1 to 5
Model AccessArea: what it touches
Internal ChangesKind: in v2.1.268,
Internal ChangesSection of the release
Unclear Whether this reprobe behavior is active for any given user is unread, since the gate tengu_session_model_cached_deny_reprobe has no recorded reading.
What
When Claude Code decides a model isn't accessible and caches that denial, it now tracks this in a new per-session state object called sessionModelDenyReprobe. This replaces the older fields that used to track this (lastGoodAntOverrideConfig and antCapabilitiesByModelId).
The new state tracks:
Which models have been confirmed accessible (honoredModels)
Denials that are contested and being rechecked (contestedDenies)
Models that were genuinely refused (refusedModels)
A generation counter and a restricted flag
The logic that checks model access was rewritten to use this state: it can mark a cached denial as contested and kick off an asynchronous recheck ('reprobe') that can overturn a previously cached denial if the model turns out to be accessible after all.
Why
Previously, once a model was cached as denied, Claude Code might keep treating it as unavailable even if that access actually became valid again. The reprobe system lets a stale denial get corrected automatically instead of requiring a restart or manual retry.
How sure we are
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubtWhether this reprobe behavior is active for any given user is unread, since the gate `tengu_session_model_cached_deny_reprobe` has no…
