Log flooded with repeated 'Provider model discovery failed with HTTP 404' for anthropic-adapter providers without /v1/models (Azure AI Foundry)

[DiNaSoR]

Summary

When a custom provider uses adapter: "anthropic" with a base URL that does not implement the Anthropic model-listing endpoint (e.g. Azure AI Foundry's Anthropic-compatible endpoint), the proxy log is flooded with this warning on every catalog poll:

[opencodex] Provider model discovery for "azure-foundry-anthropic" failed with HTTP 404 [urlClass=provider-models, fallback=configured].

The warning repeats dozens of times per session (the dashboard/Codex polls the catalog frequently, and each poll after the discovery cache/cooldown expires re-probes and re-logs), drowning out useful log output.

Environment

• opencodex @bitkyc08/opencodex 0.144.5 (Windows 11, Node via scoop/nvm)
• Provider config:

"azure-foundry-anthropic": {
  "adapter": "anthropic",
  "baseUrl": "https://<resource>.services.ai.azure.com/anthropic",
  "models": ["claude-haiku-4-5", "claude-opus-4-8[1m]", "claude-sonnet-5[1m]", "claude-fable-5[1m]"],
  // ...
}

Root cause

buildModelsRequest() (src/oauth/index.ts) probes GET {baseUrl}/v1/models?limit=1000 for every adapter: "anthropic" provider.

Azure AI Foundry's Anthropic endpoint only implements the inference route, not the models-list route. Verified directly against the endpoint:

• GET /anthropic/v1/models → 404
• POST /anthropic/v1/messages → 200

So discovery can never succeed for this provider class; the 404 → fallback=configured path in src/codex/catalog/provider-fetch.ts works correctly (the configured static models list is served and inference is unaffected), but the warning is re-emitted forever.

Workaround

Setting "liveModels": false on the provider skips discovery entirely and silences the log. This works, but users have to discover the flag after the fact.

Suggested fixes (any of these would help)

1. Log once per provider per process (or once per cooldown window) instead of on every failed probe — e.g. demote repeats to debug level after the first warning.
2. Remember a "discovery unsupported" verdict: after N consecutive 404s on urlClass=provider-models, treat the provider as liveModels: false for the rest of the session (keep the configured/static list) and log a single informative line suggesting the config flag.
3. Optionally, have the Azure Foundry preset/docs set liveModels: false by default, since the endpoint is known not to implement /v1/models.

Happy to provide more logs if useful. Thanks for the project!

[Ingwannu]

Confirmed on current dev: configured-model fallback and inference remain functional, but a provider that does not implement /v1/models is reprobed after each failure cooldown and emits the same HTTP 404 warning again.

I am going to keep the first warning and the existing discovery-failure status visible, suppress only repeated identical 404 warnings for the same provider models URL during the process lifetime, and reset that suppression after a successful discovery or explicit cache reset. I’ll add a focused regression test and document liveModels: false as the explicit static-catalog option. The existing workaround is safe in the meantime.

[lidge-jun]

Root cause: an anthropic adapter always probes GET {baseUrl}/v1/models (src/oauth/index.ts). Azure AI Foundry's Anthropic-compatible endpoint doesn't implement that route, so it returns HTTP 404 permanently. There IS a backoff — a 30s discovery cooldown (MODELS_FETCH_FAILURE_COOLDOWN_MS) — but it only suppresses re-fetches, not the log line: after each 30s window the next poll re-probes and re-console.warns the identical 404, so you see one warning roughly every 30s per provider. The configured-model fallback itself is correct, so inference is unaffected — it's pure log noise.

Fix (in PR #416): shouldLogDiscoveryFailure() logs a discovery failure only when its signature (reason + HTTP status) changes vs the last observed status. So the first 404 logs once, repeated identical 404s are suppressed, and a changed status / a recovery / a provider-config change (cache clear) logs again. The 30s re-probe cooldown is unchanged, and the failure stays visible via /api/providers discovery status. Regression tests added (tests/provider-discovery-log-suppression.test.ts).

This gates all five discovery failure warnings (blocked / http / invalid JSON / malformed / network) the same way. Will close once #416 lands.

[lidge-jun]

Fixed in PR #416 (dev 6a0f5b5): provider discovery failures now log once per signature (shouldLogDiscoveryFailure), so a permanent 404 from an anthropic-adapter baseUrl without /v1/models no longer re-logs every ~30s. The 30s re-probe cooldown and the observable discovery status are unchanged.