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.
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_mechanismon each result says how a schema was actually enforced.ParameterDroppedevents 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.