Streaming | Dagnam.AI Docs

Short-lived stream tokens, the event streams available, event names, and reconnecting.

Streaming Training, deployment, inference and account updates are all available as server sent event SSE streams. Every stream is read the same way: mint a short-lived token, then open the stream with it. How stream tokens work A browser EventSource cannot send an Authorization header, so every stream is opened with a token instead of your personal API key or session: .", / The token is short-lived, so mint a fresh one whenever you reconnect. The dagnam SDK does this for you. Account events are the one exception to the first step: their token needs a web session. Training events The stream opens with connected , then sends status , progress , metric , log , log batch several log lines at once , checkpoint , system and heartbeat events. A run reported from your own hardware can also send error events, and warning reports that system metrics are temporarily unavailable. When events arrive faster than the stream sends them, it holds back metric , progress , log , system and checkpoint events and sends them together in a batch event, grouped by type. A client that listens only for metric misses the metrics that arrive inside a batch . When a running job sends complete or failed which carries the job's error , the stream follows it with stream end and closes. Cancelling a job sends nothing on this stream, and a few failures arrive only as a status event, so read the job's status if the stream stays open after the job stops. Opened on a job that has already finished, the stream sends connected , a status event with the final status, job error with the job's error if it failed, and stream end . On a live stream, job error means the stream itself failed. See Training monitor /docs/training/monitor and dagnam stream in the CLI reference /docs/dag-lib/cli . Deployment events The stream opens with connected , then sends deployment progress , deployment status and heartbeat events. It ends with stream end once the deployment reaches a terminal state, or with error if the stream itself fails. See Managing a deployment /docs/deployments/manage . Inference streaming A chat deployment streams its response token by token: /predict/stream/session with your input; the response carries a session id and a stream token together.", "GET /api/v1/inference/ /predict/stream/ ?token= .", / Starting a stream takes your personal API key or web session, not the deployment key. The stream sends token , complete and error events. Only chat deployments stream: text classification, embedding, tabular and image deployments answer 400 for a stream request. See Calling a deployment /docs/deployments/inference . Account events Carries the same live updates the web app shows: training job and deployment status changes across your account. Minting this token needs a web session; a personal API key cannot, so this stream is for the browser app. Reconnecting Only the training stream resumes: send the id of the last event you saw in the Last-Event-ID header, and it replays the recent events you missed before going live again. The other streams restart live on reconnect, so read the current state the deployment, or your jobs again after reconnecting. The SDK's stream training reconnects automatically, re-minting a token as needed, up to a configurable number of attempts.