Using Multiple LLM Providers with the Laravel AI SDK

The Laravel AI SDK (laravel/ai, v0.8.1) ships with built-in support for 14 AI providers: OpenAI, Anthropic, Google Gemini, Groq, Mistral, DeepSeek, xAI, Ollama, Azure OpenAI, Cohere, OpenRouter, Jina, VoyageAI, and ElevenLabs. That breadth is genuinely useful — but unlocking it correctly requires more than swapping an env variable. This article covers how to configure multiple providers in the same application, switch between them at runtime, handle provider-specific failures, and test the whole setup without hitting a live API. Prerequisites PHP 8.3+ Laravel 12 or 13 laravel/ai v0.8 (pin to ^0.8 in composer.json until v1.0 ships — the package is still pre-1.0) At least two provider API keys (we'll use OpenAI and Anthropic for the walkthrough) Install the SDK if you haven't already: composer require laravel/ai php artisan vendor:publish --tag=ai-config How the SDK Resolves Providers When you call AI::text()->using('gpt-4o-mini')->..., the SDK maps the model string to a provider using the published config/ai.php. The default config reads a single AI_PROVIDER env variable. That's fine for a simple setup, but in a multi-provider application you need named provider instances instead. Here is the relevant section of config/ai.php after customisation: // config/ai.php 'providers' => [ 'openai' => [ 'driver' => 'openai', 'api_key' => env('OPENAI_API_KEY'), ], 'anthropic' => [ 'driver' => 'anthropic', 'api_key' => env('ANTHROPIC_API_KEY'), ], 'groq' => [ 'driver' => 'groq', 'api_key' => env('GROQ_API_KEY'), ], 'openrouter' => [ 'driver' => 'openrouter', 'api_key' => env('OPENROUTER_API_KEY'), ], ], And the matching .env entries: OPENAI_API_KEY=sk-... ANTHROPIC_API_KEY=sk-ant-... GROQ_API_KEY=gsk_... OPENROUTER_API_KEY=sk-or-... Never prefix these with NEXT_PUBLIC_ — all AI calls must go through the Laravel backend. A frontend that calls an LLM directly exposes your API key to every browser that loads the page. Selecting a Provider at Call Time The using() method accepts a model identifier that the SDK resolves to a provider. You can be explicit: use Illuminate\Support\Facades\AI; // GPT-4o-mini via OpenAI $openAiResult = AI::text() ->using('gpt-4o-mini') ->prompt($userMessage) ->generate(); // Claude Sonnet via Anthropic $claudeResult = AI::text() ->using('claude-sonnet-4-5') ->prompt($userMessage) ->generate(); // Llama 3 via Groq (fast inference) $groqResult = AI::text() ->using('llama3-70b-8192') ->prompt($userMessage) ->generate(); The SDK looks at the model string and matches it to the correct provider driver configured in config/ai.php. If a model string is ambiguous (e.g. two providers offer a model with the same name), qualify it with a provider prefix: // Explicit provider prefix avoids ambiguity $result = AI::text() ->using('openai:gpt-4o') ->prompt($prompt) ->generate(); Building a Provider Router A common production pattern is to choose the provider based on the task type. Create a simple service class rather than scattering using() strings throughout controllers: