Send queued messages together: a "Steer all" action and a batched queue mode #15815

Guria · 2026-10-05T00:44:21Z

Guria
Oct 5, 2026

A thread's queue drains one message per turn (#6885), and thread.steerQueuedMessage steers only the oldest queued message. That's fine for unrelated follow-ups. When the queued messages belong together, the agent handles them separately: it re-plans after each one, and it can act on the first before it sees a later one that changes the picture.

I hit this in two ways:

As the operator. During a long turn I queue notes as they come to me, for example one message per review point while I read the diff. Four notes become four turns.
With threads working together. Worker threads report to a coordinating thread with t3_thread_send. While the coordinator is busy, each report lands in its queue (mode: "queue", or "auto" before the turn is steerable), and again each one gets its own turn.

I'd like two ways to deliver the queue together. Both serve both cases.

1. "Steer all" action

Joins every queued message into one message and steers it into the running turn. The queue is empty afterwards.

Operator: the agent heads the wrong way while I have three corrections queued. Today I either promote them one by one, which gives three steers each landing mid-reasoning, or I copy them into the composer by hand. "Steer all" is one action.
Collaborating threads: I see several worker reports waiting in the coordinator's queue and want it to use them now, in a single update. The coordinating agent could do the same itself.

Places it would go: a button by the queue list, a keybinding next to thread.steerQueuedMessage, the mobile queue sheet, and an MCP tool alongside t3_queue_promote_to_steer. Available only when the provider supports steering, like the existing steer.

2. Batched queue mode

When a turn ends, the next turn gets everything queued so far as one message instead of only the first.

Operator: I keep writing review points during the turn without merging them by hand, and the agent gets them in one turn where it can weigh them against each other. [Feature]: Quote part of an assistant message and batch replies into one turn #6974 makes the same argument for quoted replies: "One turn where the agent sees all four objections together beats four turns where it re-plans after each one."
Collaborating threads: the coordinator waits on workers that finish at different times. Whatever arrived during its current turn reaches it in one next turn.

This has to be a server-side, per-thread option, not part of Follow-up behavior. That setting applies per client and decides how my own messages enter the queue. Batching decides how the queue leaves, whoever filled it, and messages from other threads never go through a client. Per-thread fits because only some threads need it. It could also be settable at t3_thread_launch, so a coordinator starts with it on.

Open questions

Join format: plain separator, or a header per message showing its source (me or a sending thread)? Attachments merged into the combined message?
Per-thread setting, environment default, or both?
Is the mode worth adding, or are "Steer all" plus a "send all as next turn" queue action enough?

Related: #6885, #11912, #6974.

Drafted with AI assistance: Claude Opus 5.5 (claude-opus-5-5) via Claude Code in T3 Code.

Dwite · 2026-10-05T16:10:03Z

Dwite
Oct 5, 2026

I have the same problem as the operator: several queued notes that are one request.

A smaller option that may cover both of your proposals: a Merge all action in the header of the queue list. It joins all queued messages into one queued message, in queue order, with their attachments. The result stays in the queue as a normal message. Nothing is sent.

The existing actions then do the rest:

Merge, then Steer: the same result as "Steer all".
Merge, then wait: everything goes as one next turn.
Merge, then the pencil: I can clean up the text first.

This needs no new mode and no new setting. I think it answers your third open question.

It does not cover the automatic case for threads that work together, where nobody presses a button. An MCP tool next to t3_queue_edit could help there: the coordinator merges its own queue before the next turn.

0 replies

shcpj · 2026-10-05T23:59:16Z

shcpj
Oct 5, 2026

Adding a concrete user experience from Windows desktop with a long-running Codex coordinator and a separate Claude thread.

I had already set Follow-up behavior to Steer, but seven status/coordination messages from the other thread accumulated in the coordinator's queue while it continued working. Inspecting the sender calls showed explicit t3_thread_send calls with mode: "queue"; the tool reported delivery: "queued". These were coordination updates needed during the current turn, not independent future tasks.

The workaround was to read them with t3_queue_list / t3_queue_read, then promote all seven individually using t3_queue_promote_to_steer. The queue was empty afterward. We also instructed the sender to use auto/steer going forward.

This supports the proposed Steer all action. An additional useful control would be a clearly labeled, server-side per-thread preference for incoming agent/thread updates: inherit the user's Steer preference, or choose a separate delivery policy. It should be clear whether explicit sender queue mode is respected or overridden, and preserve intentional future-task queueing. If such a control already exists, making it discoverable beside Follow-up behavior would help.

The confusing part is that choosing Steer appears to solve this as a user, but messages sent by other agents take a separate path. This report does not establish a bug in automatic delegate_task completion delivery; the verified case is explicit cross-thread sends.

Posted with the user's authorization by their coding assistant. No private project data or logs attached.

0 replies

maciekczech · 2026-10-13T11:19:35Z

maciekczech
Oct 13, 2026

🤖 Opus 5.5 via Claude Code, on Maciek's behalf

I hit the same thing as the operator, and built the "Merge all" variant from the comment above: a Squash button in the queue header joins every queued message into one queued message, in queue order with attachments, open for editing before it is saved. Nothing is sent, so Steer, Edit and Reorder work on the result as on any queued message.

My reason for wanting one message rather than several steers: in my experience steering tends to lose track, and after three steers the agent gets lost in the main thread. One combined message gets better results.

Squash: feat: squash queued messages into one #19020 (web, desktop, mobile, and t3_queue_squash for agents)
Unsquash, as a follow-up that puts the originals back: feat: unsquash a squashed queued message #19021

Neither has maintainer approval of the direction, which the contributing guide asks for. Maintainers: is "squash into one queued message" a direction you would take? I am happy to cut scope (for example squash only, or web only) if that helps.

0 replies

aneym · 2026-10-27T18:16:01Z

aneym
Oct 27, 2026

I built proposal 2, the batched queue mode, as a server setting in our fork and have been running it.

What it does. Settings > Chat > "Send queued messages together", next to Follow-up behavior. When a turn ends, everything queued on the thread starts as one next turn. The provider gets one message that opens with "These N messages were queued separately while you were working. They are listed in the order they were sent, with their senders. Handle each one accordingly.", followed by each message labeled with its number and sender. The timeline still shows every message on its own, all under that one turn.

Details:

These still get their own turn: notifications, delegated task completions, scheduled tasks, /compact, /goal, and messages queued for a different provider or model. Batching stops at the first of these, which then runs next on its own, so nothing gets stuck.
Sending one queued message now from the queue list still sends just that one.
After Stop, the queue stays held until Resume or until a later turn completes. A completed turn releases every held message, and they go out together.
In our fork, messages queued when the server shuts down for a restart run after it comes back. That part is not in the PR, because upstream holds don't record why a message was held.
Steer is unchanged.
At most 20 messages go into one turn.

What I ran. On a Linux server running our fork, I started a turn that ran a 2 minute command and queued three notes while it worked. With Claude Haiku 5.5 and with Codex on GPT-6 Astra, all three ran as one next turn, and that turn's one reply answered each note. The wrapper text showed up in both providers' session logs. With the setting off, the same script gave three turns, one per note.

Not checked yet: attachments on folded messages, a full batch of 20, and mobile. The setting lives on the server, and mobile has no settings row for it.

On Squash vs this: Squash works when someone is watching the queue. In the coordinator case described above, nobody is watching, so the batch has to happen when the turn ends. I think both are worth having.

Questions for maintainers:

Server-wide or per thread? The original post asks for per thread. Ours is server-wide because the queue drains on the server, and per thread would need a thread-level override.
Default: our build turns it on. The PR ships it off.

PR with the upstream version (off by default): #26072. I opened it so this discussion has working code to look at. It is not approved, and I'll change or close it based on what's decided here.

Written with Claude Opus 5.5 in Claude Code.

0 replies

Krarilotus · 2026-10-30T12:23:40Z

Krarilotus
Oct 30, 2026

Problem

This adds an unattended coordination case to #15815. A coordinating thread needs to consider the reports already waiting for it together. Processing each report in a separate turn can mean acting before seeing another report that changes the decision.

The reported sequence was:

A coordinating turn remained marked running, with no visible activity, for about two hours.
Six child-result and scheduled check-up items waited behind it.
Ordinary queued messages could be promoted into the active turn, but automatic completion notices returned: Automatic completion deliveries cannot be promoted to Steer.

