[Bug] Custom OpenAI-compatible provider (B.AI) — "This server listed no models" while GET /v1/models returns 47 models (mobile only; desktop works with the same credential)

[Confettihere]

Version: 1.9 (iOS, App Store)
Platform: iPad Pro 13-inch (M4, 2024), iPadOS 26.6.1

Describe the Bug

A custom OpenAI-compatible cloud provider is added successfully in the mobile app (base URL https://api.b.ai/v1 + valid Bearer API key). The provider appears in Settings and in the Cloud tab of the model picker, but the model list is empty with the message "This server listed no models." Reloading does not change it. Since the mobile app has no manual model-ID field (#277), there is no workaround.

The same base URL and the same credential work in the desktop app — the model list loads there correctly — so this appears to be a mobile-specific issue with custom-provider model discovery.

The credential also works outside Atomic Chat:

• GET https://api.b.ai/v1/models with Authorization: Bearer <redacted> returns HTTP 200 with a standard OpenAI-shaped body: {"object":"list","data":[{"id":"..."}, ...]} — 47 models, including qwen3.8-flash, qwen3.8-27b, qwen3.8-max.
• POST /v1/chat/completions with model: "qwen3.8-flash" returns a normal completion.
• A bad key returns a clean 401 with {"error":{"message":"Invalid token",...}}, so auth errors are easy to distinguish from an empty list.

Steps to Reproduce

1. Settings → API providers → «+» → Custom provider
2. Name: B.AI, Base URL: https://api.b.ai/v1, API key:
3. Save, restart the app
4. Model picker → Cloud → B.AI → "This server listed no models."

Expected

The mobile app shows the same model list the desktop app shows for the identical provider configuration.

Actual

Empty list, no error surfaced. The provider looks "connected", which makes it impossible to tell an auth failure from an empty catalog.

Notes / possible causes

• Since the desktop app parses this endpoint fine, a mobile-specific difference in how custom-provider model discovery composes the request or parses the response is likely (e.g. path handling differing from desktop, or a stricter mobile parse).
• A 401 from /models (e.g. trailing whitespace in a pasted key) seems to be rendered as "no models" rather than as an auth error on mobile. Surfacing the HTTP status in this message would help a lot.
• Related: [Bug] Mobile app doesn't support custom model ID and API Base URL #277 (mobile has no manual model ID / base-URL override), idea: Reload cloud models should fully sync with the provider #274 (Reload models does not fully sync).

Happy to provide the raw JSON of the /v1/models response (47 entries) or run any request you need — key is redacted for obvious reasons.

[Vect0rM]

Thank you for such a precise report — verifying the endpoint outside the app and calling out that the same credential works on desktop is exactly what made this a short hunt.

You were right that it is mobile-specific, and it has nothing to do with your server. Model listing for every provider goes through a small Rust command (get_local_http) rather than the webview's fetch, because doing the request natively sidesteps CORS and a body-streaming bug we hit with some OpenAI-compatible servers. That command was only ever registered in the desktop command handler — the mobile build has a separate one, and it was missed. So on iOS the call is rejected before a single byte reaches api.b.ai, and the empty list you saw was the app failing to ask, not your server failing to answer. The same applies to every custom and cloud provider on mobile, not just yours.

The fix in the next release registers those HTTP commands on iOS/Android as well, and adds a contract test that fails the build if a command shared frontend code calls is ever missing from one of the two handlers — that check previously compared against the union of both, which is why this slipped through.

Two more things from your report are in the same change, because you are right that they matter:

• The models list no longer says "nothing here" when the fetch actually failed. The reason is kept and shown in place of the empty state, so an invalid key reads as "Authentication failed: an API key is required or invalid…" instead of an empty catalog. A 401 and an empty list are no longer the same screen.
• A JSON error envelope returned with a 2xx ({"error":{"message":"Invalid token"}}) used to be parsed as "no models"; it now surfaces the server's own message.

On #277 — this does not add the manual model-ID field, but it should remove the need for the workaround, since discovery itself will work. That issue stays open on its own merits.

Thanks again, and if you are able to test once the next build is out, we would love to hear whether B.AI's 47 models show up. We truly appreciate your help in making Atomic Chat better!