Anthropic Console Billing Bug: Typing 5.04 Charged $504 Due to Locale Decimal Handling

A developer using the Anthropic Console reported that typing 5.04 into the credit-purchase amount field was silently interpreted as 504 and charged to his credit card as $504.00 USD, roughly 100x the intended amount, with no confirmation screen before the transaction executed. The report, posted to Hacker News as item 50121562, describes a locale-dependent input-parsing failure combined with an automated support process that declined the refund.

The core claim is that a decimal separator typed by a user in a comma-decimal locale was stripped rather than rejected or normalized, and that the resulting amount was submitted to the payment gateway immediately.

What the reporter says happened

The poster identifies himself as a LegalTech attorney leading a developer team in Costa Rica. According to the post, he attempted to add credits to his Anthropic API account and was prompted for a payment amount. Because he works in a Spanish-speaking region where localized systems commonly use the comma as the decimal separator, he typed 5.04.

According to the post, the system did not raise a formatting error and did not convert the value. Instead it stripped the decimal internally and charged $504.00 USD. The poster states there was no confirmation modal or review screen summarizing the final amount before processing.

The reporter's replication of the bug

In a follow-up comment on the same thread, the original poster said he reproduced the input-validation failure inside the console. His description of the mechanism:

"when your regional settings use commas for decimals (e.g., my balance shows 430,26), the input field still physically allows you to type a dot (0.5 or 5.04). The catastrophic UX failure happens when you press 'Enter' right after typing. The form instantly submits the raw, un-sanitized input string to the backend before the frontend validation layer can block it or correctly alert the user."

He further claimed the behavior bypasses the platform's own stated minimum:

"The system breaks its own 'USD 5.00 minimum' rule, bypasses proper error prevention, and immediately fires the payment request to Stripe/the gateway."

These are the reporter's characterizations of the system's behavior, not independently verified findings.

The charged amount grew with tax

In a separate update, the poster said the final amount taken from his card was higher than $504.00 because local VAT was calculated on top of the incorrect base amount:

"Because the system processed the incorrect $504.00 base amount, it automatically calculated local VAT (taxes) on top of it, adding an extra $65.52. The absolute total taken from my card by this single-click bug is $569.52."

The support experience

The poster states he filed a complaint the same day and was routed to an automated support bot rather than a human. According to the post, the bot denied the refund and closed the ticket by citing generic policies without a human reviewing the claim that the overcharge originated from a platform bug.

He also states he initiated a chargeback with his bank in Costa Rica, and that banking processes there can take up to 120 days to resolve, leaving the charge on his statement in the meantime.

Counterpoint: the total was displayed on screen

One commenter pushed back on the claim that the amount was never surfaced. User striking reported checking the "Add credits" screen at platform.claude.com and observing that the total due updates visibly:

"I'm looking at the 'Add credits' screen on https://platform.claude.com and it prominently displays the 'total due' as $504.00 when typing 5,04 into the input..."

That observation is notable for two reasons. First, it suggests the field may treat the comma as a thousands separator rather than a decimal separator, which would produce 504 from 5,04 as well. Second, it indicates the computed total is rendered before submission, which is a weaker safeguard than a confirmation step but is not the same as a silent charge. The reporter's position is that a displayed total is not a confirmation modal and that the input should have been rejected as ambiguous.

Another commenter, merb, questioned the input itself:

"What did you want to accomplish with 5.04?? In Spanish or other European countries 5,04 would've been correct? So 5.04 would either be invalid or 504 like Claude did."

Why the failure mode matters beyond one transaction

The reporter frames the issue as systemic rather than personal. His argument is that the same parsing path scales with the number typed: an input of 50.00 under the same behavior would produce a $5,000.00 charge. He also argues that financial software should reject ambiguous numeric input rather than guess at its meaning.

"In financial software, a system is never supposed to guess or automatically manipulate a numerical input without explicit validation. If an input is ambiguous due to locale differences, the application must reject it or ask for clarification, not execute a 100x overcharge."

The asymmetry of automated support

The most widely echoed concern in the thread was not the parsing bug itself but the inability to reach a human who could recognize an obvious mistake. Commenter clickety_clack framed it as a structural imbalance:

"This is the kind of mistake I dread, where a normal human would be able to say 'oh, sure of course this is a mistake, sorry about that', but you don't get to talk to a human. A corporation can wait months for resolution, but an individual can't."

Commenter nottorp raised adjacent questions about payment controls, asking whether these payment UIs accept single-use virtual card numbers and whether 3D Secure is supported for European cards. Those questions were not answered in the thread.

One commenter, UnlockedSecrets, questioned whether the original post was written with AI assistance. That comment received no substantive follow-up in the visible thread.

What remains unresolved

The thread contains no response from Anthropic confirming or disputing the bug, no statement that a fix was shipped, and no indication that the refund was granted. The reporter's replication claim and bank-statement screenshots are self-reported. The one independent check in the thread, from striking, confirms that the console displays a computed total due of $504.00 for the input 5,04, which is consistent with the reporter's account of the charge amount but does not by itself establish the exact parsing path or whether a confirmation step exists.

The generalizable lesson for anyone building payment inputs

A currency amount field that accepts free-form text must resolve the decimal separator explicitly, not infer it. The failure pattern described here has three separable components, each of which is independently preventable:

• Ambiguous input accepted silently. A value containing a separator that does not match the user's locale should be rejected with an error or normalized with a visible echo of the interpreted value.
• No confirmation step before an irreversible charge. A displayed running total is not the same as an explicit confirmation of the final amount and currency.
• Automated support with no escalation path. A refund denial issued by a bot with no human review leaves the affected party with only the slow chargeback route, which the reporter says can take up to 120 days in Costa Rica.

For developers integrating any metered API billing, the practical takeaway is to verify the amount shown at checkout against the amount intended, and to prefer payment instruments that allow per-transaction limits or single-use numbers where the vendor supports them.