Compaction vs a Token Optimizer: What Each Saves

Q: 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.

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 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 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)
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, costs, settings reference) and the Codex docs (config reference, slash commands), read 2026-10-15. Tokenade figure: THOL benchmark, methodology here.

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, and also while you are away.

That last one is idle compaction. The settings reference 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 describes /compact as "Summarize the visible chat to free tokens", and the 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 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.
File reads come back structure-first, signatures before bodies, when the agent only needs to find its way. See skeleton compression for 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, so there the gain is smaller.

Anthropic recommends the same idea by hand. The costs page 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. 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 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, 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.

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 notes that "due to context rot, the model is at its least intelligent point when compacting". See 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.
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.

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.

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.