Session-start sidecar request is sent twice, ~13 ms apart, and both are billed

Reporting a duplicate-send shape we can measure continuously, in case it is
useful. This is a client-side send pattern, not a caching question, and it is
a different shape from the doubled-prefix report in #78420: theirs is one
request carrying a doubled body, ours is two separate requests carrying
identical bodies. I am filing it separately rather than adding it there for
that reason.

What we see. At session start, the same sidecar request is issued twice,
roughly 13 ms apart, with the second going out while the first is still in
flight. Both are answered and both are charged. The two are byte-identical
adjacent same-conversation requests carrying distinct upstream request-ids,
and each has its own completed usage record — so this is two accepted
requests, not one request retried after a failed stream.

How it is measured. We run a local forwarding proxy in front of Claude
Code that records requests pre-pipeline and replays them through a gate. The
duplicate detector groups by conversation, pairs adjacent byte-identical
bodies, and joins each member to its own usage record; a member that cannot
be joined is reported rather than dropped.

Numbers, from one sweep over one machine's live traffic across 45
captures:

• 75 duplicate pairs, forming 65 streaks; longest streak 5
• 140 requests involved, of which 62 were billed
• 38 billed streaks, of which 24 were double-billed
• membersWithoutId: 0 — every member joined to a usage record, so the

billing split is a read and not an estimate

• split by shape: 51 single-message streaks (17 double-billed) and 14

multi-message streaks (7 double-billed)

Why the split matters. The single-message streaks are the session-start
sidecar and are the bulk of the population. The multi-message ones are a
smaller, separate group that we have characterised much less well.

What we did NOT check, stated so the verified parts are usable:

• We have not established the client-side cause. We observe two sends on the

wire; we have not traced what issues them, and nothing here should be read
as a claim about the code path.

• These are counts from one machine's traffic on one day. We have not

checked whether the rate holds across machines, versions, or workloads, and
we are not claiming a fleet rate.

• We have not measured the token cost of the duplicates as a fraction of

total spend. The counts above are request counts, not a bill.

• Our own mitigation coalesces the single-message case only: the

multi-message coalesced count reads 0 in the same sweep. So the
multi-message half is unmitigated on our side and its "unchanged versus
mitigated" comparison is not established — we have one post-flip
multi-message control, which is too few to conclude anything either way.

• We have not tested whether the duplicate is idempotent from the server's

point of view, only that both members are billed.

Happy to provide the detector's grouping rules or re-run the counts over a
longer window if that would help.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_019stbymw1bF8UET5DgRkrCv