Problem

When a user types a message while Claude is mid-response, the message sits in a queue and gets delivered after Claude finishes. Claude then reads it as a reply to its just-completed output — but the user was responding to something earlier in the conversation.

This causes misinterpretation and wasted turns correcting the confusion.

Example

1. User: "Should I use approach A or B?"
2. Claude: (starts generating a long comparison of both approaches)
3. User (types while Claude is still writing): "Actually let's go with A"
4. Claude finishes its comparison, sees "Actually let's go with A"
5. Claude thinks the user read the comparison and chose A based on it — but the user had already decided before reading it

Another example: user types "yes" to confirm their own previous statement, but Claude reads it as agreeing with whatever Claude just said.

Proposed Solution

The client already knows when a message is queued (submitted while Claude is processing). Tag it before sending to the API:

[typed while Claude was writing]
Actually let's go with A

Or as a system-level annotation:

<message-context>This message was typed while Claude was still responding. 
It likely refers to the conversation before Claude's last response, not to that response itself.</message-context>

This gives Claude the context to interpret the message correctly.

Why This Matters

• Zero effort from the user — no need to manually add context like "re: my earlier message"
• Reduces wasted turns — Claude doesn't go down the wrong path
• Especially helpful for voice-typing users — dictation is slower, so messages queue more often
• Simple to implement — the client has all the timing info, no AI inference needed

Implementation

• The client knows when Claude starts/finishes processing
• The client knows when the user submits input
• If user_submit_time < claude_finish_time, the message was queued
• Wrap it with a context tag before sending to the API