Claude Code Quota Drop: Are Agents Creating New 'Legacy Code Mountains'?

Claude Code's extended weekly quota has drawn attention, with an article analyzing the token consumption mechanism of Agent programs. Prolonged operation of an Agent causes its working set to continuously expand, as each step accumulates historical state. Combined with the characteristic that cached hits still occupy context, computational cost grows cumulatively. Over-cleaning can trigger "semantic page faults," forcing the Agent to reacquire information. The article highlights that this inconsistency between code state and design-state preservation precision may lead AI-generated "legacy code": subsequent Agents cannot comprehend the design causality of earlier code, ultimately resulting in complex code with queues, bypasses, and retries compensating for one another.

Author and source: Leiphone

The code was indeed written by an Agent, but subsequent Agents no longer know why the earlier Agent wrote it that way.

The +50% weekly quota boost for Claude Code, originally scheduled to end on August 19, has been extended by Anthropic until August 31. Around the original end date, a discussion emerged on Hacker News about the cost of using Claude Code: many users found that even a relatively simple task, after a few agent cycles, rapidly depletes the quota.

The issue is that Claude Code doesn't just consume the final few lines of generated code. Reading files, tracing call chains, running tests, and processing logs—all these steps continue to add to the subsequent context. The longer the task, the heavier the historical burden the Agent carries, and the more the system relies on cleanup and compression.

The code can remain fully intact in the repository, but the original design rationale may gradually thin out during compression. As a result, token consumption and code spaghetti begin to converge in the same place.

The computational boundaries of regular Chat coding are clear: input a piece of code, the model reads it and provides an explanation or modification suggestion, and the round essentially ends.

The basic unit of Claude Code has been changed to an agent loop. The model first observes the current state and decides which file to read or which command to execute; after the tool returns the result, the model makes another round of decisions.

Reading source code, searching for references, running tests, viewing Git diffs, and modifying files may appear as a single continuous action, but on the model side, they are actually a series of independent reasoning requests. Claude Code’s official documentation also treats this “model judgment—tool invocation—continue judgment based on results” cycle as the core of its agent workflow.

For example, an intermittent login state failure issue. The agent first identifies the entry point and discovers that the state originates from a service, so they proceed to examine the service; upon encountering a cache, they search for what is writing to it; then they run tests, which reveal another anomaly, prompting them to inspect the fixture; after fixing it, revalidation exposes a compatibility issue with the original test.

It may not have been until now that it actually wrote those few lines of code. Therefore,diff there is almost no stable ratio between size and computational effort. Five lines of patch could stem from just three inferences—or from thirty tool interactions.

If you break down an Agent task, you can first obtain two variables: one is the step count, which indicates how many steps the Agent took to complete the task; the other is the working set, which represents how many item states the model still needs to track at the current step.

Simply increasing the step count will already increase consumption. If the working set is still growing during synchronization, the situation becomes entirely different. Step 3 might only require processing a few thousand tokens, but by step 30, it could already be carrying project specifications, related source code, test results, modification history, and tool outputs for continued reasoning.

This is also where the cost structure of the Coding Agent shifts: computational demand now depends on “how many steps × how much weight per step,” rather than how many lines of code were written.

Splitting a single model request from the Agent can be roughly divided into three parts. The relatively stable components include the system prompt, CLAUDE.md, tool definitions, and project rules; the constantly changing components include code files, search results, test logs, Git diffs, and prior task trajectories; finally, there is the model’s current output consisting of reasoning, text, and code.

A common misconception here is that if the previous content has already been read, it shouldn’t incur much additional cost. The issue is that LLMs do not have an internal memory accessible between requests like traditional programs. If information from the previous round is still needed for the next round’s decision, the relevant state must continue to be included in the available context.

Prompt caching can alleviate this issue. According to the official Claude Code documentation, without prompt caching, each request requires reprocessing the entire history; after a cache hit, previously processed stable prefixes can be reused, reducing redundant computation and costs.

But caching addresses whether the same historical data can be reused more cheaply, not whether that history should continue to exist at all. Even after a cached hit for the old state of 100K tokens reduces cost, it still occupies context and remains the state upon which current inference is built.

