Threads outgrew read_thread
, so we rewrote it.
read_thread
is the tool that lets Amp pull context out of other Amp threads when you mention them. Before the rewrite, it would fetch the whole thread and extract the relevant parts in a single call to another LLM.
That used to work when threads were shorter and contained a single context window. Then we added compaction and now a single thread can run for weeks. Our longest thread has been compacted over 68 times — without compaction, it would be over 21 million tokens long.
A 21-million-token thread doesn't fit into a single context window, so asking another LLM to extract relevant parts doesn't work anymore. And even threads with 1 million tokens that fit gave bad answers: one giant prompt over-weights whatever the thread ended with or started with and ignores the information in the middle.
read_thread
is now a subagent tuned to extract information from long threads. The subagent takes a thread and a question, searches the thread, reads the messages, and checks whether later work revised or reverted what it found.
Our first version of the read_thread
subagent answered from the first plausible hit. In a long thread, the first hit is often an attempt that was later revised or reverted. We switched the model to GLM 5.2 from Gemini 3.5 Flash and tuned its prompt to optimize for correctness over speed:
It also works on the thread you're in. When the agent needs something from three weeks ago — a decision, an error, the original plan — it goes back and looks instead of trusting the compaction.
Nothing changes on your end. Either tell Amp what you're looking for and let it find the thread, or give it a thread explicitly: paste a URL, or @-mention it. And when you open a new thread, hit Enter twice to reference the thread you just left.
Mention a thread and ask a question, just like before, except it now works with big threads too: