Claude Opus 4.5 and the compaction problem

Anthropic released Claude Opus 4.5 with a substantial price reduction relative to the previous Opus generation, an effort parameter for controlling reasoning depth, and improved context compaction.

The price cut is the headline for most users. The compaction work is more interesting.

the compaction problem#

Long agent sessions fill their context. Tool outputs, file contents, error messages, prior reasoning. Eventually you hit the limit and something has to go.

The naive approaches are all bad:

• Truncate the oldest. Loses the original task description, which is the single most important thing in the context.
• Truncate the middle. Loses the reasoning chain that got you here.
• Summarize everything. Loses specifics — file paths, error strings, exact values — that turn out to matter.

What you actually want is selective retention: keep the goal, keep the decisions and their rationale, keep the current state, discard the raw tool output that has already been acted on.

That is a judgment call, and doing it well requires understanding what the session is about. Which makes it a model problem rather than a buffer-management problem.

why this matters more than benchmark deltas#

For agent workloads, context management determines whether a long task succeeds far more than a few points of benchmark difference.

I have watched agent runs fail in exactly this way: two hours in, compaction drops a detail — a constraint from the original request, a decision made an hour ago — and the agent proceeds confidently in a direction that contradicts the task. Everything after that is wasted, and it looks productive the whole time.

If you are building on any model, the lesson to steal is: do not rely on the context window as your memory. Maintain durable state outside it.

task.md          — the goal, constraints, acceptance criteria. Re-read often.
notes.md         — decisions made and why. Appended, never rewritten.
state.json       — current progress, structured.

Feed those back in after every compaction. This is cheap, model-agnostic, and it is the difference between an agent that works for four hours and one that works for forty minutes.

the effort parameter#

Explicit control over reasoning depth, exposed to the caller. Everyone has this now under different names — thinking budget, reasoning effort, thinking config.

The convergence is total and it confirms the design conclusion: reasoning depth belongs to the caller, not the model, because only the caller knows whether this particular request justifies the latency and the cost.

Measure the quality-cost curve on your own task. The knee is usually much lower than people assume.

the price movement#

Frontier model pricing has fallen substantially across every provider over the past eighteen months, on a per-capability basis by considerably more.

Two implications:

Cost-optimization work has a short half-life. Elaborate infrastructure to shave token costs may be obsolete before it pays for itself. Build the thing; optimize when the bill actually hurts.

"Too expensive to do with a frontier model" is a moving line. Applications that did not pencil out a year ago may now. It is worth periodically revisiting the ideas you rejected on cost grounds, because the reason you rejected them keeps expiring.

the competitive picture#

Three labs shipping frontier releases within a week of each other, with capability differences small enough to be within evaluation noise on many tasks.

The practical consequence for developers: your model choice is a preference, not a lock-in, and it should be revisited quarterly rather than defended.

Build the abstraction. It is a day of work and it keeps paying.