Queued agent message reverts a model change sent with Steer#33574
What happened
I changed a thread from Fable 5.1 to 5.2 and sent my message using Steer, because messages from other agents were already waiting in the queue and I did not want to wait for that backlog. The agent ran on 5.2 and confirmed it. When an agent message subsequently ran from the queue, T3 silently changed the entire thread back to 5.1. I had not selected 5.1 again and had to restore 5.2.
The unwanted switch and the switch back also caused an avoidable cache miss.
Diagnosis
The durable records show the user's 5.2 message recorded as a queued run while /compact was active on 5.1. A further ordinary t3_thread_send message was recorded 1.512 seconds later with the inherited 5.1 selection. The user's run applied 5.2 first; the following agent run then wrote its captured 5.1 selection back to the thread. Subsequent turns stayed on 5.1.
Upstream main ad9e87111fd9b2f10ec320b4de0a6ad3a092278a contains the relevant paths in apps/server/src/orchestration-v2/Orchestrator.ts: dispatch fallback at L5929; queued selection stored at L6352-L6362; followsCurrentConversation/queuedRunModelSelection at L835-L852 exclude ordinary MCP messages; queue promotion writes the stored selection back at L2388-L2408. OrchestratorMcpService.ts L3175-L3205 passes no selection.
The user did not request the old model, and neither did the sending agent. The reverting event was server-generated, not another device sending a stale model pick.
Steps to reproduce
Sequence to reproduce from the reported interaction and stored events:
- Have a thread on model A with messages from other agents already waiting in its queue. In this incident, /compact was also active.
- Select model B in the web composer and use Steer to send a message ahead of the waiting backlog.
- Let the user message run on B, then let ordinary agent messages continue from the queue. The recorded reverting message had no model override and had inherited A before the user's run applied B.
- Observe that the agent message runs on A and changes the durable thread selection back to A.
Expected: the explicit model choice remains in effect when ordinary agent messages resume from the queue.
No isolated reproduction on latest main was run. The UI action is reported by the user; the queued run states and model changes below are from durable server records.
Version
0.1.8-nightly.20261106.4275; local build with read-performance patches. Queue-policy paths checked against deployed source/patches and upstream main ad9e87111fd9. Not a clean official-build reproduction.
Environment
Self-hosted Linux x64 systemd server; Claude provider; web interface on phone, tablet and laptop. The reverting message was agent/MCP traffic.
Evidence
Durable orchestration events and run/message records; 2026-11-09 UTC; identifiers removed:
| 1 | 20:19:52.246 /compact requested on 5.1; completed 20:22:05.773 |
| 2 | 20:20:40.273 user/web submission (Steer in UI) recorded queued with explicit 5.2 |
| 3 | 20:20:41.785 agent/MCP run queued with inherited 5.1 |
| 4 | 20:22:24.933 thread model -> 5.2; command_id null |
| 5 | 20:22:36.510 assistant confirms 5.2 |
| 6 | 20:22:51.043 thread model -> 5.1; command_id null |
| 7 | 20:22:57.559 agent/MCP run running on 5.1 |
| 8 | 21:29:46.727 user/web send restores 5.2; command_id present |
Related issues
#22457 was closed in favor of discussion #22473 (same ordinary-agent queue policy). This report documents a model change sent with Steer ahead of an existing agent-message backlog, then undone by queue delivery. #22577/#22579 fixed delegated completions only; ordinary t3_thread_send remains excluded on inspected main. #24564 concerns stale client drafts, a different trigger.
Fix applied or workaround
The user restored 5.2 after the queue drained. No code, deployment or database changes were made during diagnosis.
Filed by
Codex / GPT-6.1-Sol in T3 Code, following the upstream triage playbook; prepared at the user's explicit request.