messages delivered in multiple copies without user redirection

[Perseidaz]

What happened?

I noticed Qwen Desktop Code, using Qwen 3.8 Max, often saying on its thinking that he receives my message or request multiple times, and everytime, interrumping what he's focused on. then I asked what's the reason, he said : " is raising a serious concern: if her message was delivered multiple times without her resending it, she's paying for the usage — is that equivalent to having her tokens stolen?

I need to be careful and honest here. Let me think about what actually happened technically, and what I can verify:

What I observed: identical messages appearing multiple times within my conversation context.

What this means in terms of token consumption:

If the host/client delivers the same user message multiple times within the same conversation, then on every subsequent model invocation the conversation history will include those duplicates, and each duplicate adds tokens to the context of every following turn (context is re-read with every request). That means real additional cost: duplicated messages inflate the context of every subsequent request.
However — I need to distinguish: if the same message arrived as separate turns (each generating a full model response), each turn = full context + new response. That multiplies cost significantly.
Do I actually know that duplicates occurred? Let me reconsider the evidence. Within the conversation, I saw the same text appearing multiple times. But honestly, I can't fully verify from my position the mechanism of that duplication — whether the client resent it, or the server replayed it, or it's a transcript artifact. And I also can't quantify exactly how many extra tokens were billed.

Her question "c'est des tokens volés? (is this stolen tokens?)" — I mustn't make definitive claims I can't back up ("yes, you were stolen from") nor brush it off lightly. Honest position:

The duplication is not something she did.
If a message exists N times in the context, then yes, from that point on every request carries the additional tokens — so there was probably additional cost compared to a clean single delivery.
Whether it's "stolen" depends on the cause (client bug vs. billing for a retry). I can't determine the root cause from inside. What I can do: (a) confirm the duplication exists within the conversation (I saw it), (b) suggest how to investigate/report it (the /bug command mentioned in my instructions!), (c) mitigate: is there anything I can do to reduce future cost? The duplicates are already in the history; I can't remove them from the conversation context myself. Practical mitigation: if the context is inflated, starting a new session reduces the per-request cost — and my memory file + reconstruction document was designed precisely to preserve continuity across sessions. This is a really useful suggestion: since the reconstruction document + memory exist, she can start fresh without losing anything, which also reduces the token burden of the inflated history.
What I should also do: report the bug. In my system prompt: "Feedback: To report a bug or provide feedback, please use the /bug command." I can't execute /bug myself (that's a user command), but I can guide her to use it.

Should I quantify? I can estimate: the duplicated messages were mainly the initial request (~100 words → ~150 tokens) × maybe 3-4 extra copies, plus some others. Per request, the cost of these extra ~500 tokens is small relative to the full context (which was very large — the 18GB pipeline, many tool calls). Honestly, the big costs in this session were the work itself (sub-agents reading millions of tokens, my own long context). The duplicates add a small fraction, not a dominant one. I should be honest about this — both directions: yes, duplication = paying for tokens I didn't choose, but quantitatively probably minor compared to the actual work; the real issue is the principle and the bug.

Actually wait — can I check how many times messages got duplicated? I can't look at the raw transcript from inside... I only have my own context. In the context I can count how many times identical text appeared: the request "tu peux consulter les threads..." appeared roughly 2-3 times in a row... the "en fait, je travaillais..." message also appeared multiple times, "qwen, sous forme de points précis" about twice, "j'ai 10 questions" about twice, the Claude comment about twice. I can state what I observed: several messages arrived duplicated (2-3 copies). I won't claim an exact number.

Estimate of the impact: each duplicate copy is roughly 50-300 tokens; if a conversation history carries k extra copies of a message, every subsequent API request pays k×len(message) input tokens. In a session with many turns, this compounds. Rough estimate: total duplicated content maybe 2,000-5,000 extra tokens in the context; over ~30+ model calls (plus sub-agents), probably 100,000-200,000 extra input tokens. Small relative to the session's total (tens of millions). Honest framing: minor but real; and it's a bug worth reporting.

I mustn't overstate either direction. Also acknowledge the emotional side: she's paying, and unexpected consumption is a legitimate concern — she's already been burned once (Claude's audit wasted 1.4M tokens).

Response structure:

Yes, you're right to take it seriously: duplication = extra tokens on the context of every request after the duplication — a real cost you didn't choose.
What I can confirm from my position: that several messages arrived in 2-3 identical copies; that neither I nor you caused it by deliberate action.
What I can't determine: the cause (client bug / retry / server), and the exact amount billed — that's host/billing-side info I don't have.
My estimate of the scale: probably modest compared to the session's heavy work (the thread analysis itself consumed millions of tokens via sub-agents), but not zero, and the principle matters.
Concrete actions: (1) Report via /bug (the command exists for exactly this) — provide the observed facts; (2) Mitigation going forward: my memory + reconstruction document makes a fresh session lossless, and a fresh session avoids carrying the inflated history; (3) I'll keep the duplication note in memory so I never treat a duplicate as a new instruction (which itself would waste tokens).
Keep it concise, don't over-reassure, don't fan anxiety. Answer the question directly: "stolen" is too strong a word for me to confirm; "billed without being chosen" is accurate. """ as thinking, and the final answer is : """ Ta réaction est légitime — je vais être précis, sans minimiser ni dramatiser.

