Skip to content

Providers

This section is the compatibility inventory: dedicated adapters for protocols that require real translation, plus declarative presets for OpenAI-compatible services and engines. Breadth is useful, but it is not AnyInfer's product boundary; start with why and when to use AnyInfer when choosing an integration layer.

The generated complete inventory is the full accessible rendering: all 106 providers (20 dedicated adapters, 86 presets), each with its target prefixes, key variable or default endpoint, and notes.

  • OpenAI openai:
    Responses API, reasoning-token accounting.
    Hosted

  • Anthropic anthropic: / claude:
    Messages API, extended thinking deltas.
    Hosted

  • Google Gemini gemini: / google:
    Native generateContent, thinking levels, discovered windows.
    Hosted

  • DeepSeek deepseek:
    Separate reasoning channel, split cache accounting.
    Hosted

  • xAI (Grok) xai: / grok:
    Provider-reported cost, discovered pricing.
    Hosted

  • Google Vertex AI vertex:
    Gemini with GCP auth; project-scoped addressing.
    Enterprise

  • AWS Bedrock bedrock:
    Converse API, SigV4 or API key, binary streaming.
    Enterprise

  • Cohere cohere:
    Native v2 chat, grounded generation, thinking channel.
    Hosted

  • Voyage AI voyage:
    Specialist embeddings and reranking; query/document intents.
    Hosted

  • Jina AI jina:
    Specialist embeddings and reranking; full task vocabulary.
    Hosted

  • Text Embeddings Inference tei:
    Local embeddings and reranking; retrieval-only, one model per server.
    Local

  • LM Studio lm-studio:
    Native discovery: context, quantization, residency.
    Local

  • Ollama ollama:
    Native API, grammar schemas, phase timings.
    Local

  • llama.cpp llama-cpp:
    Supervised llama-server, loopback only.
    Local

  • OpenAI-compatible openai-compat:
    Any /chat/completions endpoint by URL.
    Local Hosted

  • Hosted & local presets groq: together: mistral: vllm:
    Eighty-six OpenAI-compatible services and engines, preconfigured.
    Local Hosted

  • OpenRouter openrouter:
    Rich discovered pricing and context data.
    Hosted

  • Nebius Token Factory nebius:
    Live pricing, context, quantization, and reasoning channels.
    Hosted

  • Azure AI Foundry azure-foundry: / azure:
    max_completion_tokens, API key or Entra auth.
    Enterprise

  • GitHub Copilot copilot:
    auto sentinel, CLI-delegated auth.
    Hosted

  • Microsoft 365 Copilot m365-copilot: / m365:
    Interactive auth only, the most constrained provider.
    Enterprise

See the conformance matrix for exactly which behaviors each one supports, generated from test results rather than asserted.

What Is the Same Everywhere

Since the core owns orchestration, routing and retries, structured-output validation, cost accounting, timing, telemetry, and the event stream behave identically no matter which provider served a request. The concepts section documents each.

What Differs, and How You Find Out

Real differences are surfaced, never hidden:

  • Capability flags say what a model supports, with provenance.
  • structured_mechanism on each result says how a schema was actually enforced.
  • ParameterDropped events fire when a provider accepts a parameter and discards it.
  • Provider pages document the rest.

Reaching Provider-Specific Parameters

Anything a provider supports that AnyInfer does not model is reachable verbatim:

client.generate(
    prompt,
    target="ollama:qwen3:8b",
    provider_options={"ollama": {"keep_alive": "10m", "num_gpu": 99}},
)

Options are namespaced by provider id and passed straight through to the matching adapter; the core never inspects them. A developer should never have to fork the library to reach a provider-specific feature.

Adding Your Own

Third-party adapters register through the anyinfer.providers entry-point group and prove themselves with the same conformance suite the built-ins run. See writing an adapter.