Streaming.

​

One flag, three dialects

curl -N https://api.sideren.io/v1/chat/completions \
  -H "authorization: Bearer $SIDEREN_API_KEY" \
  -H "content-type: application/json" \
  -d '{"model":"@sdn/gpt-oss-120b","stream":true,"messages":[{"role":"user","content":"Hi"}]}'

​

SDK examples

stream = client.chat.completions.create(
    model="@sdn/gpt-oss-120b",
    messages=[{"role": "user", "content": "Write a haiku."}],
    stream=True,
)
for chunk in stream:
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)

const stream = await client.chat.completions.create({
  model: "@sdn/gpt-oss-120b",
  messages: [{ role: "user", content: "Write a haiku." }],
  stream: true,
});
for await (const chunk of stream) {
  process.stdout.write(chunk.choices[0]?.delta?.content ?? "");
}

with client.messages.stream(
    model="@sdn/glm-5.3",
    max_tokens=512,
    messages=[{"role": "user", "content": "Write a haiku."}],
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

​

Usage on streams

{ "stream": true, "stream_options": { "include_usage": true } }

​

Failure semantics

• A stream that cannot complete ends with a protocol-shaped error event — never a silent empty 200. On the OpenAI dialect that means an in-band error frame and no data: [DONE], which is sent only on clean completion; on Messages the error event replaces message_stop. Your client always learns the turn failed.
• Once output has started, Sideren never replays or splices the stream — the model may already have emitted tool calls your client acted on. Whether to send the turn again is your client’s decision; if you do, retry the whole request with backoff (Errors).
• While a request waits for capacity before its first token, the stream carries SSE keepalive comments (every 15 seconds) so idle timeouts don’t fire. Clients ignore them.
• Long gaps between tokens are normal on reasoning models — they spend time thinking before emitting text. Don’t set aggressive idle timeouts on the read side.