Thus, a long task can be roughly written as: the input size at step t is approximately equal to the stable prefix S, plus the current working set W_t, plus the new information generated in this round Δ_t.

The real problem is W_t. If, with each step, the Agent reads more source code, gathers more logs, and makes another decision, while old information isn’t promptly cleared, then W_t will continue to grow as the task progresses.

In an extremely simplified model with no caching or cleanup, if the number of new valid states added each round is roughly constant, the total processed volume will exhibit a cumulative structure approaching 1 + 2 + 3 + … + n, meaning that while the step count doubles, the total historical states processed may grow much faster.

Real systems have cache, context editing, and compaction, and do not mechanically follow this growth curve, but the shape of the problem remains unchanged: the longer an Agent runs, the more each new action is likely to be built upon a heavier history.

So the very short user prompt in long tasks quickly loses prominence. What truly begins to dominate the cost is the working set the model continuously carries to maintain task continuity.

Why is the working set expanding so rapidly? The tool's output is a major source. The source code at least has structure, but logs often don't.

A single grep can return hundreds of matches, a single build might output large volumes of warnings, a failed test might bring a full stack trace, and Docker, compilers, and package managers also generate vast amounts of text with no long-term value for the task.

Suppose the test in step 10 generated an 8K token log. When it first enters the context, it is merely 8K tokens. However, since the agent must continue reviewing the source code, making modifications, and retesting, as long as this log remains in the valid history, it will increase the base weight of many subsequent requests.

This is similar to write amplification in storage systems: a single logical write triggers additional underlying processing. In the Agent, a tool output is written to the execution history and then moves along with subsequent reasoning.

Thus, placing 8K tokens at the end of a task versus at the beginning results in entirely different overall impacts. Claude Code is now actively reducing this kind of contamination. The official recommendation is to isolate high-output tasks using sub-agents, and it explicitly notes that search results, logs, and large amounts of file content consume the main session context; even tool definitions themselves take up space, so an overly large toolset increases the state burden.

But here arises an opposite issue: you can’t simply discard all logs just because they’re expensive. In a 3,000-line log, only 20 lines might be relevant to the root cause—the system doesn’t know in advance which 20 those are. If cleanup happens too early, and the Agent later needs one of those details, it would have to rerun the test or reopen the file.

This can be called a semantic page fault. In traditional virtual memory, when a program accesses a page no longer in memory, the system reloads it from disk; similarly, when a Coding Agent discards earlier evidence, it experiences a comparable phenomenon—researching the repository again, rereading files, rerunning commands, or even rediscovering a problem that was already analyzed.

Thus, long tasks fall into a dilemma: retaining too much history makes each subsequent step increasingly heavy; removing too aggressively causes the Agent to repeatedly reacquire information it has already seen.

This also explains why context management cannot be simplified to "just insert fewer tokens." The real issue to address is working set selection: which information must remain in the working set right now, and which are merely intermediate products that have already fulfilled their purpose.

Here, compaction, memory, and sub-agent truly gain their purpose.

When Claude Code approaches the context limit, it automatically compresses the session and cleans up some older tool results. The official documentation also warns that irrelevant conversations, file contents, and command outputs in long sessions may fill the window and interfere with model performance.

From a system perspective, compaction is similar to a semantic garbage collection. The challenge is that ordinary garbage collection determines whether an object still has references, while the Agent must determine whether this information will still be meaningful in the future.

The latter is much more difficult. For example, an early design conclusion stated: a module cannot cache user state on its own, because the system requires that state have only one owner, and all modifications must go through the service.

After a few steps, if this information is condensed to: "The state issue was resolved via service adjustments," the fact is not wrong, but the information has changed. The original content contained a constraint, while the summary only preserves the event.

The next time the Agent encounters a performance issue and sees slow service calls, it will likely add caching within the module again. It has not violated any of its current knowledge; the causal reason that originally prohibited caching is no longer in effect.

The context document for Claude Code explicitly states that certain path-scoped rules and nested CLAUDE.md files are compacted and summarized along with the session, and must be re-read and matched against the files to be reloaded.

Memory aims to address the issue of long-term knowledge retention. The CLAUDE.md and auto memory in the project root directory can extract content such as build commands, project specifications, and debugging insights from short-term conversations and reload them at the start of a session. However, Anthropic has clearly stated that these memories are still part of the context and not mandatory configurations.

