Solidway v0.1.0 is released under AGPL-3.0; source and releases are on GitHub. This documentation is being rewritten against the release — pages outside Quick start and Reference still describe planned behaviour. The current reference lives in docs/getting-started.md and docs/architecture.md in the repository.
Streaming
How server-sent events pass through, when failover is still possible, and how usage is counted.
Streaming responses are forwarded incrementally. The gateway does not buffer a stream in order to inspect it.
What is forwarded
Each chunk is written to the client as it arrives from the provider. Frame boundaries and
their contents are unchanged, so a client that parses data: lines sees exactly what the
provider emitted. This is what keeps incremental rendering and tool-call accumulation
working.
Failover stops at the first byte
Failover happens before any response byte reaches the client. Once the upstream has
returned 2xx headers and the gateway starts writing the body, the response is committed:
- an error event inside an otherwise successful stream is delivered to the client, not retried against another account;
- a mid-stream connection drop ends the client’s stream; the request is recorded as a stream error.
This is the price of not splicing two upstream responses together, and it is why the gateway never rewrites or reorders frames.
How usage is counted
Token usage is read from the stream as it passes — from the usage fields the provider
emits (message_delta, response.completed, and similar), and from response headers where
the provider reports them. Counting never changes the bytes sent to the client. If a stream
is interrupted before the provider reports usage, the request is recorded with whatever was
observed and marked accordingly.
Client disconnects
If the client disconnects, the upstream request is cancelled. A partially consumed stream is never recorded as a success.