OpenAI-compatible providers: decide what supporting them means, then make the claim true

What

Seven providers ship an OpenAI-compatible API and are therefore already reachable through chat.ProviderOpenAICompatible with a BaseURL:

Provider Notes
xAI (Grok) OpenAI-compatible endpoint
Groq already named in the core's own doc comment as a supported example
Mistral AI OpenAI-compatible endpoint
DeepSeek OpenAI-compatible endpoint
Meta (Llama API) OpenAI-compatible endpoint
Hugging Face OpenAI-compatible router
Vercel AI Gateway OpenAI-compatible gateway

This issue is not "add seven adapters". It is: decide what supporting them actually means, then make the claim true.

Why it needs doing at all

client.go:22 says:

// ProviderOpenAICompatible uses any OpenAI-compatible API endpoint (e.g. Ollama, Groq).

Nothing tests that. There is no capability table for a compatible endpoint, no model detection, and no conformance run against one. Groq is named in shipped documentation on the strength of the wire protocol being similar.

That is the same shape as the defect in #13 (closed): a claim that reads as a working feature, with nothing exercising it. The difference is that here it may well work — nobody knows, which is the problem.

What is actually missing, as opposed to absent

  • Capability reporting. models_generated.go is keyed on OpenAI model names. grok-4, mixtral-8x7b and deepseek-chat resolve to nothing, so Capabilities() reports unknown and the sampling and effort guards cannot pre-validate anything. A caller gets no error and no protection.
  • Compatibility is a spectrum, not a flag. Tool calling, streaming, structured outputs, logprobs, seed and prompt caching are each supported, partially supported or absent depending on the provider. One provider name cannot describe that, and today it does not try.
  • No evidence. The conformance suite exists precisely to stop providers drifting from the contract, and it has never been run against a compatible endpoint.

What the spec has to settle

  1. Named providers, or one compatible mode? A named constant per provider buys a capability table and a default model; it also multiplies the release surface by seven. The alternative is one mode plus a way for a caller to declare what their endpoint supports.
  2. Where a capability table for a third-party endpoint would come from. These providers do not all publish a machine-readable listing, and detectmodels assumes one.
  3. What Capabilities() should say when the model is unknown. Today it degrades to "send it and let the API judge", which is defensible for a model released after the table was generated and much weaker as a permanent answer for an entire class of endpoint.
  4. Which of the seven to actually verify, and how, given each needs an account and a key. A conformance run against a live endpoint is the strongest evidence available and it is not free.
  5. What to do about the Groq claim in the meantime — verify it, or stop making it.

Scope

A spec before code. The likely first deliverable is evidence rather than features: run the conformance suite against two or three of these and publish what happened, because the answer changes the design.

Related: the genuinely different ones are tracked separately — AWS Bedrock needs its own module, Azure OpenAI is a construction path inside chat-openai (chat-openai#4 (closed)), and Vertex AI is a backend inside chat-gemini (chat-gemini#5 (closed)).