Agent::stream() (Anthropic) yields only StreamEnd under PHP-FPM (works under CLI; prompt() works on both)

[ecsol]

Summary

Agent::stream() (Anthropic provider) yields no streaming events when the request runs under the PHP-FPM SAPI — the iterator produces only a single trailing StreamEnd, so the response is empty. The exact same agent works perfectly under the CLI / PHPUnit SAPI, and Agent::prompt() (non-streaming) works under both SAPIs.

This makes streaming chat endpoints return an empty body in production (FPM) while passing every test (CLI), which is very hard to diagnose.

Environment

• laravel/ai: 0.7.2
• laravel/mcp: 0.7.0
• Laravel: 13.x
• PHP: 8.4.22
• Provider: anthropic (driver anthropic, model claude-sonnet-4-6)
• Server: nginx + PHP-FPM (Laravel Herd)

What I observed

A conversational agent with tools:

#[Provider(Lab::Anthropic)]
#[Model('claude-sonnet-4-6')]
#[MaxSteps(8)]
class AssistantAgent implements Agent, Conversational, HasTools { use Promptable; /* … */ }

Iterating the stream and collecting the event types:

$events = [];
foreach ((new AssistantAgent)->stream('Liệt kê 2 shipment') as $event) {
    $events[] = class_basename($event);
}
// CLI (artisan tinker / PHPUnit):  ['StreamStart', 'ToolCall', 'ToolResult', /* many text deltas */, 'StreamEnd']
// PHP-FPM (same code, web request): ['StreamEnd']   ← only one event, no content

Correspondingly, returning it from a route:

return (new AssistantAgent)->stream($prompt)->usingVercelDataProtocol();

emits a full SSE stream under CLI, but under FPM emits only:

data: {"type":"finish"}

data: [DONE]

(no start, no text-start, no text-delta, no tool events).

Key facts that narrow it down

• Agent::prompt() (non-streaming) returns the full, correct answer under PHP-FPM — so the provider config, API key, network, SSL/CA bundle, tools, and model id are all fine under FPM.
• Only the streaming path (stream() → streamText with ['stream' => true]) is affected, and only under FPM.
• Under CLI/PHPUnit the streaming path returns all events as expected.
• No exception is thrown or logged; the stream simply yields nothing but the terminal StreamEnd.

This points at the Anthropic streaming transport / SSE reading in Gateway/Anthropic/Concerns/HandlesTextStreaming.php (the Http::…->withOptions(['stream' => true]) body read via parseServerSentEvents()) behaving differently — or being drained empty — under the FPM SAPI.

Reproduction

1. App on PHP-FPM (e.g. Laravel Herd) with ANTHROPIC_API_KEY set.
2. Define any agent (with or without tools) using the Anthropic provider.
3. Hit a web route that iterates ->stream(...) (or returns ->usingVercelDataProtocol()), authenticated via the browser/FPM.
4. Observe only StreamEnd / a finish-only SSE body.
5. Swap the same call to ->prompt(...) → full correct response under FPM.

Expected

Agent::stream() should yield the same StreamStart → text/tool deltas → StreamEnd sequence under PHP-FPM as it does under the CLI/PHPUnit SAPI.

Workaround in use

Falling back to ->prompt() and re-emitting the result as the Vercel UI-message-stream protocol manually. Works reliably under FPM but loses true token-by-token streaming.

Happy to provide more details or test a fix.

[ecsol]

Root cause isolated 🔎

I traced this down. It is not the SSE parser, the model, the API key, network, or the timeout — it's that under PHP-FPM the Http facade returns a streaming response whose body has already been fully consumed, so ParsesServerSentEvents::parseServerSentEvents() sees eof() immediately and yields nothing.

Evidence (same machine, same PHP-FPM request)

Illuminate\Support\Facades\Http with ['stream' => true] (what the gateways use):

$resp = Http::withOptions(['stream' => true])
    ->withHeaders([...])->post('https://api.anthropic.com/v1/messages', $body);

$b = $resp->toPsrResponse()->getBody();
// eof()       => true
// tell()      => 1304        ← cursor already at the END (body fully read)
// isSeekable()=> false
// read(80)    => ''          ← nothing left to read

A raw GuzzleHttp\Client doing the same POST with stream => true under the same PHP-FPM request:

$resp = (new GuzzleHttp\Client)->post('https://api.anthropic.com/v1/messages', [
    'stream' => true, 'headers' => [...], 'json' => $body,
]);
$b = $resp->getBody();
// eof()    => false
// tell()   => 0
// read(60) => "event: message_start\ndata: {\"type\":\"message_start\"...}"   ← streams fine ✅

Under the CLI / PHPUnit SAPI both work; only the Http facade under PHP-FPM drains the body.

Ruled out

• Telescope — not installed in the repro.
• timeout — raw Guzzle with 'timeout' => 60 still streams correctly.
• retry middleware — none configured on the gateway client.
• app/vendor ResponseReceived listeners — none.

So the buffering happens inside Laravel's HTTP-client wrapper for the streaming case under FPM, while a plain Guzzle client streams correctly.

Suggested fix

Issue the SSE streaming request through a raw GuzzleHttp\Client (or otherwise obtain the un-consumed PSR stream) in the gateway client layer, instead of the Http facade — verified to stream under PHP-FPM in my testing.

Environment: laravel/ai 0.7.2, Laravel 13, PHP 8.4.22 (FPM), provider anthropic, served by nginx + PHP-FPM (Laravel Herd). Happy to test a patch.

[ecsol]

Confirmed the exact mechanism + a working (but test-breaking) fix

I pinned it down to Laravel's HTTP-client handler stack. Bypassing it with a fresh Guzzle client makes streaming work under PHP-FPM:

// src/Gateway/Anthropic/Concerns/CreatesAnthropicClient.php
return Http::baseUrl($this->baseUrl($provider))
    ->withHeaders($headers)
    ->timeout($timeout ?? 60)
    ->setClient(new \GuzzleHttp\Client)   // ← streams correctly under PHP-FPM
    ->throw();

Verified under PHP-FPM: with setClient(new GuzzleHttp\Client) the streamed body arrives un-consumed (eof() === false, tell() === 0, read() returns event: message_start\ndata: …). Without it, the same request returns a fully-consumed, non-seekable body (eof() === true, tell() === 1304).

So the consumption happens inside the middleware that PendingRequest::buildHandlerStack() pushes (beforeSending / recorder / stub), which setClient() skips.

…but setClient() breaks Http::fake()

The catch: setClient() also bypasses the stub handler, so Http::fake() no longer intercepts. Running the suite with the change above:

tests/Feature/Providers/Anthropic/StreamingTest.php
Tests: 12 failed   (they hit the network instead of the fakes)

There doesn't seem to be a public API to ask "is Http currently faking?" (Factory::$stubCallbacks / $recording are protected), so a clean setClient()-only-when-not-faking guard isn't straightforward from package code.

This feels like it needs a maintainer-side decision — e.g. a faking-aware streaming client, a dedicated non-buffering transport for SSE, or a fix at the framework's HTTP-client level so ['stream' => true] keeps the body un-consumed through the handler stack under FPM. Happy to help test whichever direction you prefer.