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.

[Jardo-51]

Yep, if you don't want to compact, you have to click the button that says "Compact".

[drake-nathan]

Oh wow, that's very confusing.

[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.

[Jardo-51]

From Claude: Compacting on send after expiry is a small saving that only shows up if you keep working in that thread for a long time. You pay for it with lossy, irreversible context loss, so it shouldn't be the default.

[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!

[buzinas]

This new default has been annoying me so much! I just realized that I'm not the only one. I have a PR for at least making this configurable (#19643), so please upvote, let's get this done!

[Neon-Wang]

Following the guidance in #20344, adding our reproduction and a small fork fix here.

At our source baseline (c9c839304d260679f9dd935b2b13e89ecd34e4f9), a stale Claude thread with 150k used tokens offers compact-before-send even with a 1M context limit. There is also a persistence detail: ChatView removes the Full-history override after a successful send, so the next eligible resume returns to Compact without a reload.

Our fork now starts the stale-resume chip in Full mode and stores the explicit Full/Compact choice per client, environment, and thread. A successful send no longer clears that preference. The implementation is in 09b5489eb (a fork patch, not an upstream PR).

In an isolated real browser with a 150k/1M expired-cache fixture, we verified Full by default, opting into Compact, persistence after reload, and switching away from the thread and back. This UI fixture did not run a real 150k-token provider turn. Preserving history can incur the uncached input cost; making that choice explicit is the behavior we wanted.

A persistent preference would address the accidental /compact plus queued-message behavior independently of whether the suggestion threshold becomes configurable.

[jerrypena1]

I totally understand that you're trying to fix a problem users have, but enough people have pointed out that doing it this way doesn't actually fix anything since the compacting happens after the cache has expired.

I have my own solution to this; which I'm sure most users don't, but not having a way to reliable control this makes the UX awful for an app that I literally use all day, everyday.

+1, until this is fixed, I'm going to have to stop using T3 Code. It's grossly unusable. I'm not even seeing the toggle button to turn compacting off, which already is enough of a hassle.

[hafifuyku]

An unexpected lossy action that can't be undone shouldn't be the default. Please make it opt-in.

[burakcbdn]

Would be nice to have a setting for this. With a 1M context window, compacting at 100k just because the cache expired feels too early. I often come back to long chats and still need the earlier details, so I’d prefer to keep the full history even if it costs more tokens.

[jonathanmeier5]

Would really appreciate the ability to turn this off, very frustrating.

[yhaberstam-levion]

Adding numbers from my own threads, since this discussion has claims about cost in both directions.

Today, on claude-opus-5-5 with the 1M window, compact-before-send ran three times, at 119,845, 162,098, and 217,557 tokens. Each one came back as a summary of 5.9k to 9.3k tokens. The SDK reported $0.50 and $0.75 for the first two compactions. Re-caching the full history instead would have cost about $0.96 and $1.30 at the 1h cache-write rate, and later turns read a much smaller context. So the feature does save something, but it's well under a dollar per resume.

The bigger cost is detail. A 160k thread squeezed into 6k loses file paths, decisions, and the dead ends I had already ruled out, and the only way back is forking the thread. Whether that trade is worth it depends on the thread. I'm fine compacting one I'm wrapping up with "commit and push". I don't want it on a thread where I'm in the middle of an investigation. The app can't tell those two apart, and I can.

So I'd ask that the user get to decide: a setting for the token threshold, with a Never option, and today's default for anyone who doesn't change it. #19823 asks for the same thing and was pointed here.

Could a maintainer approve that scope? CONTRIBUTING asks PRs to link an approval, and #18486 and #19643 were closed without one. I'm happy to open a focused PR once there's a yes.

[ViaxCo]

Heads up: the latest nightly adds Compact idle Claude threads (beta) in Settings > General (#21682). It is off by default.

But this is a different feature. It compacts idle threads before the cache expires. It does not turn off the Compact chip. The chip still starts on Compact for stale Claude threads, so Enter still compacts first. The one change is that the chip now shows only at 200K tokens, not 100K. So the off switch this discussion asks for is still missing.

[Jardo-51]

+1. This annoys me too, and it clearly annoys a lot of other people. Here are the issues reporting the same behavior. All of them were closed without a fix:

• [Bug]: Sending with the "Resume with less context" banner showing silently runs /compact first #15769: sending while the resume banner shows runs /compact first. It was fixed by reverting the feature (revert(web): remove automatic compaction before resume #15771), then the feature came back as the default-on chip (feat(web): old Claude threads compact on send instead of stacking notices #16631, feat(web): compact-before-send is a chip that shows the token count #17127).
• [Bug]: Enter on a stale Claude thread runs /compact first by default (regression of #15769) #17467: Enter on a stale Claude thread runs /compact first by default. Many +1s and reports of lost work. Closed as working as intended.
• [Bug]: Idle threads compact on the first message after the cache is cold; add an off switch or a timed idle compaction #19182: idle threads compact on the first message after the cache goes cold. Closed as a duplicate.
• [Bug]: Sending on an idle Claude thread compacts its history without asking #20287: sending on an idle Claude thread compacts its history without asking. Closed as a duplicate.
• Make auto-compact-before-send configurable (it compacts long before the context window is full) #20344: make auto-compact-before-send configurable, since it compacts long before the context window is full. Closed as a duplicate.

Four separate PRs also tried to add an off switch: #15773, #17234, #18486, and #19643. All four were closed without merging.

#21682 (Compact idle Claude threads) is welcome, but it doesn't solve this. The chip still starts on Compact, so Enter on a stale thread still compacts. Please add a persistent setting to turn compact-before-send off, or make it opt-in.

[thlokol]

+1 for a real setting. My workflow is the same as several people here: I regularly go back to long Claude threads (1M window) hours or days later, and I need the earlier details. Compacting is almost never what I want there.

What makes it bite in practice:

• The chip starts on Compact and looks like part of the send control, so a normal Enter/Send quietly runs /compact first, and that can't be undone.
• Picking Full only lasts for that thread and is lost on reload, so I keep having to remember it.
• The localStorage workaround above (t3code:resume-compaction-dismissed:<environmentId>:<providerInstanceId>) does work, but it needs DevTools and has to be redone for each environment and client.

A toggle in Settings → General that sets that same flag (or defaults the chip to Full) would fix this without changing the default for everyone else. An explicit "Compact context" from the context meter would still be there for people who want it.

[thlokol]

I just answered some questions that contain very important context. Afterward, I sent a follow-up to correct a small detail. Everything got compacted. Damn...

[psicilia5179]

+1 for a real setting. One more angle now that #21682 is merged.

#21682 adds Compact idle Claude threads (beta), and it's off by default. So the automatic version is opt-in. The compact-before-send chip is still on by default, and the only way to turn it off is per-client localStorage (what "Don't ask again" writes). The chip threshold moved to 200k, but 200k is still small on a 1M-window model.

The two behaviors should follow the same rule: whoever wants compaction opts in. Any of these would fix it:

1. A Settings → Providers → Claude toggle to turn off compact-before-send, synced per environment instead of per browser.
2. Or a threshold setting with a Never option (what [Feature]: Make stale Claude resume-compaction token threshold configurable #19823 asked for, before it was redirected here).
3. Or keep the chip but default it to Full, so Enter sends normally and compacting is the one-click choice.

On cost: compacting a stale thread isn't free. The /compact turn itself re-reads the whole context uncached, which is the cost it's meant to avoid. It only saves anything if the thread runs several more turns afterward. A thread I come back to for one or two questions comes out roughly even and loses its history. That trade-off should be the user's call.

[goleary]

Workaround if you can't paste into the DevTools Console (typing allow pasting didn't unblock it for me in the desktop app): open DevTools (Alt → View → Toggle Developer Tools), go to the Storage tab → Local Storage, and add the entries by hand. Double-click the empty row, type the key t3code:resume-compaction-dismissed:<environmentId>:<providerInstanceId>, set the value to true (one row per Claude instance), then Ctrl+R.

That this takes DevTools at all is the problem. This change has been really disruptive: I lost the working context of two long threads before I understood what the chip was doing, and since then I've had to second-guess every send on an old thread. Compacting can't be undone, so it shouldn't be what a normal Enter does by default. Please make compact-before-send opt-in, or add a setting to turn it off. More broadly, I hope you'll think about how people actually work in long threads before shipping a default change like this again, especially one that throws away history.

[arielpollack]

+1, with numbers from an API-billed setup, because the chip behaves very differently there.

I use Claude through Vertex. API keys and Bedrock work the same way: the prompt cache lasts 5 minutes, not 1 hour. Since #17945 tied the chip to the real cache TTL, it now appears once a thread over 100k tokens has been idle for about 5 minutes. On a subscription that takes an hour. For me, a coffee break is enough.

From my provider logs for Oct 18–20 (claude-opus-5-5, 1M window): compact-before-send ran 13 times, each time when I just sent a normal message on a stale thread.

• 5 of the 13 fired after only 6–15 minutes idle.
• Each one held up my actual message for 56–100 s, about 17 minutes in total.
• Together they cost $20.21. Writing the same 3.61M tokens of context back into the 5-minute cache would have cost $18.05, using the per-token rates the SDK reports for these same sessions ($5/M for cache writes). So the compaction cost about 12% more than the cold resume it was meant to avoid. It only pays off if the thread keeps going for a while afterward. Meanwhile, each of those threads lost its history to a summary of 8k–23k tokens.

So for anyone who isn't on a subscription, the default doesn't save money on the resume, destroys context with no way back, and fires several times a day. I'm asking for the same thing as others here: a real setting (Never, or a threshold), or make Full the chip's default. #21682 made the automatic idle compaction opt-in. The chip should be opt-in too.

[sintypitch]

+1. The chip looks like a separate action, not a toggle. I never clicked it, typed my message as usual, and every Enter or Send still ran /compact first. I assumed that once the chip shows, you cannot send without compacting. Four of my sends yesterday were compacted this way, none on purpose (T3 Code 0.1.0, macOS, Claude).

[sintypitch]

Follow-up: I checked the 0.1.0 code. The chip is a toggle, but most people probably don't know that, it looks like a button. And it resets to Compact after every send, so you have to switch it off again every time it shows up.

[Blackskyliner]

Auto activating an option which is not visible all the time but after any kind of condition is bad UX in general. Never take the control from the user or change UI states. Because it seems to also happens in active chats if you are just idle, e.g. switching windows, or being afk and getting back to it.

I get it, if its not enabled by default, fewer people might use it or overlook it, but that's better than enforcing it on everyone. Especially as it stomps context and caches and makes preprocessing costly esp. if it then needs to reference its own compressed log or previous thread messages again to get the full context back working on your task.

[brettdh]

Getting bitten by this multiple times every day. Despite what the bot-closure message on #19643 says:

Right now we're only taking focused bug fixes from outside contributors (see Read this first), and this PR is not one.

Annoying this many (gestures around at these comments) users with unintentional destructive actions is definitely a bug, and there have been many PRs attempting a focused fix.

[OneClickSystems-UK]

It's a toggle???????? I thought it was a button this whole time and have avoided pressing it again 😂 😂 😂 Definitely needs to be kept as a setting in settings - with opus 5.5 and the rate I use it I'm more than happy to not compact

[borzaka]

+1 for a setting. I'm seeing the same thing on T3 Code 0.1.0 (Linux desktop) with claude-opus-5-5 and the 1M window.

The Compact chip appears at 200k tokens, which is 20% of the window. The meter right above it says the context "compacts automatically when needed", so nothing tells me the next Send will compact:

I sent a normal message, and it ran /compact first (311k/1m in this case):

A Claude provider setting to turn compact-before-send off would fix this for me. A threshold with a "Never" option, as #19823 asked, would work too.

[yuriharrison]

Please make this opt-in. Compaction replaces the whole conversation with one lossy summary: my messages, the agent's messages, every tool result. The only recovery is forking from before the /compact, if I even notice the mistake in time.

The chip starts on Compact and Enter, pure muscle memory, runs /compact before my message. One unnoticed Enter destroys a thread.

A Never setting, or Full as the default. The localStorage flag isn't a reasonable off switch.

[borzaka]

They are forcing us to stay in the smart zone :)

From: https://www.linkedin.com/pulse/llm-context-window-degradation-know-when-your-ai-checks-almeida-aezhf/

[sintypitch]

I noticed today it even automatically /compact's when during a big session with multi-agents I get a compact prompt...