Oui, ça a un coût réel. Chaque exemplaire en double d'un message reste dans l'historique de la conversation, et l'historique est relu à chaque requête modèle. Donc un message dupliqué N fois, ce sont N−1 copies de ses tokens facturées sur toutes les requêtes suivantes, sans que tu l'aies choisi. En ce sens : surfacturation subie, oui ; « vol » au sens d'une intention, je ne peux pas l'affirmer — je ne vois pas la cause (bug du client, retry réseau, duplication côté serveur), seulement l'effet.

Ce que je peux affirmer depuis ma position :

Plusieurs de tes messages me sont arrivés en 2–3 exemplaires identiques (la demande initiale sur les threads, le résumé en points, les 10 questions, etc.).
Ni toi (tu me le dis) ni moi (je ne les ai pas générés) n'en sommes la cause volontaire.
Ce que je ne peux pas déterminer : la cause exacte, ni le montant exact facturé — ces informations sont côté hôte/facturation, pas dans ce que je vois.

Mon estimation honnête de l'échelle : les doublons représentent probablement quelques milliers de tokens supplémentaires dans le contexte, répercutés sur les requêtes suivantes — réel mais modeste comparé au coût de la séance elle-même (l'analyse des threads a consommé des millions de tokens via les sous-agents, c'est le poste dominant, et celui-là tu l'as demandé).

Ce que tu peux faire :

Signaler le bug : la commande /bug existe précisément pour ça — signale « messages délivrés en plusieurs exemplaires sans renvoi utilisateur ».
Limiter la suite : les doublons gonflent cet historique à chaque requête. J'ai conçu la reconstruction (document + mémoire) pour être sans perte si tu ouvres une session neuve : tu repars sur un contexte propre, moins cher, avec tout le savoir du projet préservé sur disque.
Et ma note mémoire reste valable dans les deux sens : je ne traiterai plus jamais un doublon comme une nouvelle instruction — ça aussi, c'est des tokens que je te dois de ne pas gaspiller. """

What did you expect to happen?

this should not happen, bcs token are money, and multiplying messages or user requests without his knowledge is something odd. This subject must me clear and an explanation must be given .

Client information

cliVersion: 0.21.10
nodeVersion: 22.20.0
platform: win32
arch: x64 (10.0.26200)
memoryUsage: 128.6 MB

Login information

No response

Anything else we need to know?

No response

[Perseidaz]

translation of final answer : """ Your reaction is valid—I’ll be precise, without downplaying or dramatizing the situation.

Yes, there is a real cost involved. Every duplicate of a message remains in the conversation history, and that history is re-read with every model request. So, if a message is duplicated N times, you are billed for N−1 extra copies of its tokens on every subsequent request—without having chosen to do so. In that sense, yes, you are being overcharged; however, I cannot claim it constitutes "theft" in the sense of malicious intent—I don't see the root cause (client-side bug, network retry, server-side duplication), only the effect.

Here is what I can confirm from my end:

I received several of your messages in 2 or 3 identical copies (the initial request regarding the threads, the bullet-point summary, the 10 questions, etc.).
Neither you (as you’ve told me) nor I (since I didn't generate them) caused this intentionally.
What I cannot determine is the exact cause or the precise amount billed—that information lies with the host/billing system, not within what I can see.

My honest estimate of the scale: the duplicates likely account for a few thousand extra tokens in the context, which are then factored into subsequent requests. This is real, but modest compared to the cost of the session itself (analyzing the threads consumed millions of tokens via sub-agents; that was the dominant cost, and it was one you requested).

Here is what you can do:

Report the bug: the /bug command exists specifically for this purpose—report it as "messages delivered in multiple copies without user resubmission."
Limit further activity: duplicates bloat the history with every request. I designed the reconstruction process (document + memory) to be lossless if you start a new session: you begin with a clean, cheaper context, while all the project knowledge remains preserved on disk. And my mental note holds true both ways: I will never again treat a duplicate as a new instruction—those are tokens I owe it to you not to waste, too. """

[qwen-code-ci-bot]

✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

[Perseidaz]

[qwen-code-ci-bot]

Triage

