feat(backend): surface self-hosted reasoning via @ai-sdk/openai-compatible

[MesoX]

Summary

Chat-completions mode (apiMode=chat) on an OpenAI provider is, in practice, only used against self-hosted / company OpenAI-compatible servers (vLLM, SGLang, llama.cpp, TGI, LM Studio) — real OpenAI is driven via the Responses API. Those servers expose the model's thinking in a reasoning_content field, but @ai-sdk/openai's chat model only parses role/content/tool_calls and silently drops it. So the existing reasoning UI never received anything from them.

This routes chat-mode language models through @ai-sdk/openai-compatible, which reads reasoning_content (and reasoning) natively and emits reasoning stream parts — rendered by the existing collapsible "Thinking…" block. No frontend changes.

Changes

• Add @ai-sdk/openai-compatible dependency (depends on the same @ai-sdk/provider@3 as the other adapters).
• provider.ts: for OpenAI providers with apiMode==="chat", build the language model via createOpenAICompatible(...). Embeddings and native search tools stay on the OpenAI SDK. Responses mode is unchanged.
• Set includeUsage: true so streamed turns carry stream_options.include_usage — without it self-hosted servers return no token usage on the streaming path (shows as In:0 / Out:0).
• Tests covering chat→compatible routing and responses→OpenAI dispatch.

Behavior notes

• Real OpenAI in chat mode is unaffected — it returns no reasoning_content, so no reasoning parts are emitted.
• supportsStructuredOutputs is left at its default (false): a requested JSON schema downgrades to json_object mode (the AI SDK still validates client-side), which is safe across servers that don't support json_schema response_format. This only affects the title/tag generation call.

Testing

• typecheck, lint, and the provider unit tests pass.
• Verified end-to-end against a vLLM server (Qwen3, reasoning parser enabled): reasoning streams into the collapsible block and token usage populates.

🤖 Generated with Claude Code