Coalesce LMS model-discovery probes during orchestrator startup

Context

The prior fix in #13995 / #13996 moved bounded Neo diagnostic health churn out of user-facing logs, but the operator restarted the orchestrator on 2026-06-25 and LMS developer logs are still flooded. This is a distinct failure mode: LMS is receiving repeated model-discovery requests, so Neo-side log filtering alone cannot fix it.

Observed LMS developer-log burst after restart:

2026-06-25 12:02:22 [DEBUG] Received request: GET to /v1/models
2026-06-25 12:02:22 [INFO] Returning { data: [...] }
2026-06-25 12:02:22 [DEBUG] Received request: GET to /v1/models
2026-06-25 12:02:22 [INFO] Returning { data: [...] }
2026-06-25 12:02:22 [DEBUG] Received request: GET to /v1/models
2026-06-25 12:02:22 [INFO] Returning { data: [...] }
2026-06-25 12:02:22 [DEBUG] [LMSAuthenticator][Client=lms-cli] Client created.
2026-06-25 12:02:22 [INFO] [LMSAuthenticator][Client=lms-cli][Endpoint=listLoaded] Listing loaded models
2026-06-25 12:02:22 [INFO] [LMSAuthenticator][Client=lms-cli][Endpoint=listLoaded] Listing loaded models
2026-06-25 12:02:22 [INFO] [LMSAuthenticator][Client=lms-cli][Endpoint=getModelInfo] Getting descriptor for specifier: {...}
2026-06-25 12:02:22 [INFO] [LMSAuthenticator][Client=lms-cli][Endpoint=getLoadConfig] Getting load config stack for specifier: {...}
2026-06-25 12:02:22 [DEBUG] [LMSAuthenticator][Client=lms-cli][Endpoint=getInstanceProcessingState] Getting instance processing state for specifier: {...}

Ticket creation V-B-A:

• Live latest-open sweep before creation: #13994, #13983, #13936, and older design-gated backlog; no open LMS developer-log flood ticket.
• Direct open-issue search for LMSAuthenticator, /v1/models, listLoaded, and model-discovery probe flood returned no duplicates.
• Repository sweep found likely request sources in ai/services/memory-core/lifecycle/InferenceLifecycleService.mjs, ai/services/graph/providerReadinessHelper.mjs, and ai/daemons/orchestrator/services/DreamService.mjs.
• KB sweep did not know a current LMSAuthenticator ticket; related history exists around /v1/models readiness/request storms, especially archived #12262 and current #13950, but neither covers this exact regression.

Problem

Normal orchestrator startup or readiness diagnostics can issue several independent model-discovery probes into LMS at nearly the same time. LMS logs every request and CLI metadata call into the user-facing developer console, burying meaningful model activity and responses.

This invalidates the previous fix scope. The observable spam is not just Neo logger verbosity; it is LMS-facing request volume.

Architectural Reality

Known local call surfaces that need auditing:

• ai/services/memory-core/lifecycle/InferenceLifecycleService.mjs calls the OpenAI-compatible /v1/models endpoint for inference liveness.
• ai/services/graph/providerReadinessHelper.mjs performs /v1/models readiness probes, including initial and post-load model checks.
• ai/daemons/orchestrator/services/DreamService.mjs waits for the local LLM provider by polling /v1/models.
• LMS CLI metadata paths can add listLoaded, getModelInfo, getLoadConfig, and getInstanceProcessingState calls on top of HTTP model-list probes.

Protected consumers:

• Cloud diagnostics and recovery daemons must keep their recovery semantics intact. These daemons can theoretically run locally too, so the fix must classify consumers by purpose instead of assuming local equals low-stakes.
• Coalescing and TTL caching are allowed only for routine discovery/readiness paths where stale-enough model inventory is acceptable for a short freshness window.
• Recovery probes, force-refresh diagnostics, outage confirmation, and daemon actions that intentionally need current state must either bypass the cache or request a separately documented freshness policy.
• A cache hit must never suppress failure escalation, recovery decisioning, or daemon evidence capture.

If new cadence or TTL configuration is needed, it must stay under AiConfig as the reactive provider SSOT per ADR 0019. No hidden env reads, hardcoded defaults, or method-pass-through config plumbing.

Required Fix

Collapse routine model-discovery and model-metadata requests behind a shared provider-discovery service or equivalent existing surface:

• coalesce concurrent routine probes through a single in-flight promise;
• add a short TTL cache for ordinary startup, health, and readiness consumers;
• expose an explicit force-refresh path for operator diagnostics and real error investigation;
• batch or dedupe LMS CLI metadata requests where the same model instance is inspected repeatedly;
• preserve cloud diagnostics and recovery daemon behavior, including local runs of those daemons;
• keep durable bounded Neo-side diagnostic logs without making LMS developer logs unusable.

A new MCP tool is not warranted for this bug.

Acceptance Criteria

• Every routine Neo path that calls LMS /v1/models or LMS CLI metadata endpoints during orchestrator restart, health, or readiness is identified in the PR body.
• Every cloud diagnostic and recovery daemon path that calls the same provider-discovery surfaces is identified separately, with its required freshness semantics stated.
• Routine startup, health, and readiness consumers share one in-flight model-discovery probe per provider freshness window.
• Protected diagnostic/recovery consumers either bypass the routine cache or use an explicit freshness contract that cannot hide actionable failures.
• Cache hits do not issue LMS-facing /v1/models, listLoaded, getModelInfo, getLoadConfig, or getInstanceProcessingState calls for routine consumers.
• Force-refresh diagnostics still bypass the cache and write durable bounded diagnostic detail.
• A normal orchestrator restart no longer produces a repeated /v1/models plus duplicated LMSAuthenticator burst in the LMS developer console.
• Tests cover cache hit, cache miss, in-flight join, force-refresh, protected-consumer bypass/freshness behavior, and failed probe behavior not being cached as healthy.
• If cadence or TTL config is added, it is represented in AiConfig and documented in ai/config.template.mjs; no hidden env reads or defensive local defaults.
• No new public MCP tool and no extra lms-cli dependency in hot health loops.

Out of Scope

• Reopening #13995 or #13996.
• Changing LM Studio/LMS server logging behavior.
• Hiding real provider failures from diagnostics or recovery daemons.
• Solving unrelated REM token-accounting anomalies from #13994.

Avoided Traps

• Do not fix this by moving only Neo logs to file-only output; the evidence is LMS-facing request spam.
• Do not let each subsystem independently poll /v1/models during startup.
• Do not apply routine TTL caching blindly to cloud diagnostics or recovery daemons.
• Do not cache failed readiness as success.
• Do not add a bug-specific MCP tool.

Related

• Follow-up to insufficient #13995 / #13996 outcome.
• Related historical precedent: #12262 reduced a prior per-poll probe/log storm.
• Nearby model-list readiness concern: #13950.

Origin

• Origin session: 1583113d-4deb-455a-bee4-16521e9d1479
• Retrieval hint: LMSAuthenticator /v1/models listLoaded getModelInfo getLoadConfig developer logs probe coalescing diagnostics recovery daemon