First-class support for OpenAI-compatible (OpenAPI-compatible) LLM providers in TanStack AI

[RadheyMugdal]

Hi 👋
TanStack AI is great,

One limitation I ran into: TanStack AI currently requires provider-specific adapters, which makes it hard to use OpenAI-compatible APIs such as OpenRouter, Together, Groq, Fireworks, or self-hosted gateways.

It would be great to have first-class support for OpenAI-compatible providers, for example:

openai({
  apiKey,
  baseURL: 'https://api.openrouter.ai/v1',
})

or a generic openaiCompatible() adapter.

Why this matters

• Easier provider switching
• Lower cost / fallback models
• Wider ecosystem support
• No breaking changes

Thanks for considering this

[thejasonxie]

#123

[AlemTuzlak]

This has been implemented ever since!

[richardchen874-sys]

First-class OpenAI-compatible provider support would be very useful. The main thing I would want is a clean abstraction for model capabilities, pricing, context length, streaming, and fallback behavior, because provider choice often becomes an operational decision rather than just an SDK decision. I am working on an OpenAI-compatible multi-model API layer focused on official Chinese models, so this provider interface discussion is very relevant to what I am testing.

[AlemTuzlak]

It already exists today with openaiCompatible

[richardchen874-sys]

Thanks for clarifying — that is good to know.

In that case, the interesting part for me is probably less “does an OpenAI-compatible provider work at all” and more how much provider metadata the abstraction can express: context length, pricing, streaming support, tool-call behavior, structured output reliability, and fallback rules.

For multi-provider setups, those details often matter more than the base URL itself, because the app needs to decide which model is safe or cost-effective for each task.

If I test a few lower-cost OpenAI-compatible models against this interface, is there a preferred example or docs page for the current openaiCompatible path?