9 min read B2B FinOps

Anthropic API Pricing Hit a Billing Bug: A $5.04 Top-Up Cost $569.52

A decimal point in the Claude Console charged $569.52 for a $5.04 top-up. What the Anthropic API pricing bug means for your prepaid credits.

Anthropic API Pricing Hit a Billing Bug: A $5.04 Top-Up Cost $569.52

One keystroke. A user typed $5.04 into the Claude Console credit field, pressed Enter, and Anthropic charged his card $504.00 for the credits plus $65.52 in local Costa Rican VAT. Total taken: $569.52. For a top-up that should have bought five dollars of tokens.

The report went to Hacker News on October 16, 2026, and reached 87 points and 36 comments before an Anthropic engineer replied publicly that a typed “5,04” had been converted to $504 and that the company was fixing the bug. That reply matters, because it turns a support complaint into a confirmed defect in the billing pipeline that handles Anthropic API pricing.

This is not a story about a comma. It is a story about what happens when the place you keep your money and the place you spend your money are the same unguarded input field.

How the Anthropic API pricing bug actually happened

The mechanics are worth understanding, because almost every AI vendor now runs the same stack.

The reporter’s system was set to a locale that uses a comma as the decimal separator. His balance displayed as 430,26. The credits input field still accepted a period, so he typed 5.04. That is the correct thing to type in English and the wrong thing to type in a comma locale. A billing form that respected locale would have either rejected the string or normalized it to 5,04.

Instead, pressing Enter submitted the raw string to the backend before the frontend validation layer could intercept it. The backend stripped the separator and read the value as 504. Anthropic’s own help documentation says the Console should enforce a minimum purchase, and that a purchase in progress shows you an amount to confirm. Neither guard fired. The charge went straight to the payment gateway.

Then the failure compounded. Because the system now believed the base amount was $504.00, it calculated local VAT on top of that number and added $65.52. A bug that started as a parsing error became a tax error, because each downstream step trusted the corrupted value from the step before it.

To be fair to Anthropic, a company engineer responded within hours, acknowledged that the form did not account for internationalization, and said support would reach the customer directly. That is a better response than most. It is also not the point. The point is that a heavy user found the bug by losing money, and he found a human only by getting onto the front page of Hacker News.

Comparison panel showing an entered amount of 5.04 next to a charged amount one hundred times larger
The failure is a mismatch between what the field accepts and what the backend reads. Locale formats make that gap easy to hit.

Why this hits heavier users harder than it looks

The people who care most about Anthropic API pricing are the ones who buy credits constantly. A two-person shop topping up once a month has one risky interaction per month. An agency running Claude Code across a dozen repos may replenish credits weekly, sometimes more, and auto-reload can trigger a purchase with nobody watching at all.

That is the part of this story that deserves more attention than the $569.52.

Anthropic’s Console supports auto-reload. You set a threshold that triggers a purchase and a target balance to reload to. The help documentation says plainly that if your balance is already at or below the minimum when you enable it, the button reads “Turn on and purchase” and you are charged immediately to bring the balance up to the target, plus applicable taxes. There is no human in that loop by design. That is fine when the form is correct. It is a different risk profile when a locale parsing bug can multiply an input by a hundred.

Heavy users also have more surface area for the same class of mistake: multiple organizations, multiple billing roles, team members who can buy credits, cards that expire mid-run, and reporting that arrives late. Each of those is a place where a number can be wrong in a way that costs real money before anyone notices.

The reporting side broke too

Here is the cross-provider part of the story, and it is the part that should worry a FinOps owner more than the comma.

On October 9, 2026, OpenAI opened an incident on the Compliance API: costs data in that API was delayed. It was identified the same day, mitigated the next morning, and fully resolved on October 12.

A separate incident followed on a different endpoint. On October 14, OpenAI identified an issue causing delays in publishing organization cost data through the Costs API, said API and ChatGPT usage were unaffected and other reporting channels remained available, then processed a backlog before resolving on October 16.

Two different OpenAI reporting endpoints were late within a week, and Anthropic had a confirmed charge-side defect the same week. That is not a vendor-specific failure. From two companies, the charge and the reporting both went wrong in the same few days.

Cost reporting dashboard showing a delayed data feed with a backlog queue and a multi-provider spend comparison
When the Costs API lags, your dashboard keeps rendering. It just renders yesterday.

For a solo developer this is an annoyance. For anyone running AI spend as an operating line, it is the exact scenario where a late or wrong number quietly turns into an overage, a budget miss, or a charge that nobody can explain to the person holding the card.

Where the real exposure sits in your stack

If you spend $300 or more a month on AI, your exposure is not the token price. Token prices have been falling for a year and the last several releases cut them further. Your exposure is the set of surfaces where money leaves your account and where you learn about it afterward:

SurfaceWhat can go wrongWhat it costs when it does
Manual credit top-upLocale parsing, raw string submissionMultiples of the intended amount, plus tax on the inflated figure
Auto-reloadThreshold fires while nobody is watchingSilent charge at the moment of lowest balance
Monthly API credits on plansUnused credits expire at the end of each billing cyclePaid-for capacity that vanishes
Cost reporting APIsDelayed or incomplete dataDecisions made on stale spend
Shared organization rolesWrong member or org targeted on changeRecurring errors that are hard to trace

The third row is the one most heavy users miss. Claude Max and Team plans include monthly API credits, but they are spent before any credits you purchased, and unused monthly credits expire at the end of the billing cycle. They also cannot be used in Claude Code or in the Claude apps, including for extra usage. If you are sitting on a purchased balance while a monthly allowance is expiring unspent, you are paying twice for the same capacity and the invoice will not tell you.

What to do this week

Five controls, ordered by the amount of money they protect.

1. Turn off auto-reload, or make it a monitored event. If a purchase can fire without a human, then the human has to see it. Either disable auto-reload and top up manually on a schedule, or route the billing notification to a channel someone actually reads. An unreviewed auto-reload is a standing authorization to charge your card.

2. Set the smallest possible purchase amounts and buy more often. A ten-dollar top-up loses ten dollars to a parsing bug. A five-hundred-dollar top-up loses five hundred. Frequency is cheaper than size when the input field is the risk.

3. Verify the amount on screen before you press Enter, and after. Type the value, then look at the total due figure, then press the button. The reporter’s account shows the field and the confirmation can disagree. If they disagree, stop and use a different amount or a different browser locale.

4. Reconcile the bill against a second source. Do not trust a single cost dashboard. Keep your own usage log, by API key, and compare it to the provider invoice monthly.

5. Use a virtual card with a hard limit for AI billing. A single-use or limit-capped card turns a hundredfold error into a declined transaction instead of a disputed charge. This is the cheapest insurance in the entire stack and almost nobody does it.

Then do the boring thing: save the support thread and the incident pages. When you are arguing about a charge, a public acknowledgement and a dated status page are worth more than a screenshot of your own dashboard.

The takeaway for heavy AI users

The Anthropic API pricing story is not really about Anthropic, and it is not really about a decimal point. It is about the fact that the AI vendors now hold a live payment credential for nearly everyone who builds with them, and the software in front of that credential is young.

These billing systems were built in months. Payment infrastructure takes years, and the companies running it are absorbing growth at a pace that guarantees bugs. Some will be cosmetic. Some will take $569.52 from a card because you pressed Enter a half second too early.

What you control is the blast radius. Small top-ups. No silent auto-reload. A second copy of your usage data. A card that can only lose what you let it lose.

Anthropic will ship the fix, and probably this week. The next bug will ship somewhere else, on a form that looks just as trustworthy.