Laravel 13 and PHP 8.5: AI and vector search in the framework, without breaking what exists

A major release that does not demand refactoring

Laravel 13 shipped on March 17, 2026. The minimum requirement moved to PHP 8.3 (supporting 8.3, 8.4, and 8.5), and PHP 8.2 support was dropped.

The most relevant point for anyone running production systems: the release arrived with no breaking changes relative to Laravel 12. In an ecosystem where "major version" usually means a sprint of adjustments, that changes the upgrade math — the decision stops being "is it worth the effort?" and becomes "what do I gain by moving up?"

The answer has three parts worth attention.

Passkeys: the most immediate win

Passkey authentication is now built into Fortify and the new starter kits — first-party, WebAuthn-based passwordless login.

Of everything in this release, this has the best return on effort in real systems. Passwords are the source of a disproportionate share of problems: email resets, reuse across services, phishing, support time spent on unlocks. Passkeys address all four at once, and now without a third-party package or a paid integration.

For internal systems — ERPs, admin panels, operations tooling — adoption is even simpler, because the device fleet is known and you can enable it as an option before making it the default.

First-party AI SDK: the value is in the decoupling

Laravel's AI SDK is now first-party and production-ready, with a provider-agnostic interface covering text, agents, images, audio, and embeddings. Switching between OpenAI, Anthropic, and Gemini becomes a configuration change.

The real benefit is not "add AI to your app" — any HTTP client could already do that. It is not binding your domain to a vendor. Anyone who integrated AI over the last two years straight against one provider's SDK has already discovered the cost of that when it came time to compare price, latency, or quality across models.

One note of sobriety: a provider-agnostic abstraction delivers the common denominator well. Model-specific capabilities tend to sit outside it or behind escape hatches. For most product use cases — classify, summarize, extract, draft — the common denominator is exactly what you need.

Vector search in the query builder: powerful and widely misunderstood

Semantic search reached the query builder through whereVectorSimilarTo(), letting you search by meaning rather than exact word matching.

It is the flashiest feature and the one most often implemented wrong. Three things teams tend to discover too late:

1. You have to generate and store embeddings. That means a processing step on every write, a cost per document, and a strategy for reindexing when the embedding model changes.
2. Vector search does not replace keyword search. It is excellent at "give me something like this" and poor at "give me exactly this product code." Mature systems combine both.
3. Quality depends on what you index, not on the database. Indexing the full text of a long document produces worse results than indexing well-chosen chunks.

Where it shines in business systems: knowledge base and support search, similar products in a catalog, record deduplication, and grouping similar tickets.

What else changed

PHP attributes became an optional — and non-breaking — alternative for class property declarations in fifteen or more places across the framework. It is syntactic sugar with a real readability effect, but there is no urgency in converting existing code.

Practical recommendation

If you are on Laravel 12 and PHP 8.3 or higher, the upgrade is cheap and worth scheduling. The adoption order that pays off most in production systems is: passkeys first (security and support load), AI SDK next (when there is a clear use case, not before), and vector search last — only when there is a real search problem that keyword search has already proven unable to solve.