Skip to main content
Provider objects sit between configuration and runtime assembly. They resolve config values from presets, arrays, or explicit objects, and optionally carry an explicit driver instance. Runtimes use providers to determine which driver to build and how to configure it.

LLMProvider

LLMProvider is a builder that wraps an LLMConfig and an optional explicit driver. It implements CanResolveLLMConfig and HasExplicitInferenceDriver, which the runtime uses during assembly. Namespace: Cognesy\Polyglot\Inference\LLMProvider

Creating a Provider

Customizing a Provider

All mutators return a new immutable instance:
When an explicit driver is set, the runtime uses it directly instead of building one from the config. This is useful for testing or for providers that need custom initialization.

How the Runtime Uses It

When you call InferenceRuntime::fromProvider($provider), the runtime:
  1. Calls $provider->resolveConfig() to get the LLMConfig
  2. Checks if $provider->explicitInferenceDriver() returns a driver
  3. If an explicit driver exists, uses it directly
  4. Otherwise, looks up the driver name from the config and creates one via the InferenceDriverRegistry

EmbeddingsProvider

EmbeddingsProvider serves the same role for embeddings. It wraps an EmbeddingsConfig and an optional explicit driver. Namespace: Cognesy\Polyglot\Embeddings\EmbeddingsProvider

Creating a Provider

Unlike LLMProvider, EmbeddingsProvider does not have a using(...) shortcut for presets. Use Embeddings::using(...) or construct the config explicitly.

Customizing a Provider

Driver Factories

Inference Driver Registry

The InferenceDriverRegistry manages the mapping between driver names and their factory callables. Polyglot ships with a default set of bundled drivers via BundledInferenceDrivers::registry(). Supported inference drivers include: You can extend the registry with custom drivers:
A custom driver can be registered as a class name (must accept LLMConfig, CanSendHttpRequests, and CanHandleEvents in its constructor) or as a callable factory:
You can also remove drivers from the registry:

Embeddings Driver Registry

The EmbeddingsDriverRegistry follows the same immutable instance-based pattern as InferenceDriverRegistry. Bundled embeddings drivers are provided via BundledEmbeddingsDrivers::registry() and include: openai, azure, cohere, gemini, jina, mistral, and ollama. Custom embeddings drivers can be registered through the registry:
Or with a factory callable:
Both InferenceDriverRegistry and EmbeddingsDriverRegistry use immutable instance-based registration, so driver registrations can vary per runtime.

Key Contracts

The provider system is built on a small set of interfaces:

Provider Contracts

Driver Contracts

Adapter Contracts

The driver contract CanProcessInferenceRequest also includes a capabilities() method that reports what features a driver supports (e.g., streaming, tool calls, structured output). This can be used to make runtime decisions about which features to use with a given provider: