Look at all those tiny threads! Look at the token counts, and the number of user messages sent. The biggest thread is 151k output tokens and four user messages. The average thread is around 80k tokens. Now think of the time when we had a 1 million token context window. I wouldn’t run a thread that long…
But hey, there are 13 threads in that feature. Probably more, as these are only the threads connected by thread mentions. Add up all those and you’re close to one jam-packed 1 million token context window.
...
I start with a thread to build a basic implementation. If I think it’s going to be complicated, I might start with a thread to investigate some area of the codebase and gather the required context.
From that base, I’ll start new threads to tweak or refactor. Each change is a new thread — one change per thread. I use the read_thread tool to gather needed context from either the initial thread or from the previous refactor/tweak thread.
Recent articles
- Hello World - 11th January 2026
I'm thinking about how to integrate this approach into my workflow. I've recently wound up working with a lot of mega-conversations in Claude Code. Hours or days long, several compactions, and enough context that it feels like a huge pain to start over.
Clearly, that's not ideal, for model functioning or anything else.
I like the amp concept of
read_threadas a tool -- curious if anyone has implemented something similar for Claude. Obviously the.jsonlfiles are there, so it should be possible.