- What is laravel/ai and which AI providers does it support?
- laravel/ai is the official Laravel AI SDK, a unified API layer for OpenAI, Anthropic, Gemini, and other providers. It normalizes text generation, agents with tools, structured output, embeddings, image generation, and audio transcription or synthesis behind one Laravel-friendly interface. It is distributed via Composer under the MIT license.
- How do I install and configure laravel/ai in a Laravel application?
- Install it as a Composer dependency and configure provider connections according to the official Laravel AI SDK documentation. Configuration is provider-driven and supports custom HTTP headers, which helps with proxies or gateways. Reuse your existing Laravel config and environment conventions, and keep credentials and model identifiers under code review.
- Does laravel/ai support agents, tools, and structured output?
- Yes. The SDK is designed for intelligent agents with tools and structured output, along with text generation, embeddings, image generation, and audio transcription or synthesis. Tool loops and provider normalization are handled by the SDK, but provider-specific features may arrive later or require escape hatches. Validate agent behavior with your own evals rather than relying only on test fakes.
- Which Laravel and PHP versions are supported by laravel/ai?
- The package is the official Laravel AI SDK and declares its Laravel and PHP constraints in its composer.json, so check Packagist or run Composer's constraint check for your app. Because it is pre-1.0 and moving quickly, confirm compatibility against the exact Laravel version you run. Pin a tested release train instead of floating to latest.
- Is laravel/ai production-ready given it is still pre-1.0?
- It is capable and officially maintained, but v0.11.x is pre-1.0, so semver permits breaking changes and releases are frequent. Treat it as a strong-but-early dependency: pin versions, schedule minor upgrades, and keep any internal wrapper thin. Do not build customer billing directly on reported token counts without independent reconciliation.
- How does laravel/ai handle image generation, audio, and embeddings?
- These modalities are exposed through the same unified API, and generation work such as images, audio, transcription, and embeddings can be queue-backed to reuse existing workers. Generated media can be stored on Laravel filesystem disks, including S3. The SDK also provides fakes for queued generation so you can test plumbing without calling providers.
- How do I test Laravel code that uses laravel/ai?
- The SDK provides first-class test fakes, including assertPrompted, assertPromptedTimes, and faked queued generation, matching Laravel's testing culture. These fakes are useful for validating prompts, dispatch, and integration seams. They do not validate model output quality, so add a separate eval harness in CI for quality checks.
- Can laravel/ai work with multiple AI providers or failover?
- The SDK is a vendor-abstraction layer across OpenAI, Anthropic, Gemini, Bedrock, Azure, xAI, Groq, Mistral, DeepSeek, and OpenRouter, with config-driven provider connections. That makes switching providers and implementing failover more practical than wiring separate SDKs. Confirm that every provider and modality you need is covered today, because provider-specific features can lag the common abstraction.
- What are the main risks of using laravel/ai?
- The main risk is maturity: pre-1.0 breaking changes and a rapid release cadence mean you need version pinning and an upgrade policy. Provider-model drift can make defaults stale, and abstraction lag means provider-specific features may need escape hatches. Token and usage accounting has had repeated fixes, so reconcile costs independently for billing.
- Should I use laravel/ai or call provider SDKs directly?
- Use laravel/ai when you want a Laravel-native abstraction that reduces provider plumbing, retries, streaming normalization, media storage, and tool loops to a Composer dependency. Call provider SDKs directly, or use an escape hatch, when you need a provider-specific feature that the abstraction does not expose yet. Many teams will use the SDK for common paths and keep a thin internal wrapper for provider-specific gaps.