deepseek-v4-pro raises on Responses API 404 instead of falling back to Chat Completions

[albertwang2035]

Summary

Calling deepseek/deepseek-v4-pro fails with an OpenAIError / NotFoundError, while deepseek/deepseek-v4-flash works fine. The root cause is that is_responses_api_model() incorrectly classifies any
OpenAI-compatible model whose name ends in -pro as a Responses-API-only model — preventing the Chat Completions fallback.

Root Cause

In utils/llm_providers.py, is_responses_api_model() was designed to identify native OpenAI models that require the Responses API (e.g. gpt-5.2-pro):

• Before fix
  bare = name_lower.split("/")[-1] if "/" in name_lower else name_lower
  return "codex" in bare or bare.endswith("-pro")

The function correctly guards against non-OPENAI provider types, but does not guard against third-party OpenAI-compatible providers (those with a custom base_url). DeepSeek is registered as openai_compatible:
true, so its models are routed through ProviderType.OPENAI — causing deepseek-v4-pro to match bare.endswith("-pro").

The call path that exposes the bug:

1. call_llm_provider() sees ProviderType.OPENAI → calls should_use_responses_api() → True
2. Tries POST /v1/responses against https://api.deepseek.com/v1 → 404 / not implemented
3. Exception handler calls is_responses_api_model() → True (due to -pro suffix) → re-raises instead of falling back
4. deepseek-v4-flash has the same steps 1–2, but step 3 returns False → falls back to Chat Completions → succeeds

Fix

is_responses_api_model() should only enforce Responses-API-only semantics for native OpenAI endpoints. Third-party providers with a custom base_url should be excluded:

• After fix — added before the bare-name check
  if config.base_url is not None and "api.openai.com" not in config.base_url:
  return False

This makes the guard consistent: -pro-suffixed models on custom endpoints are allowed to fall back to Chat Completions, just like any other OpenAI-compatible model.

Affected versions

Any version where deepseek-v4-pro is listed as a model and is_responses_api_model uses bare.endswith("-pro") without a base_url guard.

Files changed

• pantheon/utils/llm_providers.py — is_responses_api_model(): skip the -pro check when config.base_url is set and does not point to api.openai.com

[lianzhiweivincent-cloud]

This is a good example of why Responses API selection should be tied to endpoint capability, not only model-name suffixes.

The regression test I would add is:

• provider type: OpenAI-compatible or OpenAI client with a non-OpenAI base_url
• model: deepseek-v4-pro
• first request attempts /responses only if the provider explicitly declares Responses API support
• if /responses returns 404 for a custom endpoint, fallback to /chat/completions unless the provider is known to be OpenAI-native and Responses-only
• assert that deepseek-v4-flash and deepseek-v4-pro use the same fallback rules when their endpoint capability is the same

I wrote a short OpenAI-compatible Chinese model setup/debug checklist here: https://black-eagle-ai.vercel.app/guides/chinese-ai-openai-sdk/

Disclosure: I am involved with Black Eagle AI. The checklist is generic and should still be useful if you use DeepSeek directly.

[zqbake]

Fixed in 5f87587c (main). is_responses_api_model() is now driven by a per-provider responses_required_models declaration in the catalog, so third-party OpenAI-compatible *-pro models like deepseek-v4-pro fall back to Chat Completions on 404 as expected, while OpenAI-native *-pro/codex stay Responses-only. Regression tests are in tests/test_responses_api.py.

Feel free to clone and try it: git clone https://github.com/aristoteleo/PantheonOS.git && cd PantheonOS && uv run pytest tests/test_responses_api.py.