{"version":"2.1.265","anchor":"tool-search-deferred-tools-delta-now-has-a-fast-latch-path-a","canonical_anchor":"tool-search-deferred-tools-delta-now-has-a-fast-latch-path-a","heading":"Tool-search deferred-tools delta now has a fast latch path avoiding full recompute","tier":"internal","area":"Tool Search","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265\/e\/tool-search-deferred-tools-delta-now-has-a-fast-latch-path-a","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265","markdown":"### Tool-search deferred-tools delta now has a fast latch path avoiding full recompute\n\nChecking for newly available tools mid-session now uses a faster cached check first\n\n**What**\n\nThe internal logic that decides whether to compute and announce a `deferred_tools_delta` (a signal that new tools have become available partway through a session) now first tries a quick cached check using `toolPoolRefreshes` and `aheadOfRequest`. It only falls back to the previous, more expensive full set of eligibility checks if that quick check doesn't resolve the question.\n\n**Why**\n\nThis is a performance change: it avoids redoing full eligibility computation on every check, which should make detecting newly available tools mid-session cheaper without changing what tools end up available.\n\n- Area: Tool Search\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 0\/5"}