A setting to turn off compact-before-send on stale Claude threads

[yashaka]

Problem

Since #16631 (and its chip form, #17127), a Claude thread with 100k+ tokens that has been idle for 70+ minutes compacts on send: Enter runs /compact first, then sends the message. The chip/menu lets me skip that for one send, and the choice resets (per thread, and on reload/remount).

For some workflows compaction is never the right default. I keep long-lived agent sessions whose state I manage outside the transcript (durable notes in the repo, re-read on resume), and I deliberately resume old threads with full history, accepting the cold-cache cost. For me an accidental Enter is an irreversible loss of the conversation's working context — and the default is the destructive path on every stale thread, every time.

There is already a permanent off switch in the code — the t3code:resume-compaction-dismissed:<environmentId>:<providerInstanceId> localStorage flag — but the only UI path that sets it is answering "Don't ask again" on Claude's own resume dialog, which (per the #16631 notes) practically never appears under the v2 orchestrator. Today the only way to turn the offer off is DevTools → localStorage.setItem(...) per environment and per client.

Proposed behavior

A client setting, e.g. Settings → General → "Compact stale Claude threads before sending" (on by default is fine), that:

• when off, never shows the Compact chip and never prepends /compact — sends always keep full history;
• maps to (or replaces) the existing dismissal flag, so it applies across environments viewed in that client;
• leaves Compact context in the context meter available for an explicit compaction.

Related: #17111 (the chevron that offers the opt-out does nothing in a resting composer, so every send compacts).

[moinmir]

Would like this to be configurable as well.

[Zedyas]

+1. This is an issue I'm facing in T3 Code right now. Here is data from my own threads, plus one gap I don't see covered here yet.

Data (nightly builds from Oct 8–9; current build 0.0.46-nightly.20261008.2849). Each row is a pre-send /compact from the chip. My actual message followed 17–56 ms later and went into the queue. All are Claude threads with a 1M context window, and Auto-compact after is set to 500000.

When (UTC)	Tokens in context	Idle before send	What happened
Oct 8 13:47	423,515	847 min	I stopped it after 12 s
Oct 8 13:49	460,668	835 min	I stopped it after 6 s
Oct 8 18:36	350,594	213 min	I stopped it after 12 s
Oct 8 22:25	138,028	74 min	I stopped it after 5 s
Oct 9 00:31	272,206	99 min	I stopped it after 6 s
Oct 9 01:14	113,327	158 min	compacted before I noticed
Oct 9 03:06	111,770	82 min	I stopped it after 3 s
Oct 9 03:08	200,591	76 min	I stopped it after 13 s

Each time, I pressed Enter to reply to the agent, not to compact.

Gap not covered yet: the 100K threshold ignores "Auto-compact after". All 8 were below the 500K limit I set on purpose to keep long sessions intact. Compact-before-send uses a fixed 100K threshold and never reads autoCompactWindow.

What would fix it for me:

1. The persistent setting proposed here (feat(web): add a setting to turn off compact-before-send for old Claude threads #17234 implemented it; its author closed it without merging).
2. When autoCompactWindow is set, compact-before-send only applies at or above that value.

[m9tdev]

Data point from a 1M-context model (claude-opus-5-5): my last 4 compact-before-send runs happened at 172k, 409k, 435k and 521k tokens, after 1h20m to 17h idle. Compaction lost detail I needed later. +1 for the opt-out setting in #18486.

[theDanielJLewis]

🤦‍♂️ And here I was thinking that this button that says "Compact" actually meant "Compact":

As in, "press this button to compact." I didn't realize it's a toggle button.

So that's some majorly misleading UI there.

[scmart]

This one terrible ui/default decision has probably burned hundreds of millions of tokens by now.

[robertnisipeanu]

This is totally useless anyway. Compacting is done by the same model and will consume the same amount of uncached tokens as sending a prompt directly in the chat. There is no advantage of doing a /compact on a stale (expired cache) thread over just sending the prompt directly.

[rohitgirdhar]

This feature (bug?) is making t3 code borderline unusable... could the maintainers take a look? cc @t3dotgg @maria-rcks @juliusmarminge

[rodalpho]

This is intensely annoying as my cache TTL is 5 min.

Anyway you can turn it off with the dev console

localStorage.setItem("t3code:resume-compaction-dismissed", ask your agent for the proper syntax etc.

[charlesjones-dev]

Workaround until #19643 or a similar setting lands. It hides the Compact chip for good, so Enter and Send keep the full history.

The localStorage key needs both your environment ID and the provider instance ID: t3code:resume-compaction-dismissed:<environmentId>:<providerInstanceId>. The key name on its own does nothing. Each Claude instance needs its own key, so if you've added custom instances (a second Claude home, another account), the default claudeAgent key won't cover them.

1. Run this in a terminal. It reads your environment ID and Claude instances and prints the line to paste:

python3 -c 'import json,os; h=os.path.expanduser("~/.t3/userdata/"); e=open(h+"environment-id").read().strip(); p=json.load(open(h+"settings.json")).get("providerInstances",{}); ids=sorted({"claudeAgent",*[k for k,v in p.items() if v.get("driver")=="claudeAgent"]}); print("%s.forEach(id=>localStorage.setItem(`t3code:resume-compaction-dismissed:%s:${id}`,\"true\"));location.reload()" % (json.dumps(ids), e))'

2. In T3 Code, open View → Toggle Developer Tools (⌥⌘I) and go to the Console tab. Paste the printed line and press Enter. If the paste is blocked, type allow pasting first. The app reloads.

Run it again after adding a Claude instance. Clearing the app's data removes the keys.

Checked against ChatView.tsx on main and 0.0.46-nightly.20261014.3105.

[playcations]

This feature is why theo needs 8 claude accounts

[rodalpho]

Funny, but I don't even get the reasoning behind it. Why would you want to auto-compact based on cache expiry? Once the cache expires, compacting is an expensive operation-- you want to compact BEFORE it expires, not after, if you could somehow see the future and compact before walking away that would be useful.

[ViaxCo]

#19662

@rodalpho Looks like this PR does what you're saying.

[rodalpho]

Maria ahead of the game as always!