Context Compaction for Coding Agents: OpenAI vs Claude vs Google ADK

Long-running coding agents do not usually fail because they cannot generate another token. They fail because the useful context gets buried, the tool transcript grows, or a summary drops the one detail needed for the next edit.

Context compaction is the runtime’s answer: compress older interaction history into a smaller representation so the agent can keep working. But “supports compaction” is not a meaningful comparison by itself. The trigger, ownership, persistence model, latency, and loss boundaries matter.

This article compares the current documented approaches in the OpenAI Agents SDK, Anthropic’s Claude API and Agent SDK ecosystem, and Google’s Agent Development Kit (ADK). It is a documentation-based comparison, not a benchmark. I verified the public docs on July 21, 2026 and did not run the same workload through all three stacks.

The evaluation criteria

I compared each option on five practical questions:

1. Where does compaction happen? In the provider API, SDK session layer, or an event processor?
2. What triggers it? A token threshold, event window, automatic policy, or an explicit call?
3. What survives? The answer matters more than the word “summary.”
4. How does it affect a coding workflow? Especially tool calls, file paths, test failures, and pending work.
5. What operational trade-off is documented? Latency, provider coupling, configuration effort, and auditability.

Quick comparison

Option	Main mechanism	Trigger/configuration	Best fit	Main trade-off
OpenAI Agents SDK	OpenAIResponsesCompactionSession around a session backend; the Responses API performs compaction	Automatic policy after a candidate threshold, or explicit compaction; previous_response_id and input modes are available	OpenAI Responses-based agents that need managed sessions and resumability	Provider-specific; compaction can delay the end of a streaming run
Claude API / Agent SDK	Server-side API compaction for long conversations; SDK-level patterns also exist	Configure a compaction edit and trigger threshold; server-side compaction is the recommended path for long-running work	Claude-first agents with large tool transcripts and long sessions	Summaries are lossy, and the API still needs careful preservation of durable state
Google ADK	Context compactors integrated into the event flow	Token-based or sliding-window compaction via EventsCompactionConfig; custom summarizer options	Session/event-oriented agents, especially when compaction policy belongs in the framework	More knobs to tune, and aggressive compaction can discard structured details

The table is a map of documented behavior, not a ranking. These systems do not expose identical abstractions, so “which is best” depends on where you want context policy to live.

1. OpenAI: compaction as a session wrapper

The OpenAI Agents SDK separates local application context from the context visible to the model. For conversation history, the SDK documents OpenAIResponsesCompactionSession, a wrapper around another session backend. It uses the Responses API’s responses.compact operation and can compact automatically after a turn when a configured threshold is reached.

Two details are easy to miss:

• The SDK can choose between compaction based on a chained previous_response_id and compaction rebuilt from the session’s current input items. The documented automatic mode chooses the safer available path.
• Compaction rewrites the session history. In streaming mode, the stream can remain open for a few seconds after the last output token while the compaction finishes.

That makes OpenAI’s approach attractive when the rest of your application already uses Responses sessions and you want the SDK to own persistence. It is less attractive if you need a provider-neutral local summarizer or if the user experience depends on the stream closing immediately.

A practical pattern is to separate user-visible completion from maintenance. If a coding agent is interactive and latency-sensitive, disable automatic compaction during the hot path and schedule an explicit compaction between turns or during idle time. If you do this, record the compaction boundary in your trace so an operator can tell why older tool output is no longer present.

2. Claude: server-side compaction for long-running conversations

Anthropic’s current API documentation recommends server-side compaction for long conversations and agentic workflows. When input reaches a configured trigger threshold, the API generates a summary in a compaction block. Subsequent requests can continue from that block, with earlier content dropped from the active context.

This is a useful distinction from a home-grown “take the last N messages” function. The API understands the conversation boundary and returns a continuation point. The trade-off is still real: a summary cannot preserve every compiler error, exact diff, or intermediate hypothesis.

The Claude Agent SDK builds on the same coding-agent model as Claude Code: tools, sessions, MCP, hooks, and resumable context. That is a strong fit for agents that spend many turns inspecting files and running commands. But the SDK’s capabilities do not remove the need for durable workflow state. A task checklist, changed-file manifest, failing test command, and unresolved decision should live in a structured artifact or external store, not only in the model transcript.

