You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I run the daemon on a Mac mini and reach it from three clients: the mini itself, a laptop, and my phone. While an agent is working I queue the next instruction, then walk away and pick the same agent up from whichever device I'm on next.
How I do it today
I queue on whatever client I happen to be sitting at, and then I have to remember which one that was and leave it open and awake until the turn ends. On the phone that means not switching apps. In practice I've started avoiding the queue and just waiting for the turn to finish so I can send normally, which defeats the point of queuing.
Where Paseo gets in the way
The queue belongs to the client, not to the agent. A message I queue on the Mac mini is invisible from the phone and the laptop, so from those devices the agent looks like it has nothing pending, and I can't edit or cancel it or see that I already asked for it. If I queue from the phone and then queue from the laptop, both land, in an order neither client can show me.
The same split causes two open bugs: the drain only runs while the client that holds the queue is connected and has fresh state, so the queue stalls when that client goes stale (#2693) or gets backgrounded on mobile (#3464). Closing the app loses whatever was queued.
What would the flow look like if it worked for me
The queue belongs to the agent. Every connected client shows the same pending list in the composer and can reorder, edit, cancel or send-now against it. When the turn ends the host sends the next one, whether or not any client is connected, and whether or not the one that queued it is still alive. Queue on the mini, close the lid, watch it go out from the phone.
Two earlier requests asked for the persistence half of this and were closed pointing at Discussions (#1291, #1546), so I'm opening the workflow version here rather than reopening those.
I'm happy to implement it if you want it and if you're happy with the direction. From reading the code the seams look like they're already there — the app funnels every queue mutation through one writer and the daemon already broadcasts agent snapshots to all clients — so the shape would be the host holding the queue on the agent and draining it at the turn boundary, gated on a feature flag so older daemons keep the local queue. The part I'd want your call on first is composer image attachments, since they're the only piece that lives in client-local storage today and would have to move to the host to be visible from another device.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
What am I trying to do
I run the daemon on a Mac mini and reach it from three clients: the mini itself, a laptop, and my phone. While an agent is working I queue the next instruction, then walk away and pick the same agent up from whichever device I'm on next.
How I do it today
I queue on whatever client I happen to be sitting at, and then I have to remember which one that was and leave it open and awake until the turn ends. On the phone that means not switching apps. In practice I've started avoiding the queue and just waiting for the turn to finish so I can send normally, which defeats the point of queuing.
Where Paseo gets in the way
The queue belongs to the client, not to the agent. A message I queue on the Mac mini is invisible from the phone and the laptop, so from those devices the agent looks like it has nothing pending, and I can't edit or cancel it or see that I already asked for it. If I queue from the phone and then queue from the laptop, both land, in an order neither client can show me.
The same split causes two open bugs: the drain only runs while the client that holds the queue is connected and has fresh state, so the queue stalls when that client goes stale (#2693) or gets backgrounded on mobile (#3464). Closing the app loses whatever was queued.
What would the flow look like if it worked for me
The queue belongs to the agent. Every connected client shows the same pending list in the composer and can reorder, edit, cancel or send-now against it. When the turn ends the host sends the next one, whether or not any client is connected, and whether or not the one that queued it is still alive. Queue on the mini, close the lid, watch it go out from the phone.
Two earlier requests asked for the persistence half of this and were closed pointing at Discussions (#1291, #1546), so I'm opening the workflow version here rather than reopening those.
I'm happy to implement it if you want it and if you're happy with the direction. From reading the code the seams look like they're already there — the app funnels every queue mutation through one writer and the daemon already broadcasts agent snapshots to all clients — so the shape would be the host holding the queue on the agent and draining it at the turn boundary, gated on a feature flag so older daemons keep the local queue. The part I'd want your call on first is composer image attachments, since they're the only piece that lives in client-local storage today and would have to move to the host to be visible from another device.
All reactions