Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude Code's compaction discards data that's still on disk

github.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Claude Code's compaction discards data that's still on disk

#11

Post by martinald »

antinomicus wrote: post #4
martinald wrote: post #3

Earlier quoted context omitted.

I'm fairly sure that Claude adds a note where it can find the original transcript after compactation (somewhat recently). Fwiw I built a little CLI that could help with this, https://github.com/martinalderson/claude-log-cli . It allows Claude to search its own logs very efficiently. So I'm sure you could add something like "if the session is continued from a previous one, use claude-log cli to find users original pro…

My Claude code started doing the compaction summary link thing but then stopped pretty soon after.

Yes I think the same here tbh, hard to keep up with.

Re: Claude Code's compaction discards data that's still on disk

#12

Post by CjHuber »

martinald wrote: post #10
CjHuber wrote: post #7

I honestly still don't see the point of compaction. I mean it would be great if it did work, but I do my best do minimize any potential for hallucination and a lossy summary is the most counterproductive thing for that. If you have it write down every important information and finding along a plan that it keeps updated, why would you even want compaction and not just start a blank sessions by reading that md? I'm kin…

Well a few things. Firstly, it's very useful to have your (or at least some) previous messages in. There's often a lot of nuance it can pick up. This is probably the main benefit - there's often tiny tidbits in your prompts that don't get written to plans. Secondly, it can keep eg long running background bash commands "going" and know what they are. This is very useful when diagnosing problems with a lot of tedious l…

I mean I agree the last couple of messages in a rolling window are good to include, but that is not really most of what happens in compaction, right?

> there's often tiny tidbits in your prompts that don't get written to plans.

Then the prompt of what should be written down is not good enough, I don't see any way how those tidbits would survive any compaction attempts if the llm won't even write them down when prompted.

>Secondly, it can keep eg long running background bash commands "going" and know what they are. This is very useful when diagnosing problems with a lot of tedious log prepping/debugging (no real reason these couldn't be moved to a new session tho).

I cannot really say anything about that, because I never had the issue of having to debug background commands that exhaust the context window when started in a fresh one.

I agree they are better now, probably because they have been trained on continuing after compaction, but still I wonder if I'm the only one who does not like compaction at all. Its just so much easier for an LLM to hallucinate stuff when it does have some lossy information instead of no information at all

Re: Claude Code's compaction discards data that's still on disk

#13

Post by peacebeard »

CjHuber wrote: post #7

I honestly still don't see the point of compaction. I mean it would be great if it did work, but I do my best do minimize any potential for hallucination and a lossy summary is the most counterproductive thing for that. If you have it write down every important information and finding along a plan that it keeps updated, why would you even want compaction and not just start a blank sessions by reading that md? I'm kin…

Works fine for me in sessions that use a lot of context. My workflow is to keep an eye on the % that shows how soon it will auto compact. And either /clear and start over, or manually compact at a convenient place where I know it'll be effective.

Re: Claude Code's compaction discards data that's still on disk

#18

Post by behnamoh »

g-mork wrote: post #15
behnamoh wrote: post #14

[flagged]

how do you make CC talk via a proxy? I had a few googles for this and got nowhere

set Anthropic base URL in CC to your proxy server and map each model to your preferred models (I keep opus↔opus but technically you can do opus↔gpt-5.3, etc.). then check the incoming messages for the string that triggers compaction (it's a system prompt btw) and modify that message before it hits the LLM server.

Re: Claude Code's compaction discards data that's still on disk

#19

Post by handfuloflight »

SatvikBeri wrote: post #16
behnamoh wrote: post #14

[flagged]

It's interesting that you find compaction trivial. I think it's one of the most important tasks, to the point where I use Amp these days because its "handoff" feature is so much nicer than CC's compaction.

What's nicer about their handoff feature?

Re: Claude Code's compaction discards data that's still on disk

#20

Post by grimgrin »

peacebeard wrote: post #13
CjHuber wrote: post #7

I honestly still don't see the point of compaction. I mean it would be great if it did work, but I do my best do minimize any potential for hallucination and a lossy summary is the most counterproductive thing for that. If you have it write down every important information and finding along a plan that it keeps updated, why would you even want compaction and not just start a blank sessions by reading that md? I'm kin…

Works fine for me in sessions that use a lot of context. My workflow is to keep an eye on the % that shows how soon it will auto compact. And either /clear and start over, or manually compact at a convenient place where I know it'll be effective.

i use https://github.com/sirmalloc/ccstatusline and when im around 100k tokens im already thinking about summarizing where we're at in the work so i can start fresh with it

it is pretty rare for me to compact, even if i let it run to 160k

--

just realized how i wouldn't think about using ccstatusline based a quick glance at its README's images. looks like this for me:

https://i.imgur.com/wykNldY.png

Post reply on HN