Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Laravel Ai Core

Laravel Ai Core Laravel Package

apavliukov/laravel-ai-core

Laravel AI Core provides a foundation for integrating AI capabilities into Laravel applications, with configurable drivers, service bindings, and a consistent API for working with AI models and providers. It aims to keep AI configuration and usage organized, testable, and framework-native.

View on GitHub
Deep Wiki
Context7

At a glance

Frequently asked questions about Laravel Ai Core
How do I install apavliukov/laravel-ai-core in a Laravel application?
Install it with Composer using composer require apavliukov/laravel-ai-core. Laravel package auto-discovery registers the service provider and facades, so no manual wiring is needed in a standard app. After that, publish the package config and any migrations for model assignments and reports, then set your default provider and credentials. Run your test suite immediately after install so you catch any subject key stamping issues on your own models early.
Which Laravel and PHP versions does laravel-ai-core support?
The package follows normal Laravel conventions and installs via Composer with auto-discovery, but you should verify the exact constraints in its composer.json require block before adopting. Check whether the repository publishes a CI matrix and coverage signal, because that is the only reliable way to confirm which Laravel and PHP combinations are actually tested. Pay attention to whether that matrix covers host-model trait ordering scenarios, since subject key stamping depends on that lifecycle. Treat the tested matrix as your support boundary rather than assuming current Laravel versions are covered.
How do I configure AI providers and drivers in Laravel AI Core?
Configuration is file-driven and aligned with Laravel conventions: you publish the package config, choose a default driver, and supply provider credentials and options there. The service provider then binds the package contracts to the configured driver implementations, which you can resolve through the container or the provided facades. Keep vendor-specific settings out of application code and inside config so environment changes do not require code edits. If you need per-model or per-subject settings, use the assignment records rather than branching on provider names in your services.
Can I swap AI backends without rewriting application logic?
Yes, that is the main purpose of the package. Your application code depends on the unified client and response contracts instead of a vendor SDK, and the configured driver decides which backend actually runs. Switching providers is then mostly a config and credential change, plus any capability differences you need to handle in your own code. Responses still differ in quality and features, so test prompts and output parsing against each driver you intend to use.
How do I create a custom AI driver for laravel-ai-core?
Implement the package client contract and return responses that satisfy the response contract, keeping all vendor HTTP calls inside your driver class. Register the driver in the package config so the service provider can resolve it like a built-in one. Because the package owns the surrounding plumbing, your driver stays small and testable with a fake HTTP client. Pin a package version while writing the driver, since the contracts are still pre-1.0 and can change on minor releases.
How do I test code that uses laravel-ai-core?
Use the package row factory to build model assignment and report fixtures instead of hand-rolling records, which keeps your feature tests short. Bind a fake client implementation into the container so tests never hit a real AI provider. Then assert on the contract-level behaviour your code depends on rather than on vendor payloads. Add a dedicated test that verifies subject keys are stamped correctly on your host models, because that write path is order-sensitive relative to trait bootstrapping.
Is upgrading from 0.4.0 to 0.4.1 safe, and what changed in 0.4.0?
Version 0.4.0 was a breaking minor release: assign() is now final and the store() extension point changed, so any subclass overriding assign() will fail with a fatal error rather than a deprecation. Version 0.4.1 is a patch that stamps the subject key before host traits run and sharpens the factory, with no new migration work beyond 0.4.0. Blast radius is narrow if you only consume the package, but read the changelog and confirm whether an upgrade guide for store() exists before bumping. Also confirm whether the factory change altered any method signatures or return shapes, since sharper is ambiguous in a patch release.
What is subject key stamping and why is it a data integrity risk?
Model assignments are a polymorphic pivot, and the package now derives and persists a stable subject key on write. The 0.4.1 fix for stamping before host traits implies 0.4.0 could stamp at the wrong point in the model lifecycle, producing mis-derived or null keys and silently unmatched assignments. Treat that as a data integrity concern rather than a code concern: write a verification test and, if you ran 0.4.0 with real traffic, check whether existing rows need repair or backfill. Re-keying polymorphic rows also implies migrations, so plan the migration footprint before adopting.
Do rejected-answer reports store PII, and how should I handle retention?
Reports create a table that can grow without bound and is likely PII-adjacent, because rejected answers may include prompt text or subject identifiers. Nothing in 0.4.1 addresses retention, redaction, or write-path coupling, so verify exactly what is persisted before enabling the feature. Make report capture opt-in, add a retention and pruning policy, and redact or hash identifiers you do not need. Review the write path for coupling to your application code so sensitive data is not captured implicitly.
Is laravel-ai-core production-ready given the pre-1.0 churn and a single maintainer?
It is usable, but the 0.x versioning means breaking changes can ship on minor releases, so budget rework on each bump and pin versions with a tested upgrade path. The project is maintained by a single author, so bus factor and long-term support are the dominant non-technical risks; the fast 0.4.1 turnaround is a positive responsiveness signal but does not change that. For critical workloads, compare against direct vendor SDK usage or other maintained Laravel AI abstraction packages and keep your own thin layer around the contracts. Whichever route you take, keep provider-specific code isolated so a swap stays cheap.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource