The diff block in a dump's meta.json is excellent for cache work — it pins the first byte where a request diverges from the previous one in the same session:
{"changed":true,"firstByte":907600,"lastPreviousByte":907765,"lastCurrentByte":908802,
"changedPreviousBytes":166,"changedCurrentBytes":1203,
"previousBytes":1176656,"currentBytes":1177693}A healthy incremental turn diverges deep in the body; a prefix change shows up as a tiny firstByte. That single number is the fastest cache-bust triage signal in the whole plugin.
The baseline is held in memory, so it does not survive a restart. The first request of a new process has no diff field at all — I can see it directly in my dumps, where the request at the restart boundary (filename counter back to 000001) carries no diff record while its neighbours all do.
That's the wrong moment to lose it. Restart is exactly when you want byte-level attribution, because it's when a prefix change is most plausible — new plugin build, changed system prompt, re-derived cache anchors. I spent a chunk of an investigation today reconstructing by hand what the diff would have told me immediately: pulling the last pre-restart and first post-restart body for one session and running cmp to establish the prefix was byte-identical through 200,000 bytes. That comparison is exactly what diff does, and the data was on disk the whole time — the previous request's .body.json was sitting right there in the dump directory.
Suggested direction: when dumping is enabled and no in-memory baseline exists, seed it from the newest .body.json on disk for that session before computing the diff. That keeps it opt-in with dumping, needs no new persisted state, and closes the gap precisely where it currently opens. Failing that, recording baseline: "none (new process)" instead of omitting diff would at least make the absence explicit rather than looking like an unchanged body.
Minor and diagnostics-only — no runtime behaviour rides on it. Filing because the gap is invisible until you're mid-investigation and the one datapoint you need is missing.
The
diffblock in a dump'smeta.jsonis excellent for cache work — it pins the first byte where a request diverges from the previous one in the same session:{"changed":true,"firstByte":907600,"lastPreviousByte":907765,"lastCurrentByte":908802, "changedPreviousBytes":166,"changedCurrentBytes":1203, "previousBytes":1176656,"currentBytes":1177693}A healthy incremental turn diverges deep in the body; a prefix change shows up as a tiny
firstByte. That single number is the fastest cache-bust triage signal in the whole plugin.The baseline is held in memory, so it does not survive a restart. The first request of a new process has no
difffield at all — I can see it directly in my dumps, where the request at the restart boundary (filename counter back to000001) carries no diff record while its neighbours all do.That's the wrong moment to lose it. Restart is exactly when you want byte-level attribution, because it's when a prefix change is most plausible — new plugin build, changed system prompt, re-derived cache anchors. I spent a chunk of an investigation today reconstructing by hand what the diff would have told me immediately: pulling the last pre-restart and first post-restart body for one session and running
cmpto establish the prefix was byte-identical through 200,000 bytes. That comparison is exactly whatdiffdoes, and the data was on disk the whole time — the previous request's.body.jsonwas sitting right there in the dump directory.Suggested direction: when dumping is enabled and no in-memory baseline exists, seed it from the newest
.body.jsonon disk for that session before computing the diff. That keeps it opt-in with dumping, needs no new persisted state, and closes the gap precisely where it currently opens. Failing that, recordingbaseline: "none (new process)"instead of omittingdiffwould at least make the absence explicit rather than looking like an unchanged body.Minor and diagnostics-only — no runtime behaviour rides on it. Filing because the gap is invisible until you're mid-investigation and the one datapoint you need is missing.