On July 7 at 10:20 p.m., a developer in South Korea received an email notifying him that a payment had failed. The amount billed was $1,669,875.90. He initially suspected phishing. However, both the sender address and the payment link led to Stripe’s official invoicing system, which Anthropic uses to process payments.
The same thing happened again the following day. At 11:42 p.m. on July 8, a second failed-payment notice arrived, this time for $16,627,739.70. The amount had increased roughly tenfold in a single day, reaching approximately 24.7 billion won. This was not merely an incorrectly generated email. The payment request had reached the actual financial system, and the money was not withdrawn only because the linked card declined the transaction.
The user operated several AI agents and automated scripts. At first, he suspected that something in his own system might have repeatedly called the Anthropic API. He checked his bots, workers, proxy servers, and scheduled tasks, but found no API key capable of generating actual charges. The Anthropic dashboard also showed zero API usage. He ultimately canceled his Claude Max subscription and blocked the registered payment card.
The cause was disclosed only about a week after the incident. According to Anthropic’s response to the user, the account’s automatic top-up amount had been incorrectly configured to a value far outside the normal range. The company disabled automatic top-ups, restored the setting to its default value, and stated that neither unauthorized access nor account compromise had occurred. No money was ultimately withdrawn. Anthropic did not explain, however, why the erroneous top-up value had produced a payment request exceeding $16.62 million, or why no safeguard had stopped such an abnormal amount.
The incident did not end with the billing error itself. The user sent 15 emails through several channels, including customer support and the company’s technical and marketing departments. Only four days later did he receive an automated message saying that the case would be forwarded to an actual representative. Despite a payment request worth tens of billions of won, there appeared to be no procedure for classifying it as an emergency and immediately assigning it to a human responder. Anthropic later said that the issue had been resolved through communication with the customer, but announced neither compensation nor any additional follow-up measures.
What matters here is not whether 24.7 billion won was actually withdrawn. A massive invoice was generated for an account showing zero usage, the payment request reached the financial system, and the user had to spend several days proving that the charge was erroneous.
An AI bill is not created in a single moment. A task becomes one or more model calls, those calls are recorded as usage, and prices, discounts, subscription limits, and additional usage charges are then applied. An invoice is subsequently generated and payment is executed. This incident demonstrates that when any one of these stages goes wrong, the error can pass directly into the next.
Was this merely an isolated anomaly affecting a single user account?
This Was Not a One-Off Error
The 24.7 billion won invoice was extreme in scale. That incident alone, however, is not enough to conclude that Anthropic is engaging in widespread overbilling. Yet other recently disclosed cases show that AI billing can go wrong in more than one way.
In April, an error was discovered in which a single string altered the billing path used by Claude Code. When the uppercase string HERMES.md appeared in a Git commit history, requests that should have been included within a Claude Max subscription were instead classified as separate “extra usage.” The user who reported the problem said that $200.98 in additional usage credits had been consumed even though most of the weekly allowance under the $200-per-month Max plan remained available. A reproducible procedure was also published showing that the problem disappeared when the string was changed to lowercase or removed from the commit history.
The issue was categorized as a cost-related bug and closed in Anthropic’s official Claude Code repository. An Anthropic representative said that affected users would receive refunds as well as an additional $200 in credits, equivalent to one month of the Max plan. This was not a case of usage spiraling out of control. The activity itself was normal, but the system misclassified the nature of the requests and routed their cost through a different billing channel.
Similar discrepancies have also been raised in corporate invoices. AI cost-auditing company Vaudit said it reviewed $34 million in AI spending across 60 companies between March and June and identified approximately $1.7 million in overcharges. That represented around 5 percent of the invoices examined. According to Vaudit, roughly 80 percent of the disputed amount was subsequently adjusted through credits issued by providers or cloud platforms including Anthropic, OpenAI, AWS, Google Cloud, and Microsoft Azure.
Vaudit identified several different types of error. These included higher rates being applied than those associated with the model actually used, charges attached to requests that returned no result, and duplicated costs accumulating when agents repeatedly retried failed tasks. In other cases, billing continued during service outages, or a cloud orchestration error sent a single request to two models at once. Vaudit says it installs separate software in customers’ AI environments to collect raw usage records and compare them with provider invoices.
These figures should not, however, be treated as the average error rate for the AI industry as a whole. The 5 percent figure comes from invoices audited for 60 Vaudit clients, and Vaudit itself sells an overbilling-detection service. The selection process for the sample and the details of individual companies have not been fully disclosed. The findings therefore do not prove that approximately 5 percent of all AI charges are universally incorrect. They are better understood as evidence that meaningful discrepancies can emerge when enterprise usage records are compared with provider invoices.
Anthropic did not fully accept Vaudit’s characterization. The company said that it does not charge for incomplete requests or error messages and does not route user requests to different models without disclosure. It also maintained that it had found no evidence indicating widespread overbilling.
Responsibility cannot necessarily be assigned to a single company either. Around half of the billing decisions examined by Vaudit involved an intermediary platform such as AWS Bedrock, Google Vertex AI, or Microsoft Azure between the model provider and the customer. Errors may therefore arise while determining which model receives a request or during the generation of the final invoice by the intermediary platform.
The publicly available evidence is not sufficient to conclude that Anthropic’s entire billing system is structurally broken. Yet the 24.7 billion won incident cannot simply be dismissed as a mistyped number. An abnormal automatic top-up value becoming an invoice, a valid subscription request being classified as additional usage, and enterprise records failing to match provider invoices all occurred at different points in the billing process.
One was an invoice-generation error unrelated to usage. Another was a classification error that selected the wrong billing path. A third was a discrepancy that could be discovered only after comparing an enterprise invoice involving multiple providers and cloud platforms against independent records.
The problem is not simply that similar incidents have happened more than once. Different types of error can enter at different points in the process by which AI costs are produced, while users can see almost none of that process before the final invoice arrives.
Where Does an AI Invoice Go Wrong?
An AI bill does not begin as a single number. A user’s instruction becomes multiple model calls, each call is measured in tokens, and model-specific prices, subscription limits, extra usage, and prepaid credits are then applied. Only after these stages is an invoice generated and payment processed. The amount ultimately presented to the user is the result of passing through this entire chain.
There is therefore no single reason why an AI bill may differ from what was expected. Actual usage may surge, or usage may remain normal while a different price is applied. The usage record may be correct even as an error enters during invoice generation. All of these may appear to the user as “overbilling,” but they originate at different points.
Generating Consumption — One Instruction Becomes Repeated Calls
In a conventional chatbot, one question generally produces one answer. An AI agent such as Claude Code, however, may read files, modify code, execute commands, inspect test results, and then repeat the work when necessary. Even when a user gives only one instruction, several model calls and tool operations may take place internally. This is one reason Anthropic provides a separate --max-turns option that limits the maximum number of agent turns in non-interactive tasks. Tool definitions and execution results also count toward input and output tokens, while server-side tools may incur additional charges.
Under this structure, costs can rise faster than expected even when the system is functioning correctly. Usage continues to accumulate when an agent retries after every failure, repeatedly reads multiple files, or invokes another agent. This is not an incorrect charge; it is actual consumption. The user may think of the work as one assigned task, while the billing system counts every call generated within that task.
Uber’s experience illustrates this difference. CEO Dara Khosrowshahi said that the company exhausted an AI token and infrastructure budget intended for all of 2026 in roughly three to four months. He explained that as it became harder to determine how increased token consumption translated into actual product improvements, the company had begun recalculating the relationship between staffing and AI infrastructure spending. This is not evidence of a billing error. Rather, it shows that even correctly measured AI usage can exceed the pace and scale assumed by traditional software budgets.
Measuring Usage — Users See Only the Numbers Calculated by the Provider
Once usage occurs, the next stage is measurement. Anthropic reports input and output tokens as well as cache usage in API responses. It also provides enterprise customers with administrative tools for viewing usage and costs by API key, workspace, and model. Claude Code usage and costs can likewise be examined by organization and user.
Even with this level of detail, however, the provider remains the primary metering authority. The provider’s systems determine how many tokens a request contained, whether caching applied, and which model and service tier were used. The dashboard and cost reports visible to the user simply present the results of those internal determinations.
With electricity billing, an external meter can be installed and compared against the supplier’s measurements. In AI services, customers cannot easily reproduce the provider’s usage records independently unless they retain their own call logs or operate an intermediary gateway. This is why Vaudit collects separate records within customer environments and compares them with provider invoices. The problem is not the absence of a dashboard. It is that the dashboard and the invoice are produced by the same metering system.
Applying Prices — The Same Task Can Cost Differently Depending on the Route
The measured usage must then be assigned a price. At this stage, the route through which the service was accessed matters just as much as the amount consumed.
Claude subscriptions and API usage operate under separate billing systems. Even when a user still has Claude Code usage available under a Pro or Max subscription, Claude Code will authenticate through an API key rather than the subscription account if an ANTHROPIC_API_KEY environment variable is configured on the computer. In that situation, the activity is billed at standard API rates rather than deducted from the subscription allowance. Anthropic’s own support documentation states that the two billing systems are separate and that the API-key environment variable takes precedence over subscription authentication.
Corporate environments involve even more possible routes. Claude Code may connect directly to the Anthropic API, but it can also operate through Amazon Bedrock, Google Cloud, a Microsoft cloud environment, or a separate LLM gateway. When gateway credentials are used, the individual user’s Claude subscription does not apply. Token costs are instead charged to the organization or cloud account routing the request. The same task performed through the same Claude Code interface may therefore be assigned to a different payer and billed differently depending on the authentication credentials and connection path.
The HERMES.md incident described earlier was a failure at precisely this classification stage. When a particular string appeared in a recent commit message, requests that should have been covered by the Max plan were routed into separate additional usage. The user had not performed more work or deliberately selected a more expensive model. The system simply misjudged which cost category should receive the requests.
AI usage can therefore be measured correctly while the final charge remains wrong. Counting tokens and attaching a price to those tokens are separate processes.
Generating the Invoice — Usage and Billing Diverge
Once prices have been applied, the invoice is generated. Under normal circumstances, the sum of usage multiplied by the relevant rates should become the billed amount. The 24.7 billion won phantom invoice demonstrates that this connection is not always guaranteed.
Anthropic identified an incorrectly configured automatic top-up function as the cause of the incident. The company disabled automatic top-ups, restored the setting to its default value, and explained that no money had ultimately been withdrawn. It did not disclose, however, what calculation transformed the erroneous setting into an invoice exceeding $16.62 million.
The publicly available information does not allow a definitive description of how Anthropic’s internal system operated. The outcome nevertheless shows that the dashboard’s zero-usage figure did not function as a final validation condition capable of blocking the massive invoice. Separate settings and automatic top-up logic existed between the usage display and the invoice-generation system, and one of those elements appears to have remained misconfigured as the process advanced to the next stage.
The incident challenges the assumption that accurate usage measurement automatically produces an accurate invoice. AI charges may appear to be a simple multiplication of usage by price, but credit balances, automatic top-up thresholds, monthly limits, subscription status, and billing cycles also affect the final amount. Usage and billing are connected, but they are not the same number.
Executing Payment — Abnormal Amounts Still Move to the Next Stage
The generation of an invoice does not necessarily mean that a card payment will succeed. Spending caps, user confirmation, and fraud or anomaly detection can intervene before payment is completed.
Anthropic’s current guidance states that Pro and Max users can set monthly limits for additional usage and configure automatic top-up thresholds, with notifications issued as usage approaches the limit. User confirmation is also required when purchasing credits or modifying automatic top-up settings in Claude Code. API organizations can establish monthly spending limits and separate caps for individual workspaces.
These functions can help prevent ordinary usage growth, leaked credentials, or poorly written retry loops from producing uncontrolled expenditure. They may be insufficient, however, when the safeguard monitors only values deliberately entered by the user and the configuration itself becomes abnormal inside the system. What the 24.7 billion won incident required was not merely a monthly limit. It required a separate mechanism comparing the charge against the account’s normal payment history, actual usage, and current status.
For example, when an account showing zero usage generates a charge worth tens of billions of won, the payment could be paused for human review before any request is sent to the card issuer. When an account that normally spends tens of dollars suddenly generates a multi-million-dollar charge, the owner could be required to approve it again regardless of the existing limit.
Payment-system safety does not arise solely from preventing all errors. It also depends on the ability of a later stage to recognize and stop an abnormal value received from an earlier one.
After the Incident — Billing Is Automated, but Corrections Are Extremely Slow
The final stage begins after an incident has occurred. An automated billing system can calculate usage, generate an invoice, and submit a payment request. Correcting an error, by contrast, requires the user to assemble usage records, invoices, and card authorization details, explain the problem, and wait for a customer-support representative to verify the case.
The difference in speed is stark. An erroneous charge can move automatically into the next stage, while reversing it depends on human judgment. Even when no money is withdrawn or the amount is later refunded, the user may still face an account suspension, card replacement, interrupted work, and hours spent communicating with support.
Responses to billing errors should therefore not be assessed solely by whether the money was refunded. It also matters whether a large abnormal charge was separated from ordinary inquiries and immediately escalated, whether users were forced to repeat the same explanation, and whether adequate records existed to determine where the error entered the process.
The process by which an AI invoice goes wrong can ultimately be divided into six stages. Consumption may be higher than expected. Usage may be measured incorrectly. A wrong price may be applied to accurate usage. A separate error may enter during invoice generation. The incorrect charge may fail to be stopped before payment, and correcting the incident may take much longer than generating the charge.
Fixing only one of these stages is not enough. AI billing becomes safe not merely when every stage functions accurately, but when each stage is also capable of detecting and stopping an error passed forward by the stage before it.
Who Should Build the Safeguards for AI Billing?
If billing errors can arise at several stages, the responsibility for preventing them cannot rest with only one party. Providers must control the billing systems themselves, companies must manage consumption within their organizations, and individual users must understand which accounts and authentication routes they are using.
These three parties, however, do not carry equal responsibility. Providers possess the authority to measure usage, apply prices, and generate invoices. Most users can do little beyond checking the settings made available by the provider and responding after an error has already occurred. The first line of responsibility must therefore lie with the companies that design and operate the service.
Errors Providers Must Prevent
The first safeguard providers should establish is cross-validation between usage and billing. If usage, the applied model, the authentication route, the automatic top-up value, and the final invoice do not correspond, invoice generation should be suspended. It is not enough to confirm that each individual subsystem processed its input correctly. The outputs of different systems must also be checked to determine whether they remain consistent within a reasonable range.
The second requirement is a separate threshold for abnormal amounts. Monthly spending caps are designed to protect the budget selected by the user. They should be supplemented with systems that detect sudden increases relative to normal payment patterns. Charges unrelated to recorded usage, charges vastly exceeding previous payments, and high-value transactions on long-inactive accounts could all be placed on automatic hold.
Third, billing routes must be transparent. Users should be able to see not only the final amount, but also which credentials were used, whether the cost was deducted from a subscription allowance or API credits, and which model and cloud route processed the request. Records capable of tracing the cause should remain available when an error occurs.
The final requirement is an emergency response system. A multimillion-dollar abnormal charge should not enter the same support queue as a routine question about using the product. When a charge exceeds a defined threshold or a financial institution declines the transaction, the case should automatically be escalated to a high-value billing procedure and reviewed immediately by a human representative.
Spending Companies Must Control
Companies should not rely exclusively on the provider’s dashboard. They need to maintain independent usage records. Anthropic itself states that organizations can use an LLM gateway to track usage by user and team, set budgets and request-rate limits, and retain audit logs of all model calls.
The important point is to combine financial limits with technical limits. A monthly budget alone may identify a short burst of excessive usage too late. A per-minute request limit, meanwhile, may fail to prevent waste that continues slowly over an extended period. Spending caps by project, department, and user should be combined with limits on maximum agent turns, retry attempts, and concurrent executions.
Costs should also be examined by task rather than only by model. Knowing how many tokens a department consumed does not establish whether the spending was justified. Companies need to connect the amount spent on a particular feature, document, or customer-support automation with the output it produced. Uber’s attempt to determine how token consumption related to actual product improvements reflects the same problem.
Finally, provider invoices must be compared regularly against internal logs. Looking only at the total amount after receiving a monthly invoice makes it difficult to identify discrepancies by model, account, or project. Usage and cost reports should be divided by API key, workspace, and model, with significant differences investigated before payment. Anthropic provides enterprise customers with usage and cost reports as well as workspace-level spending limits.
Billing Routes Individuals Must Check
The first thing an individual user should confirm is how Claude Code is being accessed. Even when the user believes they are logged in through a subscription account, an API-key environment variable remaining on the system can trigger API billing. Subscription usage and API credits are separate systems, so the login status, environment variables, and the dashboard from which charges are actually being deducted should be checked together.
Users who enable additional usage should also review their monthly limits and automatic top-up thresholds. Automatic top-ups prevent work from stopping, but they can also allow costs to continue increasing when a faulty script or leaked key is involved. It is safer to begin with a low limit and raise it only after normal usage patterns have been established. Enabling card-payment alerts, revoking unused API keys, and separating keys by project can also limit the scale of potential damage. Anthropic likewise recommends monitoring usage by API key and applying spending limits.
When an abnormal charge is discovered, the user should prepare to contact the provider and dispute the transaction with the card issuer at the same time. Dashboard screenshots, invoices, payment times, and usage logs should all be preserved. These steps, however, take place after the incident. A user’s failure to enable payment alerts or inspect an environment variable cannot transfer responsibility for a provider’s billing error onto that user.
Individual checks are only the final line of defense. Users may discover an abnormal charge, but they cannot prevent an erroneous invoice from being generated inside the provider’s system.
The Calculation Process Is a Bigger Problem Than the Price
AI costs are difficult to predict not simply because people use too much. A single prompt may trigger several model calls and tool operations, and token consumption can increase rapidly as an agent is given more autonomy. Yet cost uncertainty originates deeper than usage growth alone. Even when usage does not increase, a single classification or configuration error can cause the billed amount to jump unexpectedly.
Modern AI billing is an automated pipeline in which consumption, measurement, classification, price application, invoicing, and payment operate in rapid succession. This seamless connection has accelerated settlement, but it can also pass an error directly from one stage to the next. A measurement mistake becomes a pricing distortion, and the pricing distortion becomes an incorrect invoice. What is needed is not optimism that the system will remain free of defects. It is a safeguard capable of stopping the process before an anomaly advances into the next stage.
Under the current structure, most of the relevant information remains on the provider’s side. The provider possesses the data required to measure usage, apply prices, and generate the invoice. The user begins tracing the process backward only after receiving the final result.
The question left by this case is therefore not how large the bill became.
When the provider controls the entire calculation process, should the user also bear the burden of proving that the calculation was wrong?
That imbalance is the most difficult problem embedded in AI billing.
