feat: poe support responses api

[kovsu]

What this PR does

Before this PR:
Poe provider relied on model.endpoint_type to determine which SDK backend to use, but Poe models fetched from API never have this field set, causing all models to fall back to the OpenAI
Compatible Chat path. Claude models on Poe couldn't use the Anthropic SDK, and GPT/O-series models couldn't use the Responses API.

After this PR:
Poe provider routes models to the correct AI SDK backend based on model ID:

• Claude models → AnthropicMessagesLanguageModel (Anthropic Compatible API)
• GPT/O-series models → OpenAIResponsesLanguageModel (Responses API)
• All other models (Gemini, Grok, Llama, etc.) → OpenAICompatibleChatLanguageModel (Chat Completions API)

Also adds proper web search support (extra_body.web_search for chat-path models, native SDK web search for Claude/GPT) and removes redundant Poe-specific reasoning logic now handled by the
standard pipeline.

Fixes #

Why we need it and why it was done in this way

The following tradeoffs were made:

• Used inline modelId.toLowerCase().startsWith('claude') instead of importing isAnthropicModel utility to avoid pulling in heavy renderer dependency chains during module initialization.
• Used deep path import (@renderer/config/models/openai) instead of barrel import (@renderer/config/models) for the same reason.

The following alternatives were considered:

• Single endpoint_type-based routing (rejected: Poe models from API lack this field)
• 2-way routing (Claude vs. everything else to Responses API) — rejected because models like o1-mini, o1-preview, and search-preview models only support Chat Completions

Breaking changes

None

Special notes for your reviewer

• The 3-way routing logic mirrors the approach used by aihubmix provider which also uses { id: modelId } as Model to call model detection utilities.
• poe-provider.ts is registered as a ProviderExtension with LRU caching, consistent with other custom providers.

Checklist

• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Documentation: A user-guide update was considered and is present (link) or not required.
• Self-review: I have reviewed my own code before requesting review from others

Release note

Add poe as custom provider to support responses api.

[kovsu]

Note

This comment was translated by Claude.

Here are some local tests I conducted

Anthropic

Uses /messages, and reasoning effort and websearch parameters are passed correctly

OpenAI

Checks if /responses is supported, and reasoning effort and websearch parameters are passed correctly

Gemini

All models that are not Anthropic or OpenAI (that don't support responses) will use /chat. /chat previously had special handling for poe that allowed /chat requests to carry the websearch parameter. The reasoning effort here is newly handled in buildPoeProviderOptions, so the previous special handling can be removed.

---

Original Content

这是我在本地的一些测试

Anthropic

走 /messages，并且 reasoning effort 和 websearch 这些参数正常传递

OpenAI

判断了是否支持 /responses，并且 reasoning effort 和 websearch 这些参数正常传递

Gemini

所有 非 Anthropic 或者 OpenAI（不支持 responses）的模型都会走 /chat。/chat 之前已经给 poe 做过特殊的处理，会让 /chat 的请求也携带 websearch 参数。然后这里的 reasoning effort 是 buildPoeProviderOptions 里新处理的，所以之前的特殊处理可以移除了。