A queued delegated-task completion reverts a model change made while it waited#22577

Reproduced on current main 70e5e384da, Linux x64, real web dev server with Claude Opus 5.5. Started an async child, ended the delegating turn, then kept a second parent turn active until the child completion queued. Persisting Sonnet with thread.model-selection.set succeeded at 22:50:09 UTC; queue delivery at 22:50:19 wrote Opus back with no command attached and started the completion on Opus. The picker alone changed the composer draft during the active turn, so the persisted change used the app metadata command. Sanitized runtime transcript.

Additional live incident on 2026-10-30: a delegated-task completion switched a thread from Codex / GPT-6.1-Sol back to Claude / Opus 5.5, after the user intentionally left Claude because its usage allowance was exhausted. The automatic Opus turn immediately failed on the usage limit.

This appears to be the same defect as this issue, with a cross-provider and exhausted-account consequence.

Observed sequence

Times are UTC, read from t3_thread_read run metadata and activity (not inferred from the UI clock):

At 17:21:23.142, the continuation's activity contains a Codex → Claude provider context handoff followed by the notification that a delegated implementation task had finished. At 17:21:24.963 it records “Claude usage limit reached,” then the provider failure.

The user explicitly reported: “I switched it to Sol intentionally (I'm out of Opus usage).” No agent-requested provider-switch action appears in the intervening Sol turn. A subsequent user turn ran on Sol again.

Diagnosis and current source check

The observed older request starting immediately after the Sol turn, on its previously selected provider, is consistent with the queue-time selection behavior documented above.

I checked public main at 6fc9144a60c4a5f45089316ddd5f7371bafd3bf2:

• ProviderContinuationService.ts, lines 119–135 still dispatches delegated completions using queue_after_active without an explicit modelSelection.
• Orchestrator.ts, lines 767–784 lets eligible monitor updates follow the current conversation, but otherwise returns the queued run's stored selection.
• Queue delivery, lines 1521–1540 resolves the queued provider from that selection. A usage-limit queue guard exists there; this incident alone does not establish why the installed runtime let this continuation through.

This source check is separate from the incident: the installed server's exact release/commit was not established, and I did not reproduce the incident on current main. The locally available t3 --version reports 0.1.0, but that identifies the CLI, not necessarily the serving process. Environment is Linux with both Claude and Codex providers. No provider calls were made to reproduce the failure, and no runtime configuration or source code was changed during investigation.

Expected behavior and impact

An automatic delegate-completion notification should follow the user's current thread selection and should not restore an older provider. If explicit pinning must remain for other queued message types, distinguish those from automatic completions.

The practical consequence is that switching away from an exhausted subscription can appear to succeed, complete useful work, and then be undone by a delayed background notification. It causes another usage-limit failure and forces the user to restore the intended provider.

Attaching this evidence to the existing issue rather than opening a duplicate. Private project names, transcript contents, thread IDs and credentials are omitted.

Reported on the user's behalf by GPT-6.1-Sol.

Another live incident on 2026-10-31, on 0.1.5 (macOS arm64 desktop app, local server). Here it is two accounts of the same provider (claudeAgent and claudeAgent_2), and the thread loops. The user could not keep it on the account that has quota. This also shows that #22579 alone would not fix it: most of the stuck messages were not delegated completions.

What the user saw

The second Claude account (claudeAgent_2) hit its weekly limit (usage_limit_reached, rateLimitType: seven_day, resets Nov 1). The user switched the thread to claudeAgent, which has quota. Each time, the thread switched itself back to claudeAgent_2 1–7 minutes later, and the turn that followed failed on the limit. They switched back five times in about 25 minutes.

Why it keeps looping

The thread receives a steady flow of automated messages. While it was busy on claudeAgent_2 overnight, 72 of them queued, each storing claudeAgent_2:

Scheduled tasks take the thread's selection at dispatch (#18467). When the thread is busy, though, dispatch means "queued", so they keep the selection the thread had at that moment. Each cycle went like this:

1. The user switches to claudeAgent and sends a message. The turn completes.
2. Per #21705 (and #27221), that completed run releases the usage-limit hold even though the queued runs target the exhausted instance.
3. The next queued run starts with its stored selection (queuedRunModelSelection returns run.modelSelection for non-monitor messages) and emits thread.provider-switched → claudeAgent_2 with no command attached.
4. It fails on the limit. Any message queued while the thread is back on claudeAgent_2 stores claudeAgent_2 too, so the backlog refills: it grew from 67 to 72 during triage.

queuedRunModelSelection is unchanged on v0.1.6 and on main. Open PRs #22579 (delegated completions only) and #22425 (provider-specific hold) would together cover 4 of the 72 messages plus the hold release. The 62 scheduled-task messages and 6 agent sends would still switch the thread back as soon as the hold lifts.

Evidence

From orchestration_events on the thread (UTC):

Workaround that worked

1. t3_thread_configure the thread onto the working instance first, so new arrivals store it.
2. Cancel every queued run that stores the exhausted instance (t3_queue cancel, 72 calls).
3. Re-send their content as one message.

After that, every queued and running item stored claudeAgent. Disabling the instance does not help: instanceDisabledForProject holds the whole queue, including the runs on the working instance.

Suggested behavior

Any queued message a user did not type (createdBy: agent or system, including scheduled-task and agent-sent messages) should start on the thread's current selection, as monitor messages do since #21314. At minimum, a queued run should never switch the thread onto an instance whose usage limit has not reset yet.

Comment prepared by Claude Code (Claude Opus 5.5) via t3 triage.