fix(providers): custom_openai Responses API fallback fails with 404/405 when chat completions unavailable #2205

Bug: custom_openai Responses API fallback broken

Sentry issues

Combined: 76 events across 3 issues. All on macOS (aarch64 + x86_64), release openhuman@0.53.43.

Affected models (from Sentry tags)

• reasoning-v1, deepseek-v4-flash (TAURI-HJ/HM — 404 errors)
• qwen3.6-plus (TAURI-TV — 405 errors)

What happens

1. User configures a custom_openai provider pointing at a third-party endpoint (e.g. a local or self-hosted API).
2. The app sends a chat completions request to {base_url}/chat/completions.
3. The endpoint returns 404 Not Found (endpoint doesn't exist) or 405 Method Not Allowed (endpoint rejects the method/model).
4. Because custom_openai is created with OpenAiCompatibleProvider::new() which sets supports_responses_fallback = true, the code attempts a fallback to the Responses API at a derived /responses URL.
5. The Responses API fallback also fails — most third-party/self-hosted endpoints don't implement OpenAI's /v1/responses endpoint either.
6. The user gets a cryptic double-error: "chat completions unavailable; responses fallback failed: custom_openai Responses API error: " (note the empty error body — the fallback endpoint returns nothing useful).

Root cause

File: src/openhuman/inference/provider/compatible.rs

The custom_openai provider is constructed at src/openhuman/inference/provider/ops.rs:416 using OpenAiCompatibleProvider::new(), which defaults supports_responses_fallback = true (line 104). This is wrong for arbitrary user-configured endpoints.

The Responses API (/v1/responses) is an OpenAI-specific endpoint. Most third-party OpenAI-compatible providers (Ollama, LM Studio, vLLM, text-generation-webui, etc.) do not implement it. When chat completions fails with 404, the fallback to /responses is virtually guaranteed to also fail, producing a confusing double error.

The fallback logic lives in three methods in compatible.rs:

• chat_with_system (line 1261): on 404, tries chat_via_responses
• chat_with_history (line 1382): on 404, tries chat_via_responses
• native_chat (line 1682): on 404, tries chat_via_responses

The chat_via_responses method (line 423) constructs the responses URL via responses_url() (line 347), which derives it from the base URL. When this also 404s, the error message is empty because the error body from the third-party server is empty or HTML.

For TAURI-TV specifically, the 405 is not triggering the responses fallback (only 404 does), but it shows a related problem: the custom_openai provider blindly forwards requests to endpoints that reject specific models/features, with no graceful degradation.

Proposed fix

1. Create custom_openai with supports_responses_fallback = false — change ops.rs:416 to use OpenAiCompatibleProvider::new_no_responses_fallback() instead of ::new(). Arbitrary user-configured endpoints should not attempt the Responses API fallback. Users who specifically want the Responses API can configure their base_url to end in /responses.

2. Improve the error message when chat completions returns 404 on a custom_openai provider — surface a user-actionable hint like "check that your endpoint URL is correct and the model is available" instead of attempting a doomed fallback.

3. Consider adding a config option (e.g. responses_api: true/false) in the custom provider config so advanced users who connect to actual OpenAI-compatible endpoints with Responses API support can opt in.

Environment

• OS: macOS 26.3.1 (aarch64), macOS 26.4.1 (aarch64), macOS 26.5.0 (aarch64), macOS (x86_64)
• Release: openhuman@0.53.43+2b64ea8ac567
• Rust: rustc 1.93.0 stable

Fixes OPENHUMAN-TAURI-HJ, OPENHUMAN-TAURI-HM, OPENHUMAN-TAURI-TV