Compact cold Claude threads on a cheaper model, such as Haiku 5.5

[0xFFord]

Problem

When a large Claude thread has gone cold, the Compact chip runs /compact on the thread's own model. Claude Code always compacts on the session's current model, so an Opus thread pays Opus prices to re-read its whole history once more, only to throw it away. As one comment in #17170 says, a cold compaction then costs nearly as much as just sending the message.

Claude Code has no setting for the compaction model. But if the model is switched first, /compact runs on the new one. I checked this on Claude Code 2.1.299: in an Opus session, /compact was billed to claude-opus-5-5. The same session, resumed with --model haiku, billed its compaction to claude-haiku-5-5, and Opus got nothing extra. Both runs wrote a compact_boundary.

I do this by hand now: switch the thread to Haiku 5.5, send /compact alone, switch back to Opus.

Cost and time, measured

I compacted forks of three of my cold Opus threads (231K to 342K tokens) once with Opus 5.5 high and once with Haiku 5.5 high. Costs are Claude Code's own costUSD at list prices; times are durationMs from the compact_boundary.

Compaction of a cold thread	Cost	Time
Opus 5.5 high	$1.26 to $1.74	34 to 73 s
Haiku 5.5 high	$0.15 to $0.20	37 to 75 s
Haiku 5.5 xhigh (one run)	$0.22	180 s

Haiku at high is 8 to 9 times cheaper, about $1.3 saved per compaction at 300K, and takes about as long.

The first Opus turn after the switch back is a cold one, but it is cold after an Opus compaction too: the summary is new text, so Opus writes it to its cache either way. That first turn cost $0.26 to $0.45 after an Opus compaction and $0.28 to $0.50 after a Haiku one; the summary's length made the difference, not the model switch. So it does not eat into the saving.

A warm compaction should stay on the thread's model, which reads its own cache at $0.20 per million tokens. A cheaper model only pays off on a cold thread, which is exactly when the Compact chip appears.

Proposal

A Claude instance setting, Cold compaction model: "Same as thread" (default, so nothing changes for anyone else), Haiku 5.5, or Sonnet 5.5. It could also be a choice on the Compact chip itself, so a user can keep Opus for a research thread. When a compaction starts from the Compact chip or the resume offer on a cold thread, T3 switches the live process to that model, sends /compact, then switches back to the thread's model before the next turn.

The plumbing exists on main:

• compactThread already sends /compact as a turn (apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts:9161).
• A model change already applies to the live process with setModel when it can, without a restart that would kill background agents (ClaudeAdapterV2.ts:8417).

This fits with #18713 and #14233, which compact before the cache expires. That path is warm and should keep the thread's model. This proposal covers the threads that went cold anyway.

Quality

I wrote 10 questions per thread with answers before forking, then asked an uncompacted copy, the Opus-compacted copy and the Haiku-compacted copy the same questions (answered by Opus 5.5, no tools). A separate Opus judge scored them blind.

Thread	No compaction	Opus compaction	Haiku compaction
Long agent run, state kept in files and commits	9.0	8.5	8.0
Email drafting over several rounds	9.5	8.0	8.0
Research and Q&A, findings only in the chat	10.0	9.5	6.5

On the first two, Haiku's summary was about as good as Opus's. On the research thread it dropped measured figures and the reasons behind decisions, and stated a few things that did not happen. Across the three Haiku summaries the judge found 13 statements that contradict the transcript (several minor), against 2 minor ones in the Opus summaries. This is three threads with one run each, so it shows a direction, not a rate.

Higher effort did not fix that. On the research thread I ran Haiku three more times: at high again (7.5), at high with /compact instructions naming what to keep (7.5), and at xhigh (7.0, and 2.5 to 5 times slower). Opus had scored 9.5 there.

So the setting should stay opt-in, and it suits threads whose work is saved in files. It is a poor fit for a thread whose findings exist only in the conversation.

Workaround today

Pick Haiku 5.5 in the composer, send /compact as its own message (not "Compact and send", or your message also runs on Haiku), then pick your model again.