A new control for individual subagents
Anthropic released Claude Agent SDK for TypeScript 0.3.296 on October 9, 2026, giving individual subagents a control for earlier compaction. The autoCompactWindow field on AgentDefinition lets a subagent compact before the main conversation’s window. For a subagent carrying findings into a coding task, this creates a tuning decision: retain more history or summarize sooner. Evaluating that choice means checking what survives and how much work follows. Sources: Anthropic
The SDK exposes Claude Code capabilities programmatically, including repository exploration, file editing, and command execution. Version 0.3.296 declares parity with Claude Code 2.1.296 and adds claude_code_version to the initialization response. The release also doubles the upfront limit for MCP tool descriptions and server instructions, from 2,048 to 4,096 characters. Keep comparison runs on the same release so these other changes do not affect the experiment. Sources: Anthropic
Compare complete tasks
Anthropic describes compaction as summarizing conversation history and continuing with a smaller context. Its Claude Code example retains architectural choices, outstanding bugs, and implementation details while removing redundant material. The company warns that aggressive compaction can lose subtle information needed later and recommends tuning against complex traces. A useful comparison therefore measures completed workflows, including recovery work, rather than summary size alone. Sources: Anthropic
Whether earlier compaction in SDK 0.3.296 reduces total tokens while preserving constraints and final quality remains an open question. The protocol below proposes a test; it does not report completed runs. Anthropic’s release announcement does not specify the field’s complete type, accepted values, precedence, or exact trigger calculation. Inspect the installed, pinned package before configuring the experiment. The table below outlines potential benefits and costs to measure. Sources: Anthropic
Table
Potential benefits and costs of earlier compaction
| Potential benefit of earlier compaction | Potential cost to measure |
|---|---|
| Smaller contexts on subsequent calls | Extra summarization work |
| Earlier removal of irrelevant tool output | Loss of evidence whose relevance emerges later |
| Less accumulated distracting material | More rereads, repeated searches, and repeated reasoning |
| More room for subsequent tool results | More compaction cycles and possible cumulative drift |
Existing evaluations measure different outcomes
Factory evaluated hundreds of compression points drawn from 36,611 messages in opted-in production software-engineering sessions. It compared identical conversation prefixes using probes for recall, artifacts, continuation, and decisions, with a blinded GPT-5.2 judge. Factory reported overall scores of 3.70 out of 5 for its method, 3.44 for the Anthropic condition, and 3.35 for the OpenAI condition. This vendor-run evaluation measures responses after compression, rather than completed-task cost or the new SDK control. Its useful testing principle is to check whether the agent can continue accurately, including tracking which files changed. Sources: Factory
The authors of Lost in Compaction examine session constraints: instructions intended to remain binding throughout a task. Their abstract reports that retention varies with phrasing, placement, context length, and compactor. Andrew Fribush’s October 5, 2026, practitioner report instead checks whether removed tool results contain distinctive tokens used later. He also describes successful file rereads after three live compactions. His comparison used unequal compression levels and evaluated his own implementation, limiting its relevance to choosing an SDK threshold. These approaches suggest three separate checks: what disappeared, what the agent recovered, and whether its subsequent behavior remained correct. Sources: arXiv, Andrew Fribush
Run the same migration under three settings
Use one long-lived subagent with a pinned TypeScript repository and a frozen documentation corpus. Assign it to research a paginated API migration, implement it, run tests, and produce a cited migration report. Require unchanged exported signatures, correct rate-limit retries, stable ordering across pages, and no additional production dependencies. The report should distinguish documented behavior from assumptions and attach a source URL to each migration claim. These requirements make success broader than producing compiling code.
Introduce a controlled correction at the same workflow milestone in every run, such as replacing an initially permitted retry policy with a stricter one. This tests whether the agent follows the latest instruction after compaction. Supply enough relevant documentation, repository exploration, and validation output to cross the baseline threshold. Include a shorter variant to check ordinary tasks. The table below defines three experimental arms; its percentages are design targets to translate into supported values, not production recommendations.
Table
Proposed comparison arms
| Arm | Configuration intent |
|---|---|
| A: default | Omit the subagent override; record the effective baseline behavior |
| B: moderately earlier | Target roughly 75% of the verified default window |
| C: substantially earlier | Target roughly 50% of the verified default window |
Pin the model identifier, effort, prompts, tools, permissions, repository commit, and source corpus alongside SDK and command-line interface versions. Record settings files and environment variables, and keep parent orchestration and subagent count fixed. Use fresh sessions and workspaces, vary execution order, and record cache usage. Start with ten repetitions per arm as a pilot, increasing the sample if variation obscures the result. Include timeouts, exhausted budgets, and unsuccessful completions.
Account for recovery and grade behavior separately
Track input, output, cache reads, and cache writes as separate token categories. Include parent, subagent, and compaction calls wherever observable, then establish whether parent totals already contain child usage. Check how retries and streamed events affect those totals before the main experiment. Missing summarization usage or counting child usage twice could reverse an apparent saving. Apply recorded provider rates to each category, because equal token totals need not imply equal billed cost.
Measure constraint loss at three levels: absence from the summary, failure on a recall probe, and an actual violation during execution. Run checkpoint probes separately so their questions do not remind the agent of requirements during the measured task. Grade implementation quality with hidden behavioral tests, compatibility checks, and regression results. Use blinded human review to assess the migration report’s factual accuracy, citation validity, coverage, and unsupported claims. Keep those judgments separate from code correctness. A fluent explanation should not compensate for a broken implementation.
- Record actual compaction trigger sizes, event counts, resulting context sizes, and duration.
- Track repeated file reads, searches, failed approaches, and corrective human interventions.
- Calculate token change as the earlier total minus the default total, divided by the default total.
- Calculate constraint violation rate as violated applicable constraints divided by applicable constraints.
- Calculate cost per successful completion as the cost of all attempts divided by successful completions.
Set acceptance criteria before comparing costs
Set correctness and constraint requirements before looking at the results. Compare cost per successful completion among settings that meet those requirements, reporting individual runs and uncertainty alongside averages. An earlier setting that reduces input tokens but causes repeated searches may offer little practical benefit. One that saves money while reviving the obsolete retry policy should fail the acceptance criteria. Keep the shorter workload’s results separate so unusually long sessions do not dictate every deployment.
Before adopting an override, establish whether its value is the trigger itself or a window from which a reserve is deducted. Check precedence against parent, model, and environment settings. Observe what happens when one tool result crosses the boundary, and verify that compaction events can be attributed to the subagent. Across repeated compactions, track whether the corrected retry decision survives each cycle. Retain that telemetry after deployment to detect changes in recovery work, compliance, and cost.