{"version":"2.1.268","anchor":"new-session-scoped-model-denyreprobe-tracking-state","canonical_anchor":"model-access-deny-caching-reworked-into-a-reprobe-system-w","heading":"Model access denial caching reworked with a 'reprobe' system","tier":"internal","area":"Model Access","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268\/e\/new-session-scoped-model-denyreprobe-tracking-state","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268","markdown":"### Model access denial caching reworked with a 'reprobe' system\n\nClaude Code can now automatically recheck and overturn a cached 'model access denied' result during a session\n\n**Unclear.** The finding does not say what user-visible behavior this bookkeeping change produces.\n\n**What**\n\nWhen 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`).\n\nThe new state tracks:\n\n- Which models have been confirmed accessible (`honoredModels`)\n\n- Denials that are contested and being rechecked (`contestedDenies`)\n\n- Models that were genuinely refused (`refusedModels`)\n\n- A generation counter and a restricted flag\n\nThe 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.\n\n**Why**\n\nPreviously, 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.\n\n- Area: Model Access\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5"}