Models and Providers

Find a Model for Your Task

Use the provider directory to explore integrations, or filter the model catalog by task. Open a model to review its exact ID, input and output types, capabilities, and provider documentation.

Choose based on the workflow you need: text generation, media generation, retrieval, document processing, or an audio workflow. Models from the same provider can expose different endpoints and capabilities.

A language model that several providers host is listed once, with each host as an endpoint that has its own price, limits, quantization and data policy. Send the model’s ID to let routing choose a host, or a host’s own ID, shown on the model’s page, to use that host only.

Distinguish Catalog Coverage from Access

A catalog entry describes an integration. Deployment configuration, key scopes, provider availability, and the supported operation determine whether a request can run. Treat a preview badge as a reason to check prerequisites, not as evidence of production access.

Use the model listing and the model’s capabilities to inform selection. Language requests use the same API URL as audio and other model types. A successful metadata request does not exercise provider inference, billing, or every model option.

Run a small representative request before integrating the model into your application. Keep the model ID with its task and endpoint; a provider name alone is not enough configuration.

When a provider announces a shutdown, the model list shows it as expiration_date. From that date the model leaves the list, requests to it are refused, and looking it up returns state: "disabled". Move to a replacement before the date.

Check Uptime, Latency, and Throughput

Language, speech, and transcription models publish their recent performance on their model pages and through model stats, which needs no key:

curl "$AUDIOLAB_API_URL/v1/models/openai/gpt-5.5/stats?window=7d"

The response has a summary and a series for the window (24h, 7d, or 30d), and the same for each provider when a model has more than one. A model that several hosts serve, such as openai/gpt-oss-120b, combines every host's numbers and splits them by endpoint: each entry names the endpoint's routing tag (deepinfra/turbo) and its host-pinned ID. The numbers combine customer requests with AudioLab's probes, which send every offered model a tiny request every two hours.

• Uptime is the share of attempts that succeeded. Failures caused by the request itself, such as invalid or oversized input, a content filter, or a cancelled request, are not counted.
• Latency is the time to first token for language models, the time to first audio for speech, and the whole call for transcription.
• Throughput is output tokens per second after the first token, input characters per second of synthesis, or seconds of audio transcribed per second. It comes from customer requests only, since a probe's output is too short to measure speed.

An interval with no attempts has null values. The endpoint listing also carries the last day's uptime: uptime_last_1d as a percentage for a language model, uptime as a fraction on other endpoints.

Use Provider-specific Options Deliberately

AudioLab normalizes common request fields where possible. Native options are supported only where the integration implements them. A parameter appearing in a provider’s own documentation does not mean it can be passed through every AudioLab endpoint.

Begin with the AudioLab endpoint reference, then consult the model’s linked provider documentation for details such as voice IDs or language behavior. If you select automatic routing, avoid provider-specific options that unnecessarily exclude other candidates.

For comparisons, keep your inputs, required features, and output settings consistent. Evaluate quality alongside latency and cost; a model that accepts the request can still be a poor fit for your application.