Laravel AI SDK | Laravel 13.x - The clean stack for Artisans and agents

The Laravel AI SDK provides a unified, expressive API for interacting with AI providers such as OpenAI, Anthropic, Gemini, and more. With the AI SDK, you can build intelligent agents with tools and structured output, generate images, synthesize and transcribe audio, create vector embeddings, and much more — all using a consistent, Laravel-friendly interface.
You can install the Laravel AI SDK via Composer:
Next, you should publish the AI SDK configuration and migration files using the vendor:publish Artisan command:
Finally, you should run your application's database migrations. This will create a agent_conversations and agent_conversation_messages table that the AI SDK uses to power its conversation storage:
You may define your AI provider credentials in your application's config/ai.php configuration file or as environment variables in your application's .env file:
The default models used for text, images, audio, transcription, and embeddings may also be configured in your application's config/ai.php configuration file.
By default, the Laravel AI SDK connects directly to each provider's public API endpoint. However, you may need to route requests through a different endpoint - for example, when using a proxy service to centralize API key management, implement rate limiting, or route traffic through a corporate gateway.
You may configure custom base URLs by adding a url parameter to your provider configuration:
This is useful when routing requests through a proxy service (such as LiteLLM or Azure OpenAI Gateway) or using alternative endpoints.
Custom base URLs are supported for the following providers: OpenAI, Anthropic, Gemini, Groq, Cohere, DeepSeek, xAI, OpenRouter, and TypeSafe.
If you are using an OpenAI-compatible API, such as LM Studio, vLLM, Together, Fireworks, or a local gateway, you may configure an openai-compatible provider. The url option is required, while the key option is optional and will be sent as a bearer token when present:
Once configured, you may use the named provider like any other provider:
You may also configure a default text model for the provider so that you do not need to pass a model explicitly:
You may add custom HTTP headers to every outgoing request for the provider by defining a headers array in its configuration. This is useful when an endpoint requires an additional identifying or authentication header beyond the bearer token:
OpenAI-compatible providers support text generation, streaming, tools, structured output, image attachments, embeddings, transcription, and classification. If your endpoint requires additional request body fields, provide them using provider options.
Since arbitrary endpoints have no known models, you must configure a default embeddings model to use embeddings() with an OpenAI-compatible provider. You may also configure a fixed dimensions value; if omitted, the request is sent without a dimensions parameter and the model's native dimensions are used.
Likewise, you must configure a default transcription model to use Transcription with an OpenAI-compatible provider. The audio will be uploaded to the endpoint's /audio/transcriptions route as a standard multipart request:
OpenAI-compatible and Groq providers do not support diarization. Invoking the diarize method when using these providers will throw an exception.
If your endpoint implements OpenAI's decisions endpoint, you may use classification with an OpenAI-compatible provider. The SDK sends questions to the endpoint's /decisions route and supports image attachments. Since the SDK does not know which models your endpoint supports, configure a default classification model or pass a model to the classify method:
Sometimes you may need to use provider credentials that are not defined in your application's configuration file, such as API keys that are stored in your database for each tenant of a multi-tenant application. You may use the Ai::build method to create a provider from a configuration array. The array should have the same structure as a provider entry in your application's config/ai.php configuration file:
On-demand providers may be used anywhere a provider is accepted, including failover lists and when generating images, audio, transcriptions, and embeddings. To specify a model for an on-demand provider, include a models array in its configuration:
When an agent should always use an on-demand provider, you may return the provider from the agent's provider method. Since the provider is rebuilt when the agent is used, this approach also works well for queued agents:
You should pass on-demand providers within an array, as shown in the examples above. If you give an on-demand provider a name in its configuration array, the name may not match a built-in provider or a provider defined in your config/ai.php configuration file.
The AI SDK supports a variety of providers across its features. The following table summarizes which providers are available for each feature:
The Laravel\Ai\Enums\Lab enum may be used to reference providers throughout your code instead of using plain strings:
Agents are the fundamental building block for interacting with AI providers in the Laravel AI SDK. Each agent is a dedicated PHP class that encapsulates the instructions, conversation context, tools, and output schema needed to interact with a large language model. Think of an agent as a specialized assistant — a sales coach, a document analyzer, a support bot — that you configure once and prompt as needed throughout your application.
You can create an agent via the make:agent Artisan command:
Within the generated agent class, you can define the system prompt / instructions, message context, available tools, and output schema (if applicable):
To prompt an agent, first create an instance using the make method or standard instantiation, then call prompt:
The make method resolves your agent from the container, allowing automatic dependency injection. You may also pass arguments to the agent's construc