On two other occasions, a child's final result was found through task_status, with no notice or queue item observed. Those observations do not establish lost delivery: reading a finished result acknowledges it, and can remove its queued notice. The state before that read was not captured.

Environment: Windows, T3 Code (Beta). The installed desktop executable reports 0.1.5 at drafting time; the exact incident and server versions were not established. These are field observations, not a deterministic reproduction. Token savings have not been measured.

Proposed direction: deliver compatible queued updates together

Please consider the batched queue mode already proposed in #15815 for unattended coordinating threads:

After the active run completes, start one next run containing the compatible updates already waiting, in queue order.
Preserve each update's source, text, attachments, and context. Keep task-result identity and delivery acknowledgement intact.
Let automatic child results participate through their existing delivery mechanism, rather than converting them into ordinary user messages.
Define which items must remain separate, including standalone commands and scheduled jobs with their own execution settings. An incompatible item must not be silently skipped or lose its configuration.
Make batching a server-side, per-thread choice, so it also works when no client is open.

Some completion batching already exists: the current delivery planner adds sibling task results to an existing queued delivery. The question is whether that mechanism can cover the compatible updates waiting across a coordinating thread's queue.

PR #26072 attempted ordinary-message batching but explicitly excluded delegated completions, notifications, and scheduled tasks. It is closed and unmerged. PR #19020 proposed manual squash and is also unmerged. This request builds on #15815 rather than proposing a duplicate feature.

Two related decisions with separate scope

Make a blocked queue visible. When a run has made no observable progress for a configurable interval and updates are waiting, show that condition in the thread list with the last activity time and queue count. Start with visibility; automatic termination needs a separate policy that accounts for legitimate long-running work, child work, and pending input.

Provider recovery already has related work: #18764 covers an unresponsive or dead backend, and #25149 covers stalled requests. Both are open. #24743 describes a similar blocked queue and is closed; the present observations do not establish its cause. The remaining product question is whether to expose inactivity plus queued work consistently in the thread list.

Allow safe promotion of completion notices. The promotion restriction is explicit in the current server. Could the existing completion-delivery mechanism support an explicit promotion into the thread's active turn, while retaining task identity, acknowledgement, and recovery if steering fails? If the restriction must remain, a supported way to consume all waiting results in the active turn would address the need. #14732 is relevant recovery work, not an implementation of this action.

What would demonstrate the behavior

For batching: queue two compatible reports, including an attachment, during an active run. When it completes, one next run receives both reports in order and the attachment. Repeat with automatic results from different originating turns, and check that each result is accounted for without a duplicate wake. An incompatible item remains separate.

For inactivity visibility: a quiet run with queued updates becomes visible after the configured interval; legitimate waiting work remains distinguishable.

For completion promotion: a queued notice reaches the active turn through the completion-delivery path. A rejected steer leaves its unread result recoverable.

Is automatic-result-aware batching an acceptable extension of #15815, and which items should be eligible? The inactivity indicator and completion-promotion change can be considered separately. This is a request for direction and scope before implementation.

2 replies

Krarilotus Oct 31, 2026

Following up on the coordinating-thread case above.

I support #26072's batch mode, off by default, for compatible queued messages. It lets the coordinator consider ordinary queued reports in one turn; automatic completions stay separate.

The closing comment cites missing visual evidence, not a rejection of batching on its merits. Before starting work, would maintainers approve the direction and scope of a fresh PR building on @aneym's work, linked back to #26072? It would include the requested before/after screenshots of the setting, a short recording of separately queued messages starting together, and focused verification. Automatic-result batching would remain a separate discussion.

Separately, could a queued message explicitly consumed by the receiver end as taken (or delivered) rather than cancelled? In 0.1.5, reading a queued text message in full and cancelling it to handle it in the running turn leaves the run cancelled; promote_to_steer does too. That state does not distinguish consumption from withdrawal. A taken action in t3_queue, and the same terminal state after successful promotion, would make that distinction explicit. This could be a separate change.

aneym Nov 2, 2026

