https://docs.all-hands.dev/ logo
Join Slack
Powered by
Just a quick heads-up, <@U06QFDJ1QQ2> <@U06PEF04LE...
# proj-agent
c
Just a quick heads-up, @wooden-umbrella-84098 @limited-student-10747 We're about to change the WS interface to stream a wrapper for Events and FleetingThingsTM (a better handling for LLM streaming). Please do tell if you have strong feelings about this: comment 😅 🙏 Protocol:
Copy code
{
  "kind": "durable",
  "seq": 42,
  "event": { "...the normal Event..." }
}
and
Copy code
{
  "kind": "delta",
  "item_id": "...",
  "order": 3,
  "content": "hello"
}
w
Oh I do not want to ship a breaking change to the websocket 😅
I would rather open a second websocket for streaming events
I believe we have folks depending on the websocket right now
I certainly do
c
I think it’s a different endpoint cc @modern-fireman-99755
w
😌
so long as we maintain backward compatibility I'm happy
but IMO we shouldn't be sending both over the same websocket
opening a second websocket seems like a better solution to me
claude is also recommending 
SSE or plain HTTP streaming
c
I don’t know; LLM streaming definitely brought this to a major point, but TBH to my mind, it wasn’t the only problem with a WS for Events: • we also have conversation status updates every step, which are Events so saved/loaded in file stores, even though n-1 for n steps are useless, outdated
(I mean, maybe those wouldn’t be persistent Events, if the protocol allowed to send them nicely or something)
Should we live with them on long-running conversations? They don’t bother now, but on 100k steps they’re idk, 100k perhaps
But just for clarity, I don’t object to a second WS if we can do it
w
I trust y'all to figure out the right solution here 🙂 so long as we don't make breaking changes
ty 1
Open in Slack
PreviousNext
Powered by