# Compaction vs a Token Optimizer: What Each Saves

> Compaction cleans up after the context has filled; a token optimizer stops it filling so fast. What each one saves, what each one loses, and why you want both.

Source: https://tokenade.net/en/articles/compaction-vs-token-optimizer · Updated: 2026-10-18

Native compaction and a token optimizer are not competitors: compaction cleans up the context after it has filled, a token optimizer slows down how fast it fills. Use both. If you can only change one thing, change what enters the context, because compaction never refunds the turns you already paid for.

That distinction sounds academic until you look at a long session. A 20,000-token test log that lands at turn 10 rides along in every request until the next compaction. `/compact` eventually turns it into a sentence. It does nothing about the thirty turns that carried it in full.

Part of the [reduce Claude Code token usage](https://tokenade.net/en/articles/reduce-claude-code-token-usage) pillar. If you want the cost mechanics of `/compact` itself (warm cache, cold cache, what survives), read [Claude Code /compact: what it costs and what survives](https://tokenade.net/en/articles/claude-code-compact) first. This page does not repeat it.

## Compaction vs a token optimizer at a glance

| | Native compaction | Token optimizer |
|---|---|---|
| What it is | The agent summarises its own history (`/compact`, auto-compact, idle compaction) | A layer that compresses tool output, file reads and manifests at the tool boundary |
| When it acts | After the context has grown, near a threshold or on demand | Before each tool result enters the context |
| Entry price | Included in Claude Code and Codex | Tokenade: 7-day free trial, then 1% of the value saved (see [pricing](https://tokenade.net/en/pricing)) |
| Best for | Keeping one long task going past the window limit | Long, tool-heavy sessions where output and file reads dominate |

Behaviour of `/compact`, auto-compact and idle compaction: read in the Claude Code docs ([context window](https://code.claude.com/docs/en/context-window), [costs](https://code.claude.com/docs/en/costs), [settings reference](https://code.claude.com/docs/en/settings-reference)) and the Codex docs ([config reference](https://learn.chatgpt.com/docs/config-file/config-reference), [slash commands](https://learn.chatgpt.com/docs/developer-commands?surface=cli)), read 2026-10-15. Tokenade figure: [THOL benchmark](https://tokenade.net/en/thol), [methodology here](https://tokenade.net/en/thol).

## How I compared them

I build Tokenade, so take the framing with that in mind. I compared the two on four questions: at which moment each one acts, what it removes, what it costs to run, and what the model loses as a result.

I did not compare savings percentages. Compaction has no single "saving" to quote: it depends on how big the history was and what the summary kept. The only measured number on this page is Tokenade's own, and it is a whole-session cost figure, not a per-tool one.

## What native compaction actually does

**Compaction replaces the conversation history with a summary the model writes.** Claude Code runs it when you type `/compact`, automatically "as you approach the limit, so a full context window doesn't end your session", per the [context window docs](https://code.claude.com/docs/en/context-window#what-survives-compaction), and also while you are away.

That last one is idle compaction. The [settings reference](https://code.claude.com/docs/en/settings-reference#idlecompaction) says it compacts a long conversation "shortly before its prompt cache expires", after about 54 minutes idle, on sessions using the one-hour cache whose context passed a threshold that defaults to 200,000 tokens. Your next message then sends a summary instead of the whole conversation.

Codex has the same pair of mechanisms. Its [slash command list](https://learn.chatgpt.com/docs/developer-commands?surface=cli) describes `/compact` as "Summarize the visible chat to free tokens", and the [config reference](https://learn.chatgpt.com/docs/config-file/config-reference) exposes `model_auto_compact_token_limit`, the "token threshold that triggers automatic history compaction", unset by default so each model uses its own value.

Claude Code also trims in a smaller way. The [costs page](https://code.claude.com/docs/en/costs#prompt-cache-statistics) mentions Claude Code "clearing old tool results from context" and counts the resulting cache miss as an expected rebuild. Same family: it removes content that already entered and was already billed.

## What a token optimizer actually does

**A token optimizer works on each tool result before the model sees it.** Nothing is summarised after the fact. The command output, the file read or the tool manifest arrives already smaller, and stays smaller on every later turn that re-sends it.

Tokenade does this with hooks on the agent's tool calls, or a local proxy where the agent has no usable hooks. Concretely:

- **Command output** is filtered: progress bars, repeated lines and passing tests go, errors and the lines around them stay. See [output filtering for command logs](https://tokenade.net/en/articles/output-filtering-command-logs).
- **File reads** come back structure-first, signatures before bodies, when the agent only needs to find its way. See [skeleton compression for file reads](https://tokenade.net/en/articles/skeleton-compression-file-reads).
- **MCP manifests** are deferred on agents that load every tool description up front. Claude Code now defers MCP tool definitions by default, per its [costs page](https://code.claude.com/docs/en/costs#reduce-mcp-server-overhead), so there the gain is smaller.

Anthropic recommends the same idea by hand. The [costs page](https://code.claude.com/docs/en/costs#offload-processing-to-hooks-and-skills) suggests a hook that greps a log for `ERROR` instead of letting Claude read 10,000 lines, and describes it as "reducing context from tens of thousands of tokens to hundreds". That is their example, on one log, not a session figure. A token optimizer is that hook, written for every common tool.

## What each one saves

**Compaction saves the tokens of everything after it; an optimizer saves tokens on every turn, starting with the first.** That difference in timing is the whole comparison.

Every turn re-sends the full conversation, which is why [the context window drives your token bill](https://tokenade.net/en/articles/context-window-token-bill). A bulky tool result is therefore paid once when it arrives, then again on every following turn, mostly at cache-read price, until something removes it.

| | Native compaction | Token optimizer |
|---|---|---|
| Tokens before the cleanup | Paid in full, on every turn | Never entered |
| Tokens after the cleanup | Replaced by a short summary | Already small |
| Cost of the cleanup itself | One extra request carrying the whole history | Local processing, no extra model call |
| Effect on the window limit | Resets it | Pushes it further away |
| Effect on how often you compact | None | Fewer compactions per session |

The third row is easy to forget. Compaction is itself a model request that reads your entire history, at cache price if the cache is warm and at full input price if not. The [compact article](https://tokenade.net/en/articles/claude-code-compact) has the arithmetic. An optimizer runs on the computer you work on and never calls the model.

Here is the measured part. On the published [THOL benchmark](https://tokenade.net/en/thol), Tokenade cuts session cost by 39% on long sessions, against running no tool at all. How the sessions and the control are set up is on the [methodology page](https://tokenade.net/en/thol).

## What each one loses

**Compaction loses detail you did not know you needed; an optimizer loses detail the filter judged irrelevant.** Both are lossy. They fail differently.

Compaction is the riskier of the two, for three reasons:

- It summarises at the worst moment. Anthropic's [session management post](https://claude.com/blog/using-claude-code-session-management-and-1m-context) notes that "due to context rot, the model is at its least intelligent point when compacting". See [context rot](https://tokenade.net/en/glossary/context-rot).
- It drops whole categories by design: path-scoped rules, nested CLAUDE.md files, context injected by hooks, and the content of any re-read file over 5,000 tokens, per the [context window docs](https://code.claude.com/docs/en/context-window#what-survives-compaction).
- It cannot guess where you are going next. A warning you skipped at turn 12 is gone when you ask about it at turn 40.

An optimizer's failure mode is narrower: it drops a line in a log or a function body the agent actually needed. The agent then re-runs the command or reads the file again, which costs a turn. Tokenade keeps the full output on your computer and lets the agent fetch it back by reference, so a bad filter costs a lookup rather than a re-run.

There is a quality argument for the optimizer too. A context with fewer noise tokens is a context that rots more slowly, so the summary you eventually get is written by a sharper model.

## Why they stack

**They act at different moments on different content, so neither cancels the other.** The optimizer reduces what each turn adds. Compaction resets what has accumulated. Run both and you get smaller turns, a slower climb, and fewer, cheaper compactions.

Picture the curve of context size across a session. Without an optimizer, it climbs steeply, hits the auto-compact threshold, drops, climbs again. With one, the slope is flatter. The threshold arrives later, so you compact less often, and each compaction reads a smaller history.

Nothing about native compaction needs to change for this to work. Keep auto-compact on, keep idle compaction on, and keep running `/compact` with a focus instruction at natural breaks. The optimizer only changes what those mechanisms have to clean up.

The one place they touch: content the optimizer shrank is also what compaction later summarises. That is fine. A summary of a filtered log is no worse than a summary of the raw one, and it was cheaper to carry.

> Keep the context small before it fills: Tokenade compacts command output, file reads and MCP manifests at the tool boundary, and leaves /compact to do the rest.
>
> Install: `npm install -g @tokenade/cli && tokenade install && tokenade login` — or let your agent do it: https://tokenade.net/install.md

## Does this change for Codex and other agents?

**No, the split is the same.** Every serious coding agent has some form of history compaction now, because without it a long session simply ends at the window limit. Codex has `/compact` and `model_auto_compact_token_limit`; Claude Code has `/compact`, `/autocompact` and idle compaction.

What varies is how much each agent does at the tool boundary. Claude Code defers MCP tool definitions by default; others load every manifest before your first message. Where the agent does less, an optimizer has more to take.

If you work under a plan rather than an API key, the same logic applies to your limits. Fewer tokens per turn means the five-hour window lasts longer, which is the subject of [Claude Code limits: how to stay under them](https://tokenade.net/en/articles/claude-code-token-limit).

## Which one should you rely on?

- **Short sessions, one task each:** native compaction is enough, and `/clear` between tasks does more than either.
- **Long sessions with lots of builds, tests and logs:** add an optimizer; this is where tool output dominates the bill.
- **Large codebases where the agent reads whole files:** add an optimizer for structure-first reads.
- **Sessions you leave idle for an hour:** let idle compaction do its job, it is cheaper than compacting cold.
- **Everyone:** run `/compact` yourself at natural breaks rather than waiting for the threshold.

## FAQ

### Is auto-compact enough to keep Claude Code costs down?

It keeps the session alive, which is a different goal. Auto-compact fires near the window limit, so every bulky tool result before that point is re-sent on every turn. It also costs a request of its own that reads the whole history. It caps the context; it does not shrink what each turn adds.

### Does a token optimizer replace /compact?

No. An optimizer slows down how fast the context grows, but a long enough session still reaches the limit. Keep `/compact` and auto-compact on. With an optimizer in place, they simply fire less often and summarise a smaller history.

### Can a token optimizer make compaction worse?

Not in practice. Compaction summarises whatever is in the context. If a log was already filtered to its errors, the summary has less noise to sift through. The real risk is the optimizer dropping a detail the agent needed, which it then fetches again.

### Does Codex compact the same way as Claude Code?

The idea is the same: a `/compact` command that summarises the chat, plus automatic compaction at a token threshold set by `model_auto_compact_token_limit` in `config.toml`. Leave it unset and Codex uses the model's default. The thresholds and what survives differ by agent, so check each one's docs.

## See also

- [Claude Code /compact: what it costs and what survives](https://tokenade.net/en/articles/claude-code-compact): the cost mechanics this page builds on
- [How the context window drives your token bill](https://tokenade.net/en/articles/context-window-token-bill): why every turn re-sends everything
- [Output filtering for command logs](https://tokenade.net/en/articles/output-filtering-command-logs): the biggest pre-context lever
- [Skeleton compression for file reads](https://tokenade.net/en/articles/skeleton-compression-file-reads): structure-first reads in detail
- [Claude Code limits: how to stay under them](https://tokenade.net/en/articles/claude-code-token-limit): where both fit when you are close to a plan limit