Nanobot
Nanobot contributor requests durable queues and conversation-specific drafts
Three September 24 Nanobot requests describe everyday friction around long-running chats: follow-ups need a server-side queue, drafts should survive conversation switching, and streaming replies need visible speed feedback. They are proposals, not shipped features, and distinguish durable accepted messages from unsent browser-local text.
A small cluster of Nanobot feature requests focuses on the time between asking an agent to work and getting a usable response. The central request asks for a server-owned waiting room for follow-up messages while a turn is busy. Two adjacent requests ask to retain unsent drafts per conversation and expose generation speed. Together they describe a concrete interaction problem: users should be able to leave, switch context or inspect progress without confusing an accepted task with text that exists only in a tab.
The facts
- Issue #5909 was opened September 24 and requests a queue owned by the API server while a session has an active turn. - The requested queue would drain in order after the current turn and survive a client disconnect; canceling individual queued messages is optional scope. - Its author distinguishes the existing pendingMessageSends acknowledgement tracking from a persisted, user-visible queue. - Issue #5910 requests a separate saved draft for each conversation, with browser-local storage suggested as sufficient. - Issue #5908 asks for live tokens-per-second feedback during streaming and a total token count on completion. - All three inspected items are open requests, not merged implementations or release announcements.
Why it matters
The useful distinction is ownership. Once a server accepts a message for later execution, a user reasonably expects it to outlive a laptop closing. A draft the user has not submitted has a different lifecycle and should not quietly become an executable task. Combining those states into one spinner or input box makes it hard to know whether anything will happen. That is an operator concern as much as a cosmetic one: sending the same request again to compensate for uncertainty could create duplicate work if the first message was actually retained.
Current
The current inspected release baseline is Nanobot v0.3.5. These September 24 reports do not establish that it or development mainline has gained the requested features. The claims about disappearing drafts and busy-message behavior are the reporter's observations, not a reproduced test here. The three requests are treated as one interaction-design story rather than inflated into separate feature launches; they come from a narrow source cluster, not a measured survey of the user base.
Evidence
Primary: HKUDS/nanobot issue #5909 (https://github.com/HKUDS/nanobot/issues/5909). Supporting context: HKUDS/nanobot issue #5910 (https://github.com/HKUDS/nanobot/issues/5910); HKUDS/nanobot issue #5908 (https://github.com/HKUDS/nanobot/issues/5908). Source pages and available diffs were inspected; test and live-account results remain attributed to their authors, not independently repeated measurements.
Operator take
For an implementation review, require visibly different states for an unsent draft, an acknowledged queued message and an executing turn. Test tab closure after acknowledgement, reconnection before completion and cancellation of one queued item without discarding its neighbors. Keep draft persistence scoped to the correct conversation. Treat a streaming-speed display as diagnostic feedback rather than proof that the agent is making task progress: fast output can still be wrong, while tool work may proceed without producing model tokens. Those are proposed acceptance checks, not results reported by these issues.
Caveat
No durable queue, draft persistence or tokens-per-second display is claimed available. The cluster is evidence of specific user needs, not adoption volume or a confirmed general outage. The inspected reports do not specify a complete restart-durability or duplicate-execution contract, which implementation would still need to settle.
No durable queue, draft persistence or tokens-per-second display is claimed available. The cluster is evidence of specific user needs, not adoption volume or a confirmed general outage. The inspected reports do not specify a complete restart-durability or duplicate-execution contract, which implementation would still need to settle.