The problem
With the 200k context window, a conversation was effectively a single sitting, and archiving it as one dated file was exactly right.
The 1M window changed that. A single conversation now routinely spans days or weeks — you come back to the same session repeatedly rather than starting a new one. A real example: one session ran from July 17 to July 25 (nine days, ~10MB of .jsonl).
Codec names the archive for the session's start date, so all nine days landed in 2026-07-17_session-*.md. That produces two failure modes:
- Discovery — looking for work done on July 25th, you search for a
2026-07-25 file, find nothing, and reasonably conclude it was never archived. It was. It's filed under the day the conversation opened.
- Navigation — once inside a 10MB transcript, there's no way to find "where did the July 25th work start?" short of scrolling or guessing at a keyword.
This is a good problem to have. It only exists because sessions can now run this long.
What NOT to do: split into per-day files
The obvious fix is to break the archive into one file per day. I think that's wrong, and it defeats the point of the tool.
A conversation spanning nine days is still one conversation. Threads opened on Tuesday get resolved on Friday; the reasoning carries across. Codec exists to preserve the journey, and splitting the file destroys precisely the continuity that makes the journey worth keeping. The boundaries would also be arbitrary — a session running 11pm to 1am would tear in half mid-thought.
Keep one file per conversation. Make the seams visible instead.
Proposed: three additive changes
1. Break on resumption, not on midnight
The useful signal isn't "the calendar date changed," it's "the human left and came back." A six-hour gap is a real seam; crossing midnight mid-burst isn't. So detect gaps between consecutive messages above a threshold (~3 hours, configurable) and insert a visible marker:
──────────────────────────────────────────────
⏸ Resumed · Saturday, July 25 2026 · 3:30 PM
(gap: 6 days, 4 hours)
──────────────────────────────────────────────
Searchable by date, and it surfaces something the raw transcript doesn't: where the pauses were — which is often exactly what you're trying to locate.
2. A table of contents at the top of the file
Sessions within this conversation:
2026-07-17 (Fri) · 2026-07-18 (Sat) · 2026-07-19 (Sun) · 2026-07-25 (Sat)
So you can see what a 10MB file contains before scrolling into it.
3. Filename reflects the span
2026-07-17_to_2026-07-25_session-clean.md
This is the change that actually fixes discovery — the date range is visible in a directory listing, so you know which file holds July 25th without opening anything.
⚠️ Implementation caveat: the filename now changes as an in-progress session grows, which interacts with the existing "already archived, no changes" dedupe logic. That logic will need to match on conversation ID rather than filename, and rename the existing file when the span extends.
Feasibility
The .jsonl already carries per-message timestamps (the full export prints them), so gap detection is exact rather than heuristic. Changes are contained to extract-conversations.js, and all three are additive — existing archives stay valid.
Priority
Low-urgency, high-quality-of-life. Nothing is lost today; it's a findability problem, and it will get steadily more annoying as multi-day sessions become the norm rather than the exception.
The problem
With the 200k context window, a conversation was effectively a single sitting, and archiving it as one dated file was exactly right.
The 1M window changed that. A single conversation now routinely spans days or weeks — you come back to the same session repeatedly rather than starting a new one. A real example: one session ran from July 17 to July 25 (nine days, ~10MB of
.jsonl).Codec names the archive for the session's start date, so all nine days landed in
2026-07-17_session-*.md. That produces two failure modes:2026-07-25file, find nothing, and reasonably conclude it was never archived. It was. It's filed under the day the conversation opened.This is a good problem to have. It only exists because sessions can now run this long.
What NOT to do: split into per-day files
The obvious fix is to break the archive into one file per day. I think that's wrong, and it defeats the point of the tool.
A conversation spanning nine days is still one conversation. Threads opened on Tuesday get resolved on Friday; the reasoning carries across. Codec exists to preserve the journey, and splitting the file destroys precisely the continuity that makes the journey worth keeping. The boundaries would also be arbitrary — a session running 11pm to 1am would tear in half mid-thought.
Keep one file per conversation. Make the seams visible instead.
Proposed: three additive changes
1. Break on resumption, not on midnight
The useful signal isn't "the calendar date changed," it's "the human left and came back." A six-hour gap is a real seam; crossing midnight mid-burst isn't. So detect gaps between consecutive messages above a threshold (~3 hours, configurable) and insert a visible marker:
Searchable by date, and it surfaces something the raw transcript doesn't: where the pauses were — which is often exactly what you're trying to locate.
2. A table of contents at the top of the file
So you can see what a 10MB file contains before scrolling into it.
3. Filename reflects the span
This is the change that actually fixes discovery — the date range is visible in a directory listing, so you know which file holds July 25th without opening anything.
Feasibility
The
.jsonlalready carries per-message timestamps (the full export prints them), so gap detection is exact rather than heuristic. Changes are contained toextract-conversations.js, and all three are additive — existing archives stay valid.Priority
Low-urgency, high-quality-of-life. Nothing is lost today; it's a findability problem, and it will get steadily more annoying as multi-day sessions become the norm rather than the exception.