Before a long Claude Code task: when to compact and how to control subagents and usage

Before asking Claude Code to spend an extended stretch reading code, making changes, and running tests, do not rush to clear the context. Nor do you need to keep every old discussion just to “make full use of 1M.”

Start with more useful questions: Which original details will the next step still need? Can the work you plan to delegate be completed independently? Once the task is finished, how will you tell whether the change helped, rather than merely produced a smaller usage number?

On September 19, ZryMiller described a change in his approach. He had been compacting frequently, then returned to what he called the default 1M window. He felt the experience improved considerably and said he was preparing to release his first app. But the post included no comparable tasks, no before-and-after usage figures, and no outcome showing that the app was ultimately released. It is useful personal feedback, not evidence that “never compacting makes every long task go better.”

Rather than choosing between “compact often” and “never compact,” make the decision at a specific boundary in the work.

First, confirm what you are using

Run claude --version in the terminal and record the client version. Once in a session, use /status to check the account and current model, /model to see available models and related settings, and /context to inspect context usage. Run /usage when you need usage information. These commands show different things; they are not interchangeable measurements. Official command reference · Usage documentation

The official model name in this discussion is Claude Fable 5.1, its Claude API model ID is claude-fable-5-1, and its official specification lists a 1M-token context window. The model, Claude Code version, and effort setting are different details. Do not record them simply as “used Fable” or “used Ultra.” Official model specification

A model supporting 1M does not mean every account, model, and access route automatically has the same conditions of use. For example, the official documentation distinguishes between Opus 1M being included in Max, Team, and Enterprise plans and requiring usage credits on Pro. Sonnet 4.6’s 1M window also requires usage credits on subscription plans. Do not apply those rules directly to other models. Client configuration, model mapping, and gateway support also need checking; adding [1m] in the selector cannot expand the server-side model’s capabilities on its own. 1M eligibility and model configuration

Also distinguish three easily confused numbers: context usage tells you how much content the current request needs to accommodate; cumulative token usage records how much input, output, and cached content requests have processed; subscription allowances are the account’s limits within the applicable usage windows. Five hours or a week describes an allowance window, not a guarantee that a task can run continuously for five hours or a week. Cached content still occupies context, although API billing can apply different cache rates. So “30% of context used” cannot be converted into “30% of the five-hour allowance used,” and 1M is not a token allowance you can process repeatedly for free. Context and caching · API pricing structure

Before compacting, consider what the next step still depends on

Suppose you are investigating a bug that spans the frontend, an API, and the database. You have just read several pieces of code, examined a failed request, and noticed an edge case, but have not yet reached conclusions you can verify. Compacting simply because “the chat is getting long” could discard the details you most need to compare next.

By contrast, if the root cause is clear, the relevant files and evidence locations are recorded, and the next step is a small implementation change based on an agreed plan, much of the earlier search process may no longer need to remain in the current window.

A good point to compact is not a universal percentage. It is the end of a completed phase, when reliable records are enough to continue. This is a workflow recommendation, not a fixed model threshold.

First, ask Claude to write the necessary state into the task record you specify: confirmed facts and evidence locations, files actually changed, checks actually run and their real results, unresolved issues, and the next step. There is no need to copy the whole conversation, and unverified guesses should not become conclusions.

Then use the native /compact command, specifying what should be retained: How compaction works

/compact Keep the current goal, confirmed conclusions and evidence locations, changed files, checks actually run and their real results, unresolved issues, and the next step. Remove repeated searches and discussions that have already been ruled out.

This text is a request about the summary, not a guarantee that no information will be lost. Before making further changes, ask Claude to explain the next step using the compacted context, and check key constraints against the actual files and task record. Restore any missing edge cases first, rather than waiting for the implementation to drift and require rework.

If the next task is unrelated, it is usually more straightforward to save the current results and handoff information, then start a new session with /clear. Use /resume if you need to return to the original conversation. Clearing a session does not refund usage already incurred or reset a subscription allowance. Session commands · What resets in the usage display

Claude Code already has automatic compaction, so you do not need to install a plugin to follow this approach. Versions v2.1.221 and later also provide /autocompact: without arguments, it shows the current automatic compaction window; /autocompact auto restores the model-tuned window setting. The latter saves a setting rather than merely expressing a preference to the model. A model’s maximum context window and its automatic compaction window are not the same thing. Automatic compaction command

HKTECH_AI estimated that a single compaction could consume about 15% of a five-hour allowance. The post supplied neither a bill nor a calculation method, so that percentage should not become an operating rule. What matters is whether compaction reduced the content carried repeatedly into subsequent requests, and whether it also led to rereading, re-explanation, or corrections.

Subagents can divide the work, but “one at a time” depends on how you enforce it

SHCH shared a division of roles: Fable handles planning and judgment, a Sonnet Scout searches, and an Opus Builder executes well-defined tasks. He specifically advised invoking only one subagent at a time.

