Repository navigation
Log flooded with repeated 'Provider model discovery failed with HTTP 404' for anthropic-adapter providers without /v1/models (Azure AI Foundry) #395
Description
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/opencodex0.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→ 404POST /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)
- 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.
- Remember a "discovery unsupported" verdict: after N consecutive 404s on
urlClass=provider-models, treat the provider asliveModels: falsefor the rest of the session (keep the configured/static list) and log a single informative line suggesting the config flag. - Optionally, have the Azure Foundry preset/docs set
liveModels: falseby default, since the endpoint is known not to implement/v1/models.
Happy to provide more logs if useful. Thanks for the project!
Activity
Ingwannu commentedon Jul 24, 2026
Confirmed on current
dev: configured-model fallback and inference remain functional, but a provider that does not implement/v1/modelsis 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: falseas the explicit static-catalog option. The existing workaround is safe in the meantime.fix(catalog): log provider discovery failures once per signature (#395)
lidge-jun commentedon Jul 24, 2026
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/providersdiscovery 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.
fix(web-search): bound sidecar search deadline to 60s + graceful degr…
lidge-jun commentedon Jul 24, 2026
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.
fix(web-search): bound sidecar search deadline to 60s + graceful degr…