[devnull3]

> the model has to re-run the generation, and the client has to start receiving tokens from scratch again.

I don't understand. The payload can be designed to have sequence number. In case of reconnect, send the last known sequence number. Sounds like a application level protocol problem and not transport. Am I missing something?

The pub/sub mentioned in the article essentially does the same thing.

[petcat]

The blog author is confusing SSE the protocol itself, with how the application is typically implemented. SSE is great and can trivially be implemented in a way that allows history, catch-up, and resuming. The "Pub/Sub" mentioned at the end of the exact application of SSE that the author wants.

[embedding-shape]

> The blog author is confusing SSE the protocol itself, with how the application is typically implemented

Yeah, pretty common misunderstand among us self-taught developers who at one point never came across things like the OSI model (https://en.wikipedia.org/wiki/OSI_model) or similar before, that we confuse what layer things actually happens at.

[verdverm]

Exactly, I use ADK (https://google.github.io/adk-docs/runtime/) and it handles all that bookkeeping for me. If my client disconnects, the engine continues to run until the turn is up, recording all events.

We need more frameworks like ADK that handle the bookkeeping and give us great abstractions for building agentic systems.

[medbrane]

Indeed, the reconnect behavior is described in the protocol and the server will simply resume from the requested sequence id.