pastilhasandClaude Opus 5
856a63b840
Send no longer refuses mid-turn. The prompt goes into a queue, and each turn's completion delivers the next — one per turn, which is the whole drain loop. A slash command the client handles itself never starts a turn, so delivery reports whether it did and the drain keeps going rather than waiting for a completion that will not come. Attachments are captured when the prompt is composed, not when it is delivered, so a queued message keeps the files it was written with instead of picking up whatever is in the tray when its turn arrives. The composer empties on queue as it does on send — a box that stayed full would read as "it didn't take", and you would send it twice. The send button turns amber with a different icon to say the press will not go anywhere yet, and sits BESIDE stop rather than replacing it: typing a follow-up should not cost you the ability to interrupt. A tray above the composer lists what is waiting, each item removable — without it a queued prompt is invisible until its turn, which looks exactly like having lost it. Stop clears the queue. Ending a turn is precisely the signal the drain waits for, so leaving it alone fired the next prompt the instant you pressed the button meant to halt things. Nothing is lost: a queued prompt was recorded in the prompt history when it was written, so Up brings it back. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>