streaming capability, so UIs can paint reasoning, tool progress, and the final answer as they arrive.
accepted ack from the final answer.
Quick Start
1
Open a streaming client
2
Print each event type
Event Vocabulary
Each streaming event maps to anEventType in praisonaiagents.gateway.protocols and is advertised in hello_ok.features["events"] when the client negotiates streaming.
reasoning_stream, tool_progress_stream, and stream_error are additive. Existing token_stream consumers keep working unchanged — gate the new events on client.supports_event(...).Response Frame States
Every WebSocket response frame carries astatus: a provisional accepted ack arrives first, then the real answer as final with a structured outcome.
User Interaction Flow
A streaming UI paints each event as it arrives — reasoning bubble, then a tool progress chip, then the final answer.Common Patterns
- Reasoning Inline with Answer
- Tool Progress Chip
Best Practices
Gate rendering on client.supports_event(...)
Gate rendering on client.supports_event(...)
Wrap new-event rendering in
client.supports_event("reasoning_stream") and client.supports_event("tool_progress_stream") so legacy gateways — which never advertise these events — degrade silently instead of breaking.Treat stream_error as a soft signal
Treat stream_error as a soft signal
A
stream_error frame does not end the run. The gateway may still deliver a final response with outcome.status="error". Surface the error but keep listening until stream_end / final.Never assume type: response means done
Never assume type: response means done
Both the provisional ack and the real answer share
type: "response". Branch on status: show a spinner on accepted, render only on final, and read outcome.status for the completion state.Related
Gateway Handshake Protocol
Negotiate
streaming and read the advertised event setGateway Client
Reconnecting client that streams these events
Frame Codec
Validate inbound frames at the WebSocket boundary
Session Protocol
How sessions carry these events

