Seeded (forked) session: first request re-uploads the entire inherited log — 7.5 MB body, and a shifted system prompt

[cinast]

Seeded (forked) session: first request re-uploads the entire inherited log — 7.5 MB body, and a shifted system prompt

Environment: DSH Desktop 0.2.0-rc.2 (web), Windows 11, provider deepseek-official / deepseek-flash.
Related: #9927 (session-log upload keyed to provider, not endpoint), and the proxy-side counterpart I filed at ranxianglei/billion-context#5519.

What I measured

I forked a long-running session (parent session-da4469c3, 113 messages, already folded by the proxy) and sent a single "1" in the fork. Both requests were captured as outgoing bodies (proxy-side diagnostics.dumpBody).

Field	Parent, normal turn	Fork, first turn
Total body	583,455 B	8,071,802 B
dsh_session_log	10,856 B	7,504,595 B
system	27,011 chars	26,384 chars
messages	113 (0.41 MB)	109 (0.41 MB)
tools	106 (115 KB)	identical

So the 14× body inflation is entirely dsh_session_log: on the fork's first turn the uploader appears to send the whole inherited transcript, then falls back to the usual ~10 KB tail on subsequent turns.

Two questions

1. Is the full re-upload intended? For a seeded session the log uploader has no prior state for the new session id, so it starts from zero. That is defensible for fidelity, but it costs 7.5 MB per fork on the wire. Would an incremental/opt-in mode be acceptable (e.g. only upload when the endpoint is the official one and the session is not a fork, or send a compact manifest)?

2. System prompt differs between parent and fork (667 chars). The parent carries a state note in the system prompt (Generation boundary: this conversation's message-ref ledger was reset mid-conversation …); the fork, whose refs legitimately start at m00001, does not. Content-wise that is correct, but it means the wire prefix of a fork can never hash-match its parent, which is exactly the condition a prompt-cache-aware proxy needs. Would you consider keeping state-dependent notes out of the system prompt (tail attachment / separate field), or is "fork = new prefix" the intended contract?

Why it matters here

The proxy prices a fork at full input the first turn (0.4% cache hit) before recovering to ~90% on later turns. Part of that is the proxy's own breakpoint inheritance (filed separately as #5519); part is this upstream prefix drift. Worth documenting either way: if forks are meant to be prefix-compatible, one of the two layers needs to change.

Repro

1. diagnostics.dumpBody: true on the proxy (or any request-logging gateway).
2. Fork a folded session, send one short message.
3. Diff dsh_session_log size and system between the parent's last turn and the fork's first turn.