This distinction is critical. If “The database cannot be accessed directly here” is only written in memory, it remains a natural language statement that the model must understand and follow. Only when the same rule is implemented as a dependency lint, type constraint, or CI check does it become a software invariant that cannot be easily bypassed.

The sub-agent addresses another aspect: isolating the working set. By delegating tasks such as scanning a repository or analyzing long logs to a separate agent, and then returning a compressed result to the main agent, raw noise is prevented from entering the main thread. One of the official use cases for sub-agents in Claude Code is context isolation.

The cost is also interesting: the main Agent gains a cleaner state but loses some original evidence; running multiple Agents simultaneously establishes their own contexts. Therefore, when viewed together, compaction, memory, and sub-agents already resemble a memory hierarchy for the Agent era:

The current context is expensive working memory, compaction is responsible for compression, memory retains cross-session state, and sub-agents use isolated address spaces to filter out noise. The issue has shifted from “whether the context is large enough” to another level:

Which states require high-fidelity preservation, and which states only need to retain summaries? This question will directly impact the quality of the subsequent code.

After understanding the preceding execution structure, examining Claude Code’s weekly quota reveals that it is difficult for the platform to continue measuring Agents by “number of messages,” as a single message has lost its stable meaning.

Renaming a variable is one message; refactoring the entire authentication module is another message. The former might be completed in a few steps, while the latter could run for dozens of cycles, read dozens of files, and launch multiple agents. The same request can demand vastly different levels of underlying resources.

Claude Code packages this with rolling limits and weekly quotas; Codex now explicitly calculates credits based on input tokens, cached input tokens, and output tokens; Cursor’s plans provide different usage pools for Agents, and consumption of third-party models is affected by the model API pricing.

The interface languages of the three products differ, but the underlying problems they need to solve are very similar: how to allocate reasoning resources to an intelligent program whose execution path cannot be determined in advance. It is difficult to predict how long a Coding Agent will run at the start of a task.

The model may quickly identify the root cause, or it may make several incorrect assumptions in succession; it may pass on the first test, or it may enter a prolonged debug loop; it may require only one agent, or it may need to be split into multiple sub-agents.

Traditional APIs favor charging per request because the resource fluctuation of a single request can still be contained within a certain range. Agents disrupt this stability. As a result, tokens here begin to take on a slightly different character, more akin to CPU time.

This analogy cannot be equated. Different models have varying computational costs for processing the same number of tokens, and input, cached input, and output each carry different costs. However, from the developer’s perspective, their functions are becoming increasingly similar: all of them describe how much computational resource is consumed to continue executing a task.

When Anthropic increased the usage limits for Claude Code this year, they directly linked the increased quotas to additional compute capacity. This will lead to an interesting shift in metrics. Previously, evaluating coding agents often focused on “who can solve the same problem correctly in one attempt.” Going forward, a more meaningful metric may be: who achieves the same engineering state change with less effective computation.

If an Agent spends a large number of tokens merely repeatedly opening files, rerunning tests, and restoring lost context, those tokens do not translate into proportional engineering progress.

And this inefficient state recovery will恰好 intersect with technical debt at the next level.

Here, a software maintained by a Coding Agent can be abstracted into two evolving states. One is the code state R_t. Files, types, interfaces, tests, and Git commits all belong to this layer. A line of code added by the agent at step 20, such as retry, remains fully intact when the file is opened at step 100, as long as it hasn’t been deleted. The code preserves past modifications with very high precision.

Another set is the design state M_t. Why is retry needed here? Why can the cache only be placed in the service? Why can’t this state have two owners? Why can’t this seemingly redundant check be removed for now? These details belong to design causality.

M_tThere is no native, lossless storage like Git. It is scattered across conversations, reasoning, tool responses, memory, rule files, and compaction summaries. As tasks progress, some parts are cleaned up, some are summarized, and some need to be retrieved again.

This creates a critical asymmetry: the outcomes can be high-fidelity accumulated, while the causal relationships that generated them are continuously downsampled. This is far more serious than simply saying “the Agent forgets things.”

