The agent's chain-of-thought was never shown: glm-5.2 (and other openai-
compatible providers — DeepSeek, etc.) stream their thinking as
`reasoning_content` deltas, but the official @ai-sdk/openai provider does NOT map
that field (verified: 0 occurrences in the package), so our
`createOpenAI(...).chat()` silently dropped it. The model "thinks" server-side
and only the final answer streamed — which also made the connection look idle
during a long reasoning phase.
Fix: for the `openai` driver with a CUSTOM baseURL (an openai-compatible
third-party endpoint), build the model with @ai-sdk/openai-compatible instead.
It maps the streamed `reasoning_content` to reasoning parts (confirmed live: the
stream now carries reasoning-start/delta/end), which the client already renders,
and it targets Chat Completions (the portable endpoint these gateways accept on
multi-turn history). Real OpenAI (no baseURL) keeps the official provider.
Verified on the stand against z.ai glm-5.2: reasoning parts now stream; MCP tool
calls (searxng/crawl4ai), the multi-step agent loop, and a normal finish all
still work.
Tests: ai.service.spec asserts the provider switch (custom baseURL ->
openai-compatible; no baseURL -> openai.chat). AI/mcp specs green. server tsc
clean.
Note: complementary to the long-turn timeout fix (#175 / PR fix/ai-stream-undici-
timeout) — they touch the same openai case and compose at merge.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
fe1bbbe806