[Bug]: Forge absolutely BURNS the tokens

[Alexx999]

Bug Description

I've been trying out the forge (again), this time on slightly larger task. I haven't been able to finish even the planning phase due to EXTREME (trust me: not overstating here, all caps warranted) token burn.
It burned through two "20x" 5h usage windows in ~1hr (end of one window and fully burned the next one) and about 20% of weekly usage while doing some back-and-forth on plan/docs.
Some absolutely extreme spikes observed (3% weekly usage in single go).

It seems that it's mostly a combination of poor caching strategy and overeager compaction (I've been using the default settings), there's repeated 200k token requests with only 17k tokens cached, turn after turn.

Luckily, I've been trying it with a small personal project, so here's a cutout from the logs/sqlite. I should be able to provide anything else you need.
bug-report-token-burn-2026-04-18.zip

Steps to Reproduce

1. Start the forge with default settings
2. Select Opus 4.7 (or 4.6, shouldn't be much different)
3. Do some long-ish back-and-forth
4. Watch your usage

Expected Behavior

Usage is roughly the same as the other harnesses

Actual Behavior

It absolutely BURNS the tokens

Forge Version

0.1.0 (latest main)

Operating System & Version

Win11

AI Provider

Anthropic

Model

opus-4-7

Installation Method

Built from source

Configuration

[Alexx999]

@tusharmath it's not the sage, at least from what I can tell.
I did somewhat weird pattern to make it do plan iterations in a very specific way, so I've prepped the plan with muse and then iterated on it with forge. Big chunk of the work is collecting open source headers and online docs on PDB file format, and writing an MD doc on it - that has to stay internally consistent and needs many minor tweaks and corrections and checks, and "muse" doesn't align with this "minor chatty back and forth" workflow well.
So, I've asked forge to offer a fix for a plan problem and then apply this fix to plan and docs md as a separate turn.

[Alexx999]

If I'm reading the log correctly, the problem is broken compaction:
170 out of 176 messages in the conversation are compaction messages
It estimates token count as chars/4, but due to huge amount of markdown with lots of backticks/pipes/JSON-like fragments in summaries, the real token count is more like chars/3
Each compaction appends a new "Use the following summary frames..." user message without removing earlier ones. After 170 compactions, the conversation is a stack of 170 summary messages. In the log above, that is 527,760 chars ≈ 176 K tokens of just compaction output.

Overall: the conversation is poisoned by compaction. Running compaction once at 100 K against a conversation that's mostly prior-compaction summaries produces a new summary of hose summaries, then another, then another.

Also, that means that with default settings (100k threshold) the compaction will run every turn, effectively killing the conversation and doing the "token BURN" event I've experienced.