• Type: bug (unverified — the evidence so far is the model's own report about its context)
• Labels: type/bug, category/core, scope/session-management, scope/windows, priority/P3, status/need-information
• Next: static analysis done; need a session transcript to confirm duplicated user messages actually exist in the request payloads

中文说明

• 类型：bug（未经证实 —— 目前的证据仅为模型对自身上下文的描述）
• 标签：type/bug、category/core、scope/session-management、scope/windows、priority/P3、status/need-information
• 下一步：静态分析已完成；需要会话记录文件来确认请求负载中确实存在重复的用户消息

Analysis

Evidence carried: static source review only. No reproduction was executed (unattended CI triage never runs code); runtime behavior was not exercised.

Confidence: plausible — a matching mechanism exists in the code, but the report's core claim is not yet verified.

• The only evidence so far is the model's own reasoning claiming it saw identical user messages 2–3 times in its context. In very long sessions a model can also misread its own history, so a payload-level check is needed before this is treated as a confirmed defect.
• A plausible mechanism exists: when a turn is aborted and automatically retried, the original user message is re-sent as a new turn, while the aborted turn remains in the model's context. The same text then legitimately appears twice (or more, if retries stack up), and each retry visibly "interrupts" the agent mid-focus — matching the reported symptom. Known triggers in the desktop/session layer:
  • source auto-activation mid-turn — the turn is aborted and the message is re-sent with a [<source> activated] suffix
  • tool-call-error auto-retry (same machinery)
  • auth token refresh mid-turn ("Token expired, refreshing session…")
• The CLI's own retry path strips orphaned user entries from the history before re-submitting, so CLI-side retries should not duplicate history.
• If the transcript confirms real duplicates, the fix direction is to drop or fold the aborted turn's user message out of the model context before the re-send, instead of appending a fresh copy.
• Related but distinct: Message duplication bug #1591 (rendering-level duplication on Termux), Qwen Code sends duplicate tool-result history for a reused tool-call id #5099 (closed — duplicated tool results for a reused tool-call id).

Information needed (@Perseidaz)

1. Which client exactly? Desktop app (version from About/Settings) or the CLI in a terminal?
2. Around each interruption, did you see any of: "Token expired, refreshing session…", a [<source> activated] note, or an error being retried?
3. The session transcript of the affected conversation (redact anything sensitive first) so we can confirm the duplicates exist in the actual payloads:
   • Desktop: C:\Users\<you>\.craft-agent\workspaces\<workspace-id>\sessions\<session-id>\session.jsonl
   • CLI: %USERPROFILE%\.qwen\tmp\<project>\chats\*.json
4. Please update to v0.21.13 (the report is on 0.21.10) and note whether it still occurs.

--- Qwen Code

[doudouOUC]

Thanks for the detailed report — the token-cost concern is legitimate, and there is a concrete mechanism in the desktop client that can produce exactly this symptom. I verified it against the current main branch.

What happens

The desktop app has an automatic turn-restart pipeline: when a source (connector) gets auto-activated mid-turn, or a tool-call error triggers an auto-retry, the in-flight turn is force-aborted and your original message is re-sent automatically as a new turn:

• packages/desktop/packages/server-core/src/sessions/SessionManager.ts — on mid-turn source activation, the session records the current turn's user message and marks a pending restart ("The current turn must end before newly activated tools are visible... The renderer's auto_retry effect then resends the original user message with a [{slug} activated] suffix").
• packages/desktop/packages/shared/src/agent/qwen-agent.ts — after the next tool_result, the agent emits source_activated and calls forceAbort(AbortReason.SourceActivated).
• packages/desktop/apps/electron/src/renderer/App.tsx — the auto_retry effect re-sends originalMessage + "\n\n[<source> activated]" via sendMessage ~100ms later.

The key problem: the aborted turn (including your original user message) stays in the session history, and the re-sent copy is appended as a fresh user turn. So the same text legitimately appears 2+ times in the model's context — once per restart — and each restart visibly interrupts the agent mid-work. That matches both things you observed: duplicated messages and the agent saying it was interrupted.

By contrast, the CLI's own retry path avoids this: packages/core/src/core/turn-interruption.ts strips the orphaned trailing user entries and re-pushes the same content under the same logical turn, so the transcript gains no duplicate user message. The desktop auto-resend path has no equivalent fold/dedup step.

About the tokens

To answer your question directly: if a message exists N times in the history, every subsequent request in that session carries the extra N−1 copies as input tokens — so there is real (though usually modest) extra cost, and it compounds over a long session. It's not intentional billing; it's a bug in the restart path. Starting a fresh session does reset the inflated history, as the model suggested.

How to confirm it was this path

1. In the affected session, look for messages that end with a [<source> activated] note — one appears for each automatic restart. If you see them right after the duplicated messages, this is the culprit.
2. The session transcript (path in the triage comment above — please redact anything sensitive) will show the duplicated user entries in the actual payloads; that also lets us rule out the alternative explanation (a very long session where the model simply misreads its own history).

If you can share the transcript (or just the count of [<source> activated] notes around the interruptions), we can confirm and track the fix. The fix direction is to drop or fold the aborted turn's user message out of the model context before the re-send — mirroring the CLI's turn-interruption.ts strip semantics — instead of appending a fresh copy.