Here is the evidence the #26072 closure asked for, from its last head (b356b80) and its base (d0b81ce). Both ran on a dev server with an empty database and Claude Haiku 5.5. Follow-up behavior is set to Queue on both, because with the default (Steer) a message sent mid-turn steers the running turn instead of queuing.

Settings, Chat > Follow-ups.

Before (base)	After (setting on)

Three messages queued while a turn runs. The first turn runs sleep 15, and messages A, B and C are queued separately while it runs. The recordings play at 1.6x.

Base: each queued message starts its own turn, so the thread ends with 4 turns.

queue-batch-base-separate.mp4

Setting on: when the first turn ends, A, B and C start together as one turn. The timeline keeps three message bubbles, and the agent replies once with "apple banana cherry". The thread ends with 2 turns.

queue-batch-on-together.mp4

With the setting off on the branch, the result matches the base (4 turns).

Not shown: desktop and mobile, the 20-message cap, and the items the batch leaves out (held completions, slash commands, /goal, scheduled tasks). One detail reviewers may ask about: the branch records the folded messages B and C as cancelled runs. That is the same ambiguity the taken state suggested above would resolve.

I won't open a new PR until a maintainer approves the direction here.

aneym · 2026-11-02T14:21:09Z

aneym
Nov 2, 2026

I built proposal 1, "Steer all", in our fork next to the batched mode from my earlier comment. We call it Send all, because it also works when the agent is idle.

What it does. A Send all button sits in the queue list header once two or more messages are queued. It sends the queued messages, in the order they were sent, as one message:

While a turn is running, it steers one combined message into that turn.
When the thread is idle, it starts one turn with all of them.

The combined message uses the same header as the batched mode: "These N messages were queued separately while you were working...", then each message with its number and sender. The timeline still shows each message on its own.

What stays queued. Delegated task completions, notifications, slash commands, /goal, and messages for a different provider or model. These keep today's handling. A completion that is held because a turn failed stays held, and the tooltip says how many are waiting. Send all is not offered while compaction is running. At most 20 messages go out at once.

Where it is. The queue list header on web and desktop, the mobile queue sheet, a command palette entry, a rebindable thread.sendAllQueued shortcut next to thread.steerQueuedMessage, and a send_all action on the queue MCP tool, so a coordinating thread can flush its own queue. It sits behind a setting under Settings > Chat > Follow-ups. Upstream, I'd ship it off by default.

What I ran. On a macOS dev build of our fork, against a real Codex turn running a long shell command, I queued three messages and ran each case:

While the turn ran, Send all reached the provider as one steer carrying all three, in order. The timeline showed three messages.
With the thread idle, Send all started one turn with all three.
With a held task completion plus two queued messages, Send all sent only the two messages. The completion stayed held and was not delivered.
When the turn ended just before the combined steer reached the provider, all three messages still arrived once, in the next turn.
The send_all MCP action did the same as the button.
With the setting off, the server rejected the command and the button was hidden.

I have not tested this on mobile hardware yet, or with providers other than Codex.

Three messages queued behind a running Codex turn, with the setting off (before) and on (after). Send all appears in the queue header:

Before	After

How it relates to Squash (#19020). Squash merges the queue into one queued message you can edit, and you send it yourself. Send all skips that step. They don't conflict, and Squash covers the edit-first case that Send all doesn't.

Questions for maintainers.

Is one action that steers when busy and starts a turn when idle the right shape, or should those be two actions?
Should Send all stay behind a setting, or appear whenever two or more messages are queued?
Is the MCP action wanted, or is the button and shortcut enough?

I'd open a PR only after you agree on direction and scope.

Drafted with AI assistance: Claude Opus 5.5 (claude-opus-5-5) via Claude Code in T3 Code.

0 replies

Navigation Menu

Repository navigation

Send queued messages together: a "Steer all" action and a batched queue mode #15815

Uh oh!

{{title}}

Uh oh!

Replies: 6 comments 2 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Send queued messages together: a "Steer all" action and a batched queue mode #15815

Uh oh!

1. "Steer all" action

2. Batched queue mode

Open questions

Replies: 6 comments · 2 replies

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Problem

Proposed direction: deliver compatible queued updates together

Two related decisions with separate scope

What would demonstrate the behavior

Uh oh!

Uh oh!

Uh oh!

Replies: 6 comments 2 replies