Service S·05

Laravel AI Integration

OpenAI and Claude features built into existing Laravel applications — queued jobs, streamed responses, cost controls, and no big-bang rewrite.

Last reviewed: 24 July 2026

01 · Definition

What is Laravel AI integration?

Laravel AI integration is the engineering work of adding LLM-powered features — chat, summarisation, extraction, semantic search — to a Laravel application so they run reliably in production. In practice that means dispatching model calls as queued jobs instead of blocking HTTP requests, streaming responses to the browser, enforcing per-tenant token budgets, versioning prompts alongside code, and testing AI behaviour the way you test any other business logic. Rohan Jalil has worked in Laravel for over a decade — including the published Packagist package rohan/dynamic-form-builder — and builds AI features on the primitives the framework already gives you: queues, jobs, events, and Horizon. The result is AI functionality that ships inside your existing app, respects its architecture, and keeps API spend measurable and capped.

This is a different discipline from prototyping. A demo that calls OpenAI from a controller works in a screencast; a production feature has to survive provider timeouts, concurrent tenants, deploys, and a finance team that wants to know what the invoice will be.

02 · The problem

Why do AI features strain a Laravel app?

LLM calls behave unlike anything else in a typical PHP request cycle: they take seconds, fail in new ways, and bill by the token. Bolting them onto a controller ignores all three properties.

Concern	Bolt-on approach	Production integration
Request lifecycle	Synchronous controller call holds the request open until the model responds — or PHP times out	Model calls dispatched as queued jobs; the request returns at once and the UI receives results as they land
Streaming	None — the user watches a spinner for the full generation	Tokens streamed to the browser over server-sent events as the model generates
Retries & timeouts	A failed provider call surfaces as a 500 error	Backoff, retry, and timeout budgets handled by the queue worker, with a fallback model where it makes sense
Cost tracking	Spend is unknown until the provider invoice arrives	Token usage logged per feature and per tenant, with hard budgets that stop runaway spend
Prompt & version management	Prompts hard-coded inside controllers, edited live	Prompts versioned in the repository — every change diffable, reviewed, and revertible
Testing	Manual spot checks against the live API	Faked LLM responses in the test suite for CI, plus evaluation sets for real model behaviour

03 · Scope of work

What I build into Laravel apps

Six deliverables recur across nearly every engagement. Each one uses standard Laravel machinery, so your team can maintain it without me.

Queued LLM jobs	Every model call runs through Laravel queues with Horizon dashboards — retries, backoff, timeouts, and failure alerting come from framework primitives, not custom plumbing
Streamed responses	Server-sent events (SSE) carry tokens from a streamed OpenAI or Claude response straight to the browser — no WebSocket infrastructure required
Feature flags & fallbacks	AI features ship behind flags with graceful degradation — if the provider is down or a budget is hit, the app keeps working without the feature
Per-tenant token budgets	Token accounting per tenant and per feature, stored in Postgres, with hard caps and alerts before spend becomes a surprise
Prompt versioning	Prompts live in the repository next to the code that uses them; changes go through review like any other diff
Eval & regression tests	Fixture-based tests with faked responses keep CI fast; evaluation sets catch quality regressions when a prompt or model changes

04 · Fit

How does this fit an existing codebase?

An AI feature is not a reason to re-platform. I work inside the conventions your codebase already has: if you use action classes, the AI code uses action classes; if you deploy with Forge or Vapor, it deploys the same way; if you are on an older LTS release, the integration targets that release.

New code lands in a dedicated namespace and talks to the rest of the application through your existing services and events. There is no parallel Python stack to operate unless a workload genuinely demands one — and when it does, it sits behind a queue and an HTTP boundary, not inside your request path.

Rollout is incremental: features deploy dark, then enable per account behind flags.
Nothing in the existing test suite breaks — AI modules carry their own tests.
Your team reviews every pull request; there is no black-box drop of generated code.

05 · Process

Delivery process

Step 01 · Review

Codebase and architecture review

I read the application first: queue setup, tenancy model, deployment pipeline, and where the proposed AI features touch existing flows.

Step 02 · Plan

Integration plan

A short written plan covering model choice, prompt design, queue topology, cost ceilings, and — just as important — what stays untouched.

Step 03 · Build

Build behind flags

Queued jobs, SSE endpoints, token accounting, and prompts in the repo — deployed dark to production while the feature hardens.

Step 04 · Ship

Evaluate and roll out

Evaluation sets and fixture tests gate the flag flip; rollout proceeds tenant by tenant with cost and error dashboards watched throughout.

Step 05 · Handover

Documentation and handover

Your team gets the runbook, the Horizon and cost dashboards, and code written in the house style — so ownership transfers cleanly.

06 · FAQ

Laravel AI integration — common questions

Which Laravel versions do you work with?

Current releases and older LTS-era applications alike — version is rarely the blocker, since the integration relies on queues, jobs, and events that have been stable in the framework for years. Older apps sometimes need a queue driver upgrade or a Horizon install first, and that work is scoped in the plan. The delivery standard is the same one documented in the published case studies: production safeguards from day one, not a prototype to be hardened later.

Can you call OpenAI or Claude from PHP?

Yes — both providers work well from PHP, including streaming. OpenAI and Anthropic Claude are called over plain HTTP with streaming responses relayed through server-sent events, and the calls run inside queued jobs so a slow generation never blocks a web request. Where a project benefits from provider redundancy, I route between the two with a fallback policy per feature.

How do you keep API costs predictable?

Token accounting is built in from the first commit: every call logs its usage per feature and per tenant, and hard budgets stop spend at a ceiling you set. Cheaper models handle routine work, larger models are reserved for the calls that need them, and repeated inputs are cached. You see cost per feature on a dashboard, not on a surprise invoice.

Can you add AI to a legacy app without a rewrite?

Yes — that is the normal case, not the exception. AI features arrive as new modules behind feature flags, wired into the app through its existing services; the legacy code paths keep running unchanged. If parts of the codebase make integration risky, the plan names them and works around them rather than proposing a rebuild.

07 · Related

Related work & services

CS·02

08 · Next step

Add AI to your Laravel app — properly.

Hire on Upwork → Email Rohan