Laravel, AI and blocking IO

[FredrikPAC]

Hi!

I really love the Laravel ecosystem.

But the reality of long-running outgoing LLM HTTP calls makes Laravel a non-starter with regards to competing in the space of ai apps. Building an AI stack on a framework with blocking I/O is hard to defend.

I can't be the only one figuring this out, are there any plans from the Laravel team on this topic?

If not, i would urge the Laravel team to get involved in supporting or collaborating with the true-async project if there is a serious goal of being competitive as a framework for AI workflows and applications:
https://github.com/true-async

I have no affiliation with the project. I’ve just followed its progress and am impressed with its maintainer.

I genuinely believe it could become a cornerstone in securing Laravel’s competitive future.
I say it only because i believe in the work you've put into Laravel and want it to become successful. But as a user of it, PHPs blocking nature becomes undifensible in the AI era and with it hurting Laravels competiveness as a one stop shop.

Kindly Fredrik

[shaedrich]

If not, i would urge the Laravel team to get involved in supporting or collaborating with the true-async project if there is a serious goal of being competitive as a framework for AI workflows and applications: https://github.com/true-async

I have no affiliation with the project. I’ve just followed its progress and am impressed with its maintainer.

This feels like a quite random suggestion—I've never heard of it 🤔 Also, it's not yet stable (expected end of the year). What I've heard of are

• Fibers
• (Open) Swoole
• AMPHP
• ReactPHP

The relationship of true-async to the extensions is buried somewhere in the docs (true-async RFC 1, motivation). Apparently, it is a wrapper for Swoole (Swoole evidence) as well as an RFC for a native PHP implementation without extensions (true-async RFC 2).

Then there's also a third RFC that I didn't find in the docs.

[FredrikPAC]

None of the above solve worker threads being blocked though to my knowledge?

I'm aware they arent at the finishline yet.

To be clear, my query is twofold, whats the Laravel teams future plan/strategy when it comes to handling blocking io? Since this issue is much more prominent in a world with very long outgoing llm http reqs.

Secondly a proposal to support the work being done in the true async project in an official capacity. Since laravel is the biggest framework written in php i would assume there is atleast some ability to sway or facilitate the rfc process in php?
Maybe thats an incorrect assumption.

As i stated i merely represent a user that want to use laravel, but increasingly see it as a bad fit for many business cases which feels really sad. And if there isnt a clear strat for dealing with worker level blocking io i fear for its future competiveness.

Octane is great, but isnt enough here.

I can go in to more technical detail, but it feels like the gain with having the framework async seems pretty obvious?

If we defer looking at llm calls, just pure rps throughput would improve for realworld apps doing any kind of db calls.

Maybe you disagree with me, or dont see the same future. But i like Laravel so much that i can not stay silent on the topic.

[shaedrich]

I'm not aware of any Laravel core team members with voting powers in the RFC process. The best we get is probably some Symfony contributors 🤔

PHP wasn't built with asynchronicity in mind and so wasn't Laravel. To change that is a massive undertaking.

What Laravel does offer, is concurrency handling, deferring execution (events • HTTP batches • queued jobs), and after response processing (queued jobs • bus). If anything were to be implemented, it'd probably built upon that

[FredrikPAC]

Got it, and thank you for the response!

A community member made a larvel adapter for the alpha state extension of true async, i think it may be worth keeping an eye on to support more officially at a later stage:
https://github.com/YanGusik/laravel-spawn

As said, i dont want to come of as negative or non-supporting. I am super greatful for all your work and simply want to see it thrive in the future!

My hope was to spark a conversation.

[shaedrich]

A community member made a larvel adapter for the alpha state extension of true async, i think it may be worth keeping an eye on to support more officially at a later stage:
YanGusik/laravel-spawn

Now, that should quite intriguing!

Sorry for appearing reserved earlier on

[FredrikPAC]

No worries at all, Laravel is a huge project and i understand there is alot of noise moving thru channels. Thanks for hearing me out!

[YanGusik]

laravel-spawn - Laravel Spawn is an async runtime for Laravel powered by PHP TrueAsync. You can test it now
or use Laravel Octane + Swoole

[FredrikPAC]

Great work with this!
Im trying to push the laravel team to back it a little more formally hehe!

[shaedrich]

There also seems to be Hypervel, based on Swoole, though the docs pretty much just copy from here 🤨

[mikescott]

Laravel AI Agents can take a prompt via queue() which allows it to process in the background: https://laravel.com/docs/13.x/ai-sdk#queueing

I've built a very busy AI app using this approach with Laravel Horizon and have no problems. You can also also broadcast responses from agents that have finished with broadcastOnQueue() via Laravel Echo.

[YanGusik]

This means that if a user needs to process a queue as quickly as possible, they need to create 20+ workers per queue, which is about 3GB of RAM on the server. In fact, the user doesn't use all the server's resources; they use a hack with pcntl_fork() to solve I/O blocking problems, which isn't rational and raises the question of whether there's any point in using horizon to handle such tasks. I'm talking about highly loaded servers.

[FredrikPAC]

Fully agree.
The argument of putting it on the queue isnt really a solution. You are still wasting resources or doing some hacky worker vs avail hardware threads overloading.

The only solution if one wants to be truly competitive is an actual async solution.
What i mean is, why would someone choose laravel over next when building an ai app when its blocking model is unsuitable for doing long running, blocking ai calls?

We now have something at the horizon for that, no pun intended hehe, we just have to push for it to be officially supported so we can start using it!

[musaabhasan]

I would be careful about treating AI workloads as one single async problem. In practice, there are at least three different paths:

1. Interactive user requests where the browser needs an immediate answer or a streamed answer.
2. Long-running AI jobs such as document analysis, enrichment, batch classification, evaluation, or report generation.
3. Agentic workflows where the model can call tools, touch external systems, or perform multi-step work that needs auditability and retry control.

For the second and third categories, Laravel's existing strengths are still very relevant: queues, Horizon, failed job handling, rate limits, events, notifications, policies, audit logs, and database-backed workflow state. I would usually avoid tying those operations directly to the HTTP request lifecycle. Put the AI call behind a job, persist the workflow state, give the user progress/status, and make retries/idempotency explicit.

For truly interactive experiences, there are already viable patterns depending on the deployment model:

• Laravel queues for background execution and polling/status updates.
• Server-sent events or websocket updates for progress and partial output.
• Octane with Swoole or RoadRunner where long-lived workers and concurrency matter.
• A small specialized async service for the AI streaming edge, with Laravel remaining the system of record for users, permissions, billing, audit, and orchestration.

The bigger risk I see in AI applications is not only blocking I/O; it is unmanaged workflow authority. If an AI feature can access tools, data, or downstream systems, the application also needs approval gates, prompt/output logging, replayable job state, rate limiting, and clear failure handling. Laravel is actually strong in those areas.

So I agree that async support matters, and projects like TrueAsync are worth watching. But I would not say Laravel is a non-starter for AI applications. I would separate latency-sensitive streaming from auditable AI operations, then choose the runtime pattern accordingly. For many institutional and regulated AI use cases, that separation is healthier than pushing everything into the request thread.