Skip to main content
One of Polyglot’s core design principles is that your request code should remain stable while the provider configuration changes. A preset is a named YAML file that bundles everything the runtime needs — driver type, API URL, credentials, default model, and token limits — into a single, swappable unit. When you call Inference::using('openai'), Polyglot loads the openai.yaml preset from the configuration directory and builds a fully wired runtime behind the scenes. Switching providers is a one-line change.

Switching Providers

Because presets encapsulate all provider details, the same request code works against any supported backend:
You can also override the model on a per-request basis without creating a new preset:

Understanding Presets vs. Driver Types

It is important to distinguish between a preset name and a driver type. A preset name (e.g. openai, ollama, custom-local) is an arbitrary label for a YAML configuration file. A driver type (e.g. openai, anthropic, openai-compatible) refers to the underlying protocol implementation that Polyglot uses to communicate with the API. Multiple presets can share the same driver. For example, you might create a local-llama preset that uses the openai-compatible driver pointed at a local Ollama instance, and a together preset that also uses the openai-compatible driver pointed at the Together AI API. Polyglot ships with the following driver types:

Implementing Fallbacks

Polyglot does not impose a fallback policy. Fallback behavior belongs in application code, where you have the context to decide which providers to try and how to handle failures:
This pattern gives you full control over retry logic, logging, and error handling at each step of the fallback chain.

Cost-Aware Provider Selection

You can route requests to different presets based on the complexity or importance of each task. This pattern lets you reserve expensive models for critical work while using cheaper alternatives for simpler queries:

Task-Based Provider Selection

Different providers may excel at different tasks. You can map task types to the most appropriate preset, routing creative writing to one model and code generation to another:
Tip: You can combine cost-aware and task-based routing. For example, use a cheap local model for simple factual lookups but route complex creative tasks to a premium cloud provider.

Reusing an Inference Instance

Each call to Inference::using() loads the preset YAML and builds a new runtime. If you plan to issue many requests against the same provider, create the instance once and reuse it:
Because Inference uses immutable builder methods (each call returns a new copy), sharing a single instance across concurrent requests is safe.