His published Builder screenshot stresses following the existing plan, stopping to report problems with it, not launching further subagents, and reporting check results. The value of those instructions is that they clarify responsibilities. But “do not launch further subagents” in an image is still a prompt-level constraint, not a software-enforced limit. The author also mentioned running multiple main sessions and did not publish verifiable before-and-after usage. This setup therefore cannot be interpreted as “only one agent across the entire account,” let alone a promise of a fixed percentage saving.

An ordinary subagent starts with its own context, receiving the delegated task and relevant configuration. It does not automatically get the main session’s entire chat history; a fork subagent inherits the existing conversation. Moving a noisy investigation into a subagent can reduce the process details held directly in the main session, but the subagent’s requests still process tokens, and its returned result also enters the main session. Subagent context boundaries

So ask “Is this task worth delegating?” before “How many should run at once?” A simple lookup does not need a full planner, researcher, and executor. Two tasks that will repeatedly edit the same file may not be good candidates for parallel work either. Investigations that are genuinely independent, with clear deliverables, are better candidates for parallel comparison.

You can make the working instructions more concrete, for example:

Goal: Complete the agreed changes and pass the directly relevant checks.
Allowed scope: The implementation and corresponding tests involved in this request.
Execution: Perform simple lookups directly. When delegation is necessary, provide only the context and deliverable requirements the subtask needs, and assign one subagent at a time. Do not repeatedly query the same status while waiting.
Completion criteria: Deliver against the acceptance requirements and stop once the relevant checks pass. If blocked, report what is complete and why progress is blocked; do not restart the same task.

These are still behavioral instructions. To actually restrict the creation of native subagents, use client controls. Claude Code v2.1.217 and later support concurrency and delegation-depth limits. The following Bash/Zsh launch example for macOS and Linux is a conservative starting point for investigating unnecessary parallel work: Environment variable reference

CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS=1 \
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1 \
claude

The first variable applies a per-session concurrency check when new subagents are created through the Agent tool. The second limits subagents to one level, preventing further nested delegation. They are not prompts, and they do not retroactively change other sessions that are already running. Environment variable reference

However, this is not a global lock guaranteeing “no more than one agent anywhere, ever.” The official documentation explicitly lists exceptions: ultracode sessions do not enforce this concurrency limit; manual /subtask calls and resuming completed subagents are not blocked by the same new-creation check; workflows and agent teams have their own limits. Nor does this single setting jointly control multiple main sessions or externally launched processes. Concurrency limits and exceptions

If your own scheduler needs a genuine global limit, a queue or concurrency lock must coordinate starts, resumes, and retries, rather than relying on “one at a time” in a prompt. That is part of your own scheduling implementation, not another undocumented Claude Code setting.

Waiting for a result does not mean asking the model to keep checking progress

LeeLeepenkman was not merely complaining about “using subagents.” He described Fable 5.1 sending muse a large prompt and then polling roughly every five seconds, causing the context to grow quickly. The original post did not explain muse’s implementation, provide request records, or report a result after resolving the issue. Five seconds therefore cannot be presented as Claude Code’s fixed polling interval.

Native background subagents currently provide completion notifications, with results delivered back to the main session in subsequent turns. You can use /tasks to inspect running work. This is different from repeatedly having the model issue new “Is it done yet?” requests. Background subagents and result notifications

When investigating, expand the session’s tool records and follow the same task: Are repeated checks producing any new information? Was a completed task started again? Did a status check actually trigger a new model call? Ctrl+O opens a more detailed conversation view, but the number of interface refreshes cannot be treated as the number of model requests. For request-level usage, also check the records from the provider you are actually using. Interaction and conversation views

With native notifications, an additional high-frequency checking loop driven by the model is usually unnecessary. If an external tool only supports polling, let the program wait for state changes at reasonable intervals, set a timeout, and pass information to the model only when there is a new result or an exception. The aim is to reduce model calls that add no information, not to prohibit necessary progress monitoring.

After an allowance resets, first check what is left to do

intwerpret reported a more dramatic experience. After hitting a usage limit, he chose to wait and continue automatically, then claimed that 39 agents appeared and exhausted the allowance again. He eventually switched back to Codex. The materials contain no client version, task details, complete configuration, or identification of the resume mechanism. Whether the task was eventually completed is also unknown.

This report is a reason to inspect the resume workflow, not proof that “Claude Code auto-resume always launches 39 agents.” His use of the word “Ultra” is not enough to establish that he was running the ultracode mode discussed above, either.

At the same time, automatic continuation can no longer be attributed exclusively to third-party scripts. The official interaction documentation describes native continuation after a usage limit resets: from v2.1.234, eligible interactive subscription sessions can wait for an allowance to reset and then continue working. This should not be equated with the behavior of API key sessions, -p, or every background mode. Resuming is also not simply resending the user’s last original task. Native waiting and automatic continuation

If you do not intend to let a task resume unattended, turn off Continue automatically at usage limit in /config. On versions that support the setting, you can also run:

/config autoContinueAtUsageLimit=false

If the session is already waiting, cancel that particular wait as well: press Esc in an empty input box, or use Don’t continue automatically in /rate-limit-options. Changing the default and cancelling a wait you have already selected are not the same action. Cancelling and configuring automatic continuation

Next, check /tasks and the actual state of the files. Which tasks are still running, which are complete, and which only need one more verification? Reuse existing results and specify what unfinished work should continue, rather than resending the entire request and having it break down the work again.

For commits, deployments, messages, or other actions with external effects, first establish whether the previous attempt succeeded. An allowance reset only answers “Can requests continue?” It does not guarantee “The next actions will not be duplicates.”

Check the outcome before deciding that usage has improved

chasemdev explained that he was not having Fable write all the code itself; he was using it to orchestrate Opus subagents. He still expected to hit the weekly limit soon. “Soon” was the author’s forecast at the time, not a verified final usage outcome. But it highlights something easy to omit from your records: include the subagents’ models and work, not just the main model.

The Session section of /usage currently shows session token usage and a locally calculated cost estimate. Subscription users also see plan usage in the same interface. The dollar figure in Session is not a subscription bill, nor does it necessarily equal the API provider’s final charge. Pay-as-you-go users should rely on their actual provider’s bill. What /usage currently means

Local attribution of subscription usage is also only a clue. Breakdowns for subagents, plugins, skills, and similar components come from recent history on this machine. They do not cover complete usage from other devices or the web, and they are not causal proof of “how much waste a plugin created.” If you see Showing last-known usage, record the timestamp of the displayed data and refresh before comparing. Attribution scope and cached readings

You do not need a complex evaluation system. Choose a clearly scoped task that can be reproduced safely, write down its acceptance criteria, and record the following at the start and finish:

What to record	Questions to answer
Task, starting code revision, model, effort, client version	Are you comparing the same kind of work and settings before and after?
/context and the compaction process	Did compaction lose constraints, cause rereading, or require re-explanation?
Subagents and waiting behavior	Which tasks were created or resumed, what was the peak number running simultaneously, and were there repeated checks with no new information?
Usage readings, timestamps, and reset boundaries	Did an allowance reset occur, was other session activity mixed in, and did the API accounting include all relevant models?
Actual deliverables and check results	Were the requirements met, did relevant checks pass, and how much human rework remains?

Change just one practice, such as waiting until the investigation is complete before compacting, or limiting concurrency when creating new subagents. Keep the original acceptance criteria; do not quietly shrink the task to obtain a lower usage figure. Note whether cache conditions differ, too. If the runs used different models, code revisions, or task sizes, do not attribute the entire difference to compaction.

Using fewer tokens while missing requirements or leaving verification to a person is not an improvement. Conversely, if retaining more context lets the task finish in one pass without repeated investigation, a fuller window alone is not enough to call it wasteful.

Keep standalone API usage and subscription usage in separate accounts. Switching the billing source does not reset the original subscription allowance or automatically change the client’s delegation, waiting, and compaction behavior. Judge whether the change is worthwhile by comparing total usage and rework needed to complete the same task, not merely one model’s unit price. Differences between billing methods · API token billing structure

Before a plugin decides when to compact, check what it sends out

Kun Chen started with a practical question: “when should i /compact my session”? His compact-adviser uses TypeSafe’s Jev to judge whether work has reached a suitable boundary for compaction. It offers a hint mode and an automatic mode that requires opting in. Project overview

The review for this article was pinned to commit d1655faa16a22b68bff60c3d7deb0123e1e52a53, where the Claude Code plugin manifest lists version 0.1.4. The project requires Node.js 22 or later and Claude Code 2.1.274 or later, and says it was verified on 2.1.275. Its Claude Code integration depends on experimental function hooks and requires CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1. These are compatibility conditions stated by the project, not an installation test performed for this article. Pinned version manifest · Version and integration requirements

More importantly, hint mode only means that compaction is not performed automatically. It does not mean decisions are local or that context stays on the machine. The project’s security documentation says that, after installation, if a key is available from the launch environment, saved settings, or a .env file in the working directory, and the request conditions are met, selected session content is sent to TypeSafe. This includes user constraints, recent visible replies and tool results, an existing summary, and artifact names. There is no separate sharing-consent toggle. Excerpts may still contain code or business information; best-effort redaction is not a guarantee that sensitive content is absent. Boundaries of context sharing

If you already have the plugin installed, disable it with /compact-adviser off, or launch with:

COMPACT_ADVISER_DISABLE=1 claude

According to the project, this stops plugin requests, hints, and automatic compaction. It disables the plugin, not Claude Code’s own automatic compaction. If sending work content to TypeSafe as an additional recipient is not permitted, disable or uninstall the plugin rather than merely switching from auto to hint. How to disable it

The 40-session evaluation the author mentions is the project’s own evaluation, and the dataset is not public. It cannot guarantee that details will be preserved in your tasks. Even when the plugin judges a point “safe to compact,” what ultimately matters is whether the work can continue correctly afterward. Evaluation boundaries

You can already do all of the following without a plugin: save state at task boundaries and retain the details needed for the next step; give subagents clear, independent work; avoid duplicate starts while waiting or resuming; and judge the outcome using both deliverables and usage records.

The goal of managing a long task is neither to fill the window nor to make each request look as cheap as possible. It is to do less work that does not advance the task, and reliably finish what you started.