Seoul Labs

Photo by Bernd 📷 Dittrich on Unsplash

A single debugging cycle in Claude Code, file reads, a shell execution, a follow-up edit, can add ten thousand tokens or more before Claude has written one line of production code. The documentation doesn't warn you that this cost is cumulative and non-reversible within a session, not a flat rate per message. By the time a long session feels most productive, the context window is already bending toward a crossover point where every additional message yields degraded, increasingly contradictory responses. This post maps exactly how the window fills, what breaks when it does, and which structural choices actually slow the drain.

The core argument is simple: context growth in Claude Code is not linear. It's cumulative in a way that catches people mid-task. Every tool call Claude makes appends its trace to the context. Every file Claude reads stays in the window. Every response is included in the next prompt. You're not paying a flat rate per message. You're paying a running total that only goes up, and that total affects both latency and cost in ways that are completely invisible from the chat interface alone.

How the Window Fills Before You Notice

The mechanics are worth being specific about. Claude Code tools, file readers, shell executors, directory listers, each generate a tool call record that persists in context. If Claude reads five files to understand a refactoring task, all five file contents plus five tool call traces are now resident. Ask Claude to run a test suite and the full stdout of that run gets appended. A single debugging cycle involving file reads, a shell execution, and a follow-up edit can add ten thousand tokens or more without Claude having written a single line of production code yet. The actual figure varies considerably depending on file sizes and output verbosity, but the direction is always the same: up.

CLAUDE.md is the stealth contributor. Engineers who use it thoroughly end up with substantial files that load into every session, unconditionally. A CLAUDE.md that documents project conventions, testing requirements, architectural constraints, and tool preferences is doing its job correctly. It's also fixed overhead that never shrinks no matter how small the task you opened the session to do. The question worth asking is whether your CLAUDE.md has grown because it's genuinely useful, or because no one has pruned it since the project started.

There's also a subtler contributor: conversational repair. When Claude misunderstands a request, the correction you send, plus Claude's acknowledgment, plus the re-attempt all accumulate. A task that should have taken three exchanges sometimes takes seven because of one ambiguous prompt early in the session. Those extra exchanges are not free. The context does not forget them.

The sessions that feel the most productive, the long ones where you iterate through a complex feature, are precisely the sessions generating the highest token spend per request as they age. The cost curve is not flat. It bends upward, and that bend accelerates faster than most developers expect until they're looking at an invoice.

What Breaks When the Limit Arrives

Claude Code does not crash cleanly when the context window fills. The behavior is more disruptive than a hard error. Claude begins to lose coherence on earlier parts of the conversation while continuing to respond confidently. It may reference a file it read forty messages ago as though that content is still sharp in its working memory, when effective attention on that content has degraded significantly due to positional distance in the context.

The more observable symptom is that Claude starts asking you things it already knows. It will re-request a file path you provided six messages ago, or ask for clarification on a constraint that was spelled out in the CLAUDE.md it loaded at session start. This isn't hallucination in the traditional sense. It's a context distance problem where the relevant information is technically still in the window but positioned so far from the current exchange that retrieval quality drops measurably.

A Python debugging session illustrates this concretely. Say you opened a session to track down an attribute error in a Django view. Claude read the view, read the model, ran the test suite, read the traceback, proposed a fix, then ran the tests again. By message fifteen, Claude has a dense and accurate model of the problem. By message thirty, after several iterations and some exploratory file reads into adjacent modules, that model starts to fracture. Claude may propose a fix that directly contradicts something it correctly diagnosed ten messages earlier.

This is the kind of traceback that triggers a long debugging session
Context Window Token Contributors: Cause, Behavior, and Impact

  
Context Window Token Contributors: Cause, Behavior, and Impact

  

    

      
Contributor
      
Persists?
      
Failure Mode
    

    

      

        CLAUDE.md

        Loaded unconditionally every session
      
      

        Always
      
      
Fixed overhead even for tiny tasks; grows unpruned
    

    

      

        File Reads

        Content plus tool call trace per file
      
      

        Always
      
      
5 files read adds contents plus 5 tool traces permanently
    

    

      

        Shell Execution

        Full stdout appended to context
      
      

        Always
      
      
Verbose test suites generate thousands of tokens per run
    

    

      

        Conversational Repair

        Correction plus acknowledgment plus re-attempt
      
      

        Always
      
      
3 planned exchanges become 7 from one ambiguous prompt
    

    

      

        Claude Responses

        Every reply included in next prompt
      
      

        Always
      
      
Running total grows with every message, invisible from chat UI
    

  

  

    10k+
    tokens consumed in a single debugging cycle before any production code is written
  

  
Source: Claude Code Context Window Tax article
Source: Claude Code Context Window Tax article

