Claude Code’s Billing False Positive and Anthropic’s Developer Trust Problem

I hate making another video criticizing Anthropic, but this time a Claude Code billing incident deserves attention. A subscriber reported unexpected extra charges despite having most of their weekly allowance left. The company later acknowledged a bug, but the episode raises a larger question about how subscription restrictions interact with ordinary developer workflows.

The product distinction matters. A subscription gives an individual access to Claude Code under usage limits, while an API charges for consumption. Anthropic has restricted using subscription credentials with certain third-party tools; that policy is the backdrop for a detection mechanism that misclassified a legitimate session.

For a developer paying a fixed subscription, the expectation is that the included usage stays within that plan. Extra usage is a separate paid option. The reported problem was not simply that someone reached a normal limit: the system treated certain usage as something that belonged in the extra-billing path.

The original report involved the text HERMES.md appearing in Git-related context. That does not establish that every file with this name causes a charge or that the exact detection logic is known. The alarming part is that normal project context could interact with a third-party harness check and affect billing.

I still keep a Max subscription for testing. The amount of inference included in a high-tier plan can be substantial, and that helps explain why the economics of flat-rate access matter. It also makes it especially important for customers to understand when they are using the subscription and when another meter applies.

There is a plausible reason a provider might worry about third-party harnesses: different tools can send different prompts and use resources differently. But a possible economic concern does not excuse an opaque restriction or a billing mistake. To discuss the cost, we first need to understand prompt caching.

An AI model processes input tokens to produce output. When requests share a long prefix, a prompt cache can reuse intermediate computations for that prefix instead of processing it all over again. The model's weights are not rewritten by the prompt; the cached state is an optimization for repeated inference.

A coding agent repeatedly sends context such as instructions, conversation history and tool results. If a reusable prefix stays stable, caching can reduce repeated work and charges. If earlier parts change, the affected later prefix may no longer match, so the way a harness assembles its context matters.

Cache lifetimes and pricing also affect the result. A short-lived cache can expire between requests, while creating and retaining cached state has its own cost. The best choice depends on request frequency, shared prefix length and the provider's actual terms; it cannot be inferred from a single price line.

I have complained about cache behavior and changes in Claude Code before. Here I speculate that the company may be trying to control the cost of less cache-friendly third-party usage. That is my interpretation of the incentives, not proof of Anthropic's internal reasoning or the exact cause of this particular bug.

A poorly placed change in a system prompt can make reuse less effective, and changes to the harness can also affect the behavior users experience. These are implementation details with real consequences: users see latency, bills and answer quality, even if they cannot see the machinery behind them.

I have also argued that Claude Code became less reliable during earlier changes. My broader point is that an AI product is more than model weights: prompts, context management, caching and tools are part of the experience. Diagnosing a regression requires distinguishing those layers instead of assuming the base model alone changed.

Let me show a concrete bill from T3 Chat. We serve many requests through Anthropic's API, so this is API spending rather than my personal subscription. Our April dashboard shows roughly 11 billion input tokens and 650 million output tokens across models.

The dashboard gives a sense of scale, but raw token totals alone do not explain the invoice. Model mix, output volume, cache writes and cache reads all affect what a workload costs. Different products may have very different request patterns even when they use the same model.

The April token-cost view is about $39,818. I say that a large part of the bill had come from cache writes, and that around April 20 we stopped caching in this workload. Looking at the subsequent daily totals, I did not see a meaningful reduction in our bill.

That observation surprised me, but it is not a controlled experiment. Traffic, model mix, prompt length and other factors can change at the same time. It tells us to inspect our own usage rather than assume caching always saves money; it does not establish that caching is useless for everyone.

I think restricting outside harnesses is a poor way to address those economics. Developers build their own workflows for good reasons, and the boundary between a normal Claude Code feature and an external integration can be confusing. A billing policy needs a predictable boundary and clear feedback.

Claude Code itself supports noninteractive prompts with `claude -p`, as well as options for modifying the system prompt. I use these capabilities to demonstrate why detecting a third-party tool from text can be fragile: legitimate commands and ordinary context can contain material that resembles an integration.

In my demonstration I construct a prompt containing text associated with another agent. The result is a message about extra usage. This shows what happened in my test; it does not independently reveal the server-side implementation or prove that every similar request will be classified the same way.

With extra usage disabled, I see an error instead of a successful request. I then enable the paid option and repeat the test. The distinction matters: extra usage must be enabled for the demonstrated paid path, but an unexpected classification can still surprise someone who has enabled it.

The test appears to move usage onto the extra-usage meter even though I am invoking Claude Code itself. I find that disturbing because the words in a prompt should not silently change a customer's understanding of what they will pay. My inference about how the detection works remains a hypothesis.

Now return to the original report. The subscriber described a roughly $201 charge while only a small portion of the weekly subscription allowance had been used. The relevant text appeared in Git context, which the tool incorporated into its prompt; the person said they were using Claude Code normally.

The important distinction is between a deliberate policy for third-party harnesses and a false positive affecting ordinary use. A provider can choose its subscription terms, but customers need to know those terms and need protection from accidental charges when a detector makes a mistake.

Anthropic engineer Thariq Shihipar apologized and said the bug involved third-party harness detection interacting with how Git status was pulled into the system prompt. He said the company was reaching out to affected users with refunds and an additional month of credits, citing $200 in this case.

The public issue provides a useful record of the report and response: https://github.com/anthropics/claude-code/issues/53262. The acknowledgment supports the existence of this specific failure, not a claim that every potentially affected user has already received a refund or that the entire problem is resolved.

A refund and credits are the right response to affected customers. My criticism goes further: when a system classifies users for billing based on context that can include ordinary repository data, this kind of false positive is a product-design problem, not merely an awkward error message.

I have been harsh toward the team and distinguish the people building the product from decisions made by leadership. I am frustrated that the same themes keep recurring: restrictions, confusing changes, and an experience that makes developers feel their normal work is treated with suspicion.

I speculate about Anthropic leadership's attitudes and motivations, but those personal claims are my opinions, not established facts. The observable issue is narrower: a detection policy and a Git-context interaction produced an acknowledged false positive with billing consequences.

My larger complaint is about trust. Developers are being asked to integrate AI tools deeply into their work, while the rules and economics can change underneath them. A company that wants long-term adoption needs to make limits understandable and treat accidental failures as something to fix at the system level.

I also describe a separate T3 Chat incident in which Anthropic's automatic API rebilling failed and our users temporarily could not use its models. That is my account of our operational experience, not independent evidence that all customers experienced the same billing failure.

Despite spending heavily on the service, I feel the relationship has become unnecessarily adversarial. I contrast that experience with other providers and explain why I may direct more work elsewhere. Those comparisons are my experience and preference, not a general ranking of every provider.

Strong models are valuable, but a developer platform also has to offer dependable billing, clear policies and a way to trust routine tooling. My conclusion is that the company should address the incentives and product choices behind this incident, not rely solely on apologizing after users discover the charges.

I remain a substantial customer, which is precisely why these failures matter to me. I want the product to work for developers without making them second-guess whether normal project data will change the price of a session.