Anthropic’s cookbook also documents SDK-level automatic compaction patterns. Those are useful when you need application-controlled behavior or an older model path, but the current API docs make server-side compaction the default recommendation for long-running workloads.

3. Google ADK: compaction as event policy

Google ADK treats an agent session as a stream of events that includes user instructions, model responses, tool calls, and tool results. Its context compaction feature is integrated into the event flow with a CompactionRequestProcessor and EventsCompactionConfig.

ADK documents two main strategies:

• Token-based compaction, triggered by the volume of tokens or data.
• Sliding-window compaction, based on event or turn retention.

If both are configured, the docs state that token-based compaction takes priority when its threshold is exceeded. ADK also supports a custom summarizer, which gives teams more control over what “important” means for a domain.

That flexibility is valuable for coding agents, but it creates a tuning responsibility. A sliding window can be too blunt for a workflow where a tool call and its result must remain together. A token threshold can fire in the middle of a structured exchange. For code changes, I would preserve at least the current task, the latest test output, the changed-file list, and any pending approval outside the summarised event history.

What actually differs for coding agents?

Tool-call integrity

Compaction should not leave the model with a tool invocation but no result, or with a result whose file path is gone. The public docs describe different boundaries: OpenAI rewrites session history through Responses compaction, Claude emits a compaction block, and ADK compacts event history. None of those facts alone proves that every custom tool payload will be retained. Test your own tool schema and persist critical outputs separately.

State versus transcript

A transcript is not a database. It is a noisy record of reasoning, tool calls, and intermediate results. The safe design is to keep a small durable state object beside it:

authoritative_task_state = {
  'goal': 'Upgrade the auth middleware',
  'changed_files': ['src/auth.ts', 'tests/auth.test.ts'],
  'tests': {'command': 'npm test -- auth', 'status': '2 failing'},
  'next_action': 'inspect token-refresh failure',
  'approval_required': false
}

The exact storage mechanism can be a file, database row, session state, or artifact. The principle is the same: compaction may reduce context, but it must not be the only copy of operational truth.

Latency and cost

Compaction adds work. It may reduce later input size and improve focus, but the summary itself consumes model time and can add a visible pause. Measure total cost per completed task, not just tokens on the next request. This is the same reason prompt-cache hit rate is not a sufficient cost metric by itself: the workflow outcome matters.

Auditability

A production agent needs to answer “what did it know when it edited this file?” Keep a trace or event reference before compaction, the compaction timestamp, the summary or compaction identifier when available, and the durable state snapshot. This makes a lossy operation reviewable instead of mysterious.

What to do now

1. Inventory your long runs. Find sessions with repeated tool calls, large logs, or more than one feature-sized task.
2. Define protected state. Keep goals, changed files, test commands/results, approvals, and unresolved questions outside free-form history.
3. Choose the ownership boundary. Use OpenAI’s session wrapper if you are already on Responses; use Claude’s server-side compaction for Claude API conversations; use ADK’s event policy when you need token and window strategies in the framework.
4. Start with a conservative trigger. Compact between coherent task phases, not in the middle of a tool transaction.
5. Test recovery, not just continuation. After compaction, ask the agent to identify the current goal, changed files, last failing test, and next action. Fail the test if any answer is wrong.
6. Measure the whole workflow. Track compaction pauses, input tokens, tool errors, task completion, and rework.

Candid limitations

This comparison uses official documentation and small code sketches, not a controlled benchmark. Defaults, class names, model support, and API behavior can change quickly. The providers also expose different layers, so the table is not a feature-for-feature equivalence test. A successful summary on a conversational task does not prove safe preservation of a multi-file refactor. Validate with synthetic repositories and redacted traces before connecting production credentials or write-capable tools.

For a related reliability practice, see Stop Replaying Coding-Agent Bugs by Hand: Turn Traces Into Regression Tests. For the cost side, Prompt Caching for AI Coding Agents is a useful companion, but caching and compaction solve different problems.

Sources

• OpenAI Agents SDK sessions and Responses compaction
• OpenAI Agents SDK context management
• Anthropic API compaction
• Claude Agent SDK overview
• Google ADK context compaction

Discussion

What piece of coding-agent state has been lost or corrupted after a context reset in your own workflow, and where do you store it now?