Traceback (most recent call last):
  File "/app/views/payment_view.py", line 47, in post
    amount = self.order.total_with_tax
AttributeError: 'NoneType' object has no attribute 'total_with_tax'

That traceback alone is inexpensive. But Claude reading payment_view.py, then order.py, then tax_calculator.py, then running the test suite, then reading the test file to understand the fixture setup means that by the time Claude has enough context to diagnose confidently, the window is already carrying a significant load. Context depth is exactly what makes Claude useful on complex bugs. That same depth is what degrades session quality later, and the documentation doesn't warn you about the crossover point. The session hasn't failed at message thirty. It has degraded into a state where continued investment yields diminishing and increasingly unreliable returns.

Patterns That Actually Reduce the Tax

The most effective intervention is also the least intuitive: keep sessions shorter and more targeted than feels natural. The instinct when working with an AI coding tool is to stay in the same session while a problem is live, the way you'd stay in the same terminal window. That instinct works against you. A focused session scoped to a single file or a single bug costs less per message and degrades less over time than a broad session that wanders across the codebase.

CLAUDE.md structure matters more than CLAUDE.md length. A file that's five hundred lines of dense prose is expensive to load and harder for Claude to retrieve specific conventions from when they're buried in surrounding text. Short, declarative sections with clear headers give Claude a better retrieval surface. This isn't a claim backed by published benchmarks. It's a pattern observed across repeated sessions on the same project, before and after restructuring the file, and the difference is noticeable.

Project Conventions


Testing


All new tests use pytest, not unittest


Fixtures live in conftest.py at the package level


Do not mock the database: use the test transaction wrapper


Code Style


Type annotations required on all public functions


No bare except clauses


f-strings only, no .format() calls


Architecture


Service layer handles business logic, views handle HTTP concerns


No direct ORM queries in views: go through the service layer

That structure costs roughly the same tokens as a paragraph describing the same rules. The difference is that each rule is findable independently. Claude reading a constraint from a bulleted section is less likely to conflate it with a nearby but unrelated constraint than Claude reading the same information embedded in a paragraph. The formatting choice is a retrieval quality choice, not just an aesthetics choice. Sessions run on a well-structured CLAUDE.md appear to produce fewer re-requests for information that was already loaded at session start, based on observed patterns rather than controlled benchmarks.

The other lever is explicit context resetting. Starting a new session mid-task is not an admission of failure. It's a deliberate cost management decision. Carry forward only what's necessary: the specific file path, the error message, the one constraint directly relevant to the next step. Summarizing the prior session state yourself in the opening message of the new session is cheaper than letting the old session's full history ride along.

Instead of continuing a degraded session, open fresh with precise context.


Paste something like this as the opening message of the new session:


# Working on payment_view.py line 47.


Order object is None when payment is initiated from the cart endpoint.


The order ID is present in the session but the ORM lookup is returning None.


Tests are in tests/test_payment_view.py, fixture is create_pending_order.


Goal: fix the lookup and add a guard for the None case.

That opening message is compact, perhaps a few dozen tokens in many configurations. The session history it replaces could, depending on the length and content of the prior session, run to many thousands. The new session starts with better signal density than the old one had at message thirty, which means the first response is more likely to be on target than anything in the final third of the degraded session.

Reading the Token Counter Without Lying to Yourself

Claude Code surfaces token usage in its output, though the presentation varies across interface configurations and has shifted across observed versions. The number that matters is not the per-message count but the cumulative context size at any given point in the session. When that number isn't visible in your current setup, the behavioral signals to watch for are increasing latency per response, Claude re-requesting information it already has, and responses that feel technically correct but subtly misaligned with constraints established earlier in the session.

None of those signals are definitive on their own. Latency has other causes. Claude re-asking a question might reflect genuine ambiguity rather than context distance. But when all three appear together in a session that has been running for a while, the context window is the first thing to examine, not the last.

The agents and long-running task features in recent Claude Code releases make this problem more acute, not less. An agent that autonomously explores a codebase to complete a multi-step task accumulates tool call traces, file reads, and intermediate outputs at a rate that manual sessions never approach. The context window tax in an autonomous agent run is not a hidden cost. It's a structural characteristic of the design, and planning around it is not optional.

There's also a cost asymmetry worth naming directly. The tokens in a long, degraded session are not just more expensive than the tokens in a short, focused session. They're lower quality tokens. You're spending more to get less reliable output. That asymmetry goes unmentioned in tooling documentation because it requires admitting that more context is not always better context, which complicates the narrative around longer context windows as a straightforward capability improvement. In practice, the shape of the context matters as much as its size. Treating a growing window as a sign of productive work rather than a liability to manage is the most expensive mistake you can make in an extended Claude Code session.