In the event of a concurrency issue, after analysis, the Agent added a queue. At that time, its complete conclusion was: only write path A had a race condition, so the queue could only encompass A; write path B required low latency and could not enter this queue.

The code has saved the entire queue. After long-term execution, the design state may be reduced to simply "using a queue to resolve race conditions."

Later, an intermittent error also occurred in B. When the agent read the code again, it naturally integrated B into the existing queue.

Subsequently, delays increased, so a bypass was added. The bypass introduced occasional state inconsistencies, so retries were added around the perimeter. By this point, no single change was necessarily absurd; each patch may have seemed quite reasonable given the local state at the time. Yet the code had evolved from “a clear concurrent model” into a system where queue, bypass, and retry compensate for one another.

An AI codebase likely grows this way: it doesn’t necessarily manifest as the model suddenly producing garbage, but rather as locally correct changes accumulating over time, causing the overall model to gradually disappear.

In traditional software, such issues typically develop gradually through personnel handovers. When the original author leaves, new developers see the old code but don’t understand why it exists, so they add an additional layer of compatibility logic around it.

The Coding Agent misinterpreted “personnel handover” as “context handover.” Steps 20 and 100 appear to be part of the same Claude Code session, but the design states they received are no longer identical. From an information perspective, it’s more like two engineers maintaining the same repository through a progressively dwindling handover document.

Testing can only address part of it. Testing excels at protecting behavior: what the interface should return, that certain inputs shouldn't crash the system, and that past bugs shouldn't reappear. Many architectural constraints, however, are not naturally expressed as inputs and outputs.

There can only be one owner for a state, the domain layer must not depend backward on the UI, a certain package is not allowed to connect directly to the database, and write operations must go through a unified transaction boundary—these constraints are easily overlooked during local fixes if they exist only in documentation or an agent’s memory.

This leads to a problematic engineering state: the tests are still green, but the code is becoming increasingly difficult to understand. Even more dangerous is the presence of feedback loops here.

The architecture is becoming disorganized; the next time the Agent needs to understand a feature, it must read more files; the more entangled the dependencies, the larger the working set; the heavier the working set, the more the system needs cleanup and compression; the thinner the design's causal preservation, the more future modifications will rely on current code and local tests.

Thus, code complexity increases token costs, and token pressure in turn encourages shorter state retention and more localized patches. This is the mechanism behind “more iterations lead to more problems” in agent coding that warrants closer attention.

It is not an issue of a single model capability, but a system problem involving inconsistent precision in saved code and design states.

The Coding Agent has become increasingly capable of operating for extended periods, but "being able to run for hours" is not necessarily a good performance metric.

If an Agent works for 3 hours and then needs to reread a file it modified 2 hours ago, re-reason about why a certain abstraction exists, and rerun tests that have already been executed, then a significant portion of those 3 hours of computation is spent on state recovery.

The next question becomes: How much causal information valuable for future decisions can an Agent retain after 50 steps, 100 steps?

You can call it state fidelity.

Because it measures not how many tokens can fit into a context, but how much critical design information remains in an usable form after tool calls, compression, cross-session handling, and memory retrieval. This also means that an agent’s long-term memory cannot rely solely on longer contexts.

Some knowledge belongs in memory, such as project build methods and development habits; some decisions should be documented in structured ADRs or code indexes; and those that, if violated, would breach architectural boundaries are best enforced directly through types, tests, lint rules, dependency rules, and CI.

If a rule has been transformed into a software-enforceable constraint, the Agent does not need to "remember" it. In the next round, the Agent can forget a conversation, but it cannot easily bypass the compiler and tests.

If the fidelity is low, the longer the Agent runs, the more hidden risks it creates for the system.

This may also be the line the Coding Agent must cross to move from “being able to write code” to “being able to maintain software long-term”: gradually transferring design knowledge from probabilistic linguistic memory into software states that are retrievable, verifiable, and executable.

Otherwise, the longer it runs autonomously, the more absurd the situation becomes: the Agent writes code faster and faster, and the project changes rapidly, yet every so often, it must re-understand the world left behind from the previous period.

A common phrase in legacy code is: "Don't touch this, I don't know why it breaks."

AI legacy code might be even weirder: the code was indeed written by an Agent, but subsequent Agents no longer know why the previous Agent wrote it that way.