When a long Claude Code session becomes expensive
A practical way to separate useful context from repeated reading, oversized tool output, and unproductive loops.
An agent working on a small change can accumulate a large context. It may repeatedly read generated files, carry unrelated investigation history, or receive hundreds of lines when it needs a single match. The visible patch size is not a reliable explanation of the amount of model work.
The first question is what the agent is processing repeatedly. Optimizing that is more useful than imposing an arbitrary rule that every session must be short.
Inspect the work before trimming it
Anthropic's cost guidance recommends managing context and reducing unnecessary token usage. It also distinguishes activity statistics from subscription billing. Use the harness's current usage tools to inspect the session, then compare the record with the actual task history.
In an illustrative debugging session, a test failure needs a stack trace and two functions. If every iteration reads a whole build log and several generated bundles, the agent receives much more information than the diagnosis requires. Narrowing those reads changes the workload without depriving the agent of the relevant evidence.
Reference: Anthropic: managing Claude Code costs
Give the agent useful boundaries
Write the desired outcome, the acceptance checks, and the relevant part of the repository. Ask for targeted searches before broad file reads. Keep generated assets, vendored dependencies, and unrelated directories outside routine exploration unless the problem actually points there.
Do not reduce context by deleting the evidence the agent needs to reason correctly. A small summary that drops an unresolved constraint can cause repeated mistakes and more work later. At a checkpoint, preserve the current hypothesis, files changed, checks performed, and remaining uncertainty. That makes a fresh session possible without pretending the investigation never happened.
Separate reuse from waste
A large input count does not automatically mean all those tokens were processed at the same rate. Cache reads and new input can have different pricing. Compare reported categories and actual rates before calling repeated context a financial loss.
FlockTab's Agent view helps identify which named worker is accumulating usage, while its ledger gives a call history to investigate. Those signals can point to an expensive session; they cannot, by themselves, decide whether its reasoning was useful. The supervisor still needs to connect the usage to the task's progress.
Stop loops with a decision, not a smaller prompt
When the same test fails repeatedly, write down what changed between attempts. If nothing material changed, another identical run is unlikely to add evidence. Choose a new diagnostic step, ask for missing information, or stop at the agreed budget boundary.
Review one completed task after making a context change. Compare time to a verified result, number of repeated actions, and observed usage. Keep the change only if the result remains correct. A shorter conversation is an implementation choice; a reliable outcome at an understandable cost is the goal.
Sources checked 23 September 2026. Numerical scenarios are illustrative unless explicitly identified as provider data. Vendor limits and interfaces can change; consult the linked documentation for current details.