Redesigning session history to set the stage for parallel subagents

[jpia]

Hey all 👋 — I've got a working prototype of this running locally and I'm still in the testing/refining phase. Before I start opening PRs, I wanted to put the shape of it out here and see if the community thinks I'm on the right path. Happy to course-correct based on your feedback.

Why I'm doing this

1. I'm using late to learn local models. I've been running it against oMLX to build intuition for how they behave, with the eventual goal of fine-tuning my own. A big part of that learning is replaying conversations — including subagents. Today subagent conversations are in-memory only and vanish the moment the subagent finishes. I want every conversation persisted so I can inspect, replay, and eventually use them as training data.

2. I want parallel research subagents someday. Imagine spawning 3–5 research subagents in parallel, each with its own isolated history, then consolidating. For that to be safe, each subagent needs a stable, collision-free path before any goroutine spawns. The current session store can't guarantee that, so this redesign sets the stage without actually implementing parallel execution yet.

The latent problems

To make subagent history land safely, two existing issues need fixing first:

#	Problem	Why it matters
1	ID race. Subagent IDs are minted from len(parent.Children()) — a read under no lock that races the append in AddChild under another lock. Two concurrent spawns both see count = 0, both mint coder-subagent-0, and the second rename silently overwrites the first.	Count-based IDs collide under concurrent spawns. Parallel subagents are unsafe until this is gone.
2	Flat-dir clutter. One loose .json per session in a shared top-level dir. Add subagent history and every subagent drops another indistinguishable file. Grouping, listing, and deleting a session's artifacts all become ad-hoc.	Happens even with sequential subagents. No parent-child relationship on disk.

Rather than patch each symptom, one layout change takes care of both.

The high-level design

One folder per session. Subagent histories nest as subfolders inside the parent — so late session list (top-level walk) never sees them, late session delete <id> cascades for free via rm -r semantics, and each session folder is owned by exactly one writer.

~/.local/share/late/sessions/
├── session-20260803-192905/        # parent — date-based ID unchanged
│   ├── history.json
│   ├── meta.json
│   └── subagents/
│       ├── coder-subagent-0_01J8Q3PT…/   # ULID-suffixed (new)
│       │   └── history.json
│       └── coder-subagent-1_01J8Q3Q0…/
│           └── history.json
└── session-20260803-185121/
    └── …

The ID race is fixed internally (not a breaking change): subagent IDs are minted under the parent mutex with a ULID suffix via NextChildID(agentType). Two concurrent spawns can't construct the same path. Parent session IDs stay date-based; only subagents gain the ULID suffix — and since subagent history is brand-new, nothing on disk breaks.

Migration is one-shot and idempotent. Existing flat session-*.json + session-*.meta.json files move into a folder named after the ID (the ID itself is preserved — pure layout move). Runs automatically on startup;

Making the legacy code easy to eventually remove

For backwards compat, the old flat-layout read/migrate code can stay for a while (maybe a few weeks/months?). To keep that cleanup trivial, I'm isolating all of it in a dedicated internal/session/oldsesh package and lifting the fallback decision up to cmd/late, so internal/session itself is already folder-only with zero legacy branches.

The practical payoff: when the deprecation window closes, it's rm -r internal/session/oldsesh, drop the two TODO(deprecate) glue lines in cmd/late, and go mod tidy. internal/session doesn't change at all.

What I'd love feedback on

I'm mostly looking for a gut check — does any of this feel off, or is there a simpler approach I'm overlooking? If you've wrestled with subagent history or persistence before, I'd love to hear what worked, what didn't, and what I probably got wrong.

Beyond all the design questions — I just want to say that late is just really fun to run and work with. I'm grateful it exists. Thank you!!!

[mlhher]

Thank you for the kind words. Always great to hear.

On the two suggestions:

Subagent histories:

I am open to adding this, but it should be opt-in. These histories can become gigantic, especially with external APIs. In my own usage subagents make up the vast majority of more than 50 million tokens over just a few days using DeepSeek, so saving everything by default could explode quickly.

I agree that the flat layout becomes awkward here and the issues you noted are real. However I would keep this simple for now: a flag enables both the folder layout and the subagent saving under late/sessions/session-timestamp/, with the session files there and subagents under late/sessions/session-timestamp/subagents/$type-subagent-$id.json.

The session commands should always support both layouts while the flag only controls writing new sessions/subagents this way. If an existing folder session is loaded it should continue writing there even without the flag. This also means we do not need an automatic migration for now (even if we can look at it later).

Parallel subagents:

There are two different designs I see here:

1. spawn_subagents takes multiple tasks, runs them at once, but blocks the parent until all are done. This would be a new tool.
2. spawn_subagent starts something in the background and lets the parent continue. This would be the existing tool taking a new argument (e.g. async)

The first is something I would consider, though it needs testing with smaller models such as Qwen3.6-35B-A3B and Gemma4-26B-A4B.

The second will likely be rejected (unless reasonably being shown that these issues do not happen). The parent would continue without the information it delegated and make decisions based on assumptions which may be wrong. Returning the result later either means inserting it into the earlier history, breaking KV-cache (and forcing constant prompt-reprocessing), or appending it after the parent already continued and complicating the tool ordering and/or degrading the models intelligence. Blocking until the result is available avoids both.

There are still open questions with multiple subagents at once. Researchers are likely fine, but two coder subagents could edit the same places. Generally I am not quite sure what the concrete use case is, so I would be happy to see some examples of how you would use this.

[jpia]

I appreciate the feedback!

I'll go ahead and make these adjustments on the subagent histories:

1. Opt-in only via CLI flag (per session control) or config (for users like me that want to set and forget)
2. Keep the original parent history files flat (no more migration needed) and put subagent history as late/sessions/session-timestamp/subagents/$type-subagent-$id.json.
3. CLI session commands must support both layouts

I agree with your points on the parallel subagents. As for my usecase, I often see my local model spawn multiple agents (sequentially) to research sections/repos especially on big monorepos during the discovery phase. And I sometimes notice that the next research agent doesn't really need the previous research agent's results to do its job -- these would be good candidates for parallel researchers.

I also have this idea for a code review team, where each code review agent is hyper-focused on one aspect (i.e. security only, maintainability only, etc) since I find that it helps smaller local models produce higher quality reports. -- especially for MoE variants.

[mlhher]

As for my usecase, I often see my local model spawn multiple agents (sequentially) to research sections/repos especially on big monorepos during the discovery phase. And I sometimes notice that the next research agent doesn't really need the previous research agent's results to do its job -- these would be good candidates for parallel researchers.

I also see these from time to time (specifically with Qwen) but the issue here is that we cannot reliably detect if a subagent needs previous context or not. It is similar as to the Bash AST permissions being evaluated by a model. I'd rather take "100% it just works" but with some duplication over "it works incredibly 90% of the time but breaks entirely the other 10%".

I also have this idea for a code review team, where each code review agent is hyper-focused on one aspect (i.e. security only, maintainability only, etc) since I find that it helps smaller local models produce higher quality reports. -- especially for MoE variants.

I agree with the MoE note. While the idea is great I am worried about a complexity explosion here. Though in contrast this likely is a great use-case for the parallel subagents. Will need to see real evaluations. As noted big models usually will have no issues.

Generally I think the primary thing we should be looking out for is that whatever we do it does not break Gemma-4-26B-A4B and Qwen3.6-35B-A3B (or whatever MoE is the "best" in that class at a given time). In contrast I am sure for example DeepSeek-V4-Flash-0731 would have no issues whatsoever.

[jpia]

@mlhher I use Qwen3.6-35B-A3B often but I don't have a Gemma-4-26B-A4B model configured at the moment. I did notice in the source code that there are some Gemma-specific logic. Do you have a recommendation on for how to configure Gemma-4-26B-A4B and what edge cases to look out for when testing Gemma?

[mlhher]

You should not need to account for anything. I assume you mean the -gemma-thinking flag which injects the thinking tokens into the system prompt which per Google doc are required for Gemma to think.

Apart from that I generally would try to avoid having model specific quirks unless it is a widely used model and mandatory for it according to spec.