[Feature Request] Chat Message Queuing / Queue messages while AI is thinking

[leonessawebb-rgb]

Hi everyone! I'm fairly new to GitHub, so I'm not entirely sure if this is the right place or the right way to propose a feature, but I would really love to see this convenient addition in Odysseus.

Is your feature request related to a problem? Please describe.
Currently, when a local model is generating a response or an agent is running a complex loop (like Deep Research or multi-step tool calling), the input text box is either disabled or sending another message is blocked. Since local inference and agent workflows can take some time, users often have to wait for the entire generation to finish before they can type or send their next thought. If a user thinks of a relevant follow-up or extra context in the middle of the stream, they have to wait or save it in a separate notepad.

Describe the solution you'd like
I would love to see a Message Queuing System implemented in the chat interface:

• While the AI is actively generating, the input box remains active. The user can type a follow-up message and hit "Send".
• Instead of blocking the UI or interrupting the current generation, this message is added to a visual queue (e.g., appearing in the chat history with a "Pending" or "Queued" status badge).
• As soon as the active AI response finishes, the engine automatically processes the next message in the queue sequentially, without requiring the user to wait and manually click send later.

Describe alternatives you've considered
Manually holding the text in the clipboard or opening multiple parallel chat sessions, which breaks the seamless cognitive flow of a local workspace.

[Pleniluni0]

+1

[SirThinksAl0t]

+1

[Plaer1]

Hey friends; drop screenshots of que ui/features you'd like. I've built a few ai chat bridges at this point and I'm assuming:
edit/delete/reorder/merge||link; if anyone can think of any other stuff they'd like out of a que let me know. also if you have any screenshots of something you've been using with a que please post them in a reply to this post. I'm gonna try to get a que patch ready this week.

[leonessawebb-rgb]

i was thinking something like open web ui? this is the docker ai reference witch is similar

[entitycs]

@leonessawebb-rgb

[entitycs]

Wellp, pour one out for my free Antigravity tokens

Auto-submits when current stream ends

[Plaer1]

Imagine finding out the source of the bug keeping you from hooking up the queue list to the queued message span element... was the width of the screen. 🫠

you get it working brother? I'd like to snag the patch for my setup :^) <3

[entitycs]

@Plaer1

I just about 'gave up' on hooking into the existing vanilla JS "chat / message submit" flow, and started writing a solution in svelte...

...but that first screenshot is essentially native behavior already in the app... !?

Are you using mobile, or are you on desktop?

The "existing feature" - which never worked for me or presented itself as a feature for me until I disabled one or two of the many event listeners for that "message box" - seems to be aimed at mobile users.

I'm still piecing it out, but I should be able to at least share what I concretely learn about the native feature flow as I rewrite it as something more manageable for me.

[entitycs]

Pulling back into a clone of 'dev' to diff on, I think the native queue was "fixed" in this PR from 5 days ago:

https://github.com/search?q=repo%3Apewdiepie-archdaemon%2Fodysseus+265f0911d5298d6c397bda046fa7227e8f5be5ec&type=pullrequests

Can someone confirm this PR addresses the original post? It seems to have some bugs - eg., deleted queued message can show back up on a refresh despite getting the toast confirmation that they were already deleted.

My local list-queue implementation is only an "update/improvement" to what seems to work natively now, if you consider that it enables editing for the queued messages.

So, back to the follow-ups since the OP, do we want to go with slapping an edit + delete option onto the existing chat-history appended message from the native solution - as opposed to using the list queue pattern as per OpenWebUI?

edit:

caveat: Using the 'enter' key, and using the submit button trigger two different execution paths - they keydown event being better attached to queueing.

[Plaer1]

Good catch! I'll just rebase my build to the latest dev and then hack on what they are building naively, that's good enough for me at least.

[entitycs]

@Plaer1

Lucky catch. Helped me discover a difftool configuration to help me update files that may have been incorrectly rebased.

I wonder what other features slip by.

Maybe it's time for some 'Releases' or at least 'dev-Releases' that can help us track what has been added / should be working / etc.

---

It's hard to know just through the code, because there are lots of misleading half-implementations, like this:

app.js contains

import chatModule from './chat.js';
//...
chatModule.queueStreamingComposerRequest(); //  undefined (but referenced 6 times to route logic)

chat.js contains

export function queueStreamingComposerRequest() {
    if (!isStreaming) return false;
    const queuedInput = uiModule.el('message');
    const queuedText = (queuedInput && queuedInput.value || '').trim();
    if (!queuedText) return false;
    if (fileHandlerModule.getPendingCount && fileHandlerModule.getPendingCount()) {
      try { uiModule.showError && uiModule.showError('Finish the current response before queueing messages with attachments.'); } catch (_) {}
      return true;
    }
    if (_queueAgentRequest(queuedText)) {
      queuedInput.value = '';
      queuedInput.dispatchEvent(new Event('input', { bubbles: true }));
      if (uiModule.autoResize) uiModule.autoResize(queuedInput);
      try { window._updateSendBtnIcon && window._updateSendBtnIcon(); } catch (_) {}
    }
    return true;
  }

but since it doesn't include queueStreamingComposerRequest in the default export below

  // Public API
  const chatModule = {
    init,
    initListeners,
    openAttachment,
    addMessage: chatRenderer.addMessage,
    displayMetrics: chatRenderer.displayMetrics,
    handleChatSubmit,
    abortCurrentRequest,
    detachCurrentStream,
    checkBackgroundStream,
    resumeStream,
    hideWelcomeScreen: chatRenderer.hideWelcomeScreen,
    showWelcomeScreen: chatRenderer.showWelcomeScreen,
    checkPendingResearch,
    getImageCost: getImageCost,
    setDisplayOverride,
    setHideUserBubble,
    setPendingContinue,
    regenerateFrom,
    forkFrom,
    editUserMessage,
    editAIMessage,
    resendUserMessage,
    deleteMessage,
    rewriteWith,
    continueFrom,
    _appendViewReportLink,
    hasActiveStream,
  };

export default chatModule;

then in app.js, in order for that logic to work, the chat module import should be

import * as chatModule from '$lib/legacy/chat.js';

These are the kinds of things that are inspiring me to continue beyond just a POC for a frameworked version of the app

[entitycs]

Memo:

Just noticed... the time displays on the message, but not the date, for when the message wasn't posted on the current day. Wonder if there's a PR for that I can pull from