An LLM Will Do Your Arithmetic Wrong and Format It Perfectly

The number was wrong by a factor of 100, and nothing complained

Here is the trap, stated plainly: hand a language model a simple division and it will not fail loudly when it gets it wrong. It will hand you back a fluent, correctly-formatted, confidently stated number that happens to be off by 100x — and it looks exactly like a right answer.

We hit this in the ledger side of a finance app we’re building. There’s an AI insight feature that turns a user’s transactions into a plain-English summary. Amounts are stored the sensible way for money — as integer paise, so no floating-point rounding can creep in. The prompt handed the model those integers and asked it to do the obvious thing: divide by 100 and format as rupees.

The first time we ran it against the live OpenAI API instead of a mock, gpt-4.1-mini got 0 of 5 amounts right. Every single one was exactly 100x too large. An EMI of Rs.14,581.86 came back as Rs.14,58,186 — and note the digit grouping is correct for Indian numbering. The model didn’t drop a decimal at random. It produced a beautifully formatted, wrong-by-two-orders-of-magnitude figure and stated it with total confidence.

In a budgeting app, that’s not a cosmetic bug. That’s telling someone their EMI is fourteen lakh rupees.

Why this is worse than a normal bug

A normal bug throws, or returns something obviously broken, and your tests catch it. This one doesn’t announce itself. The output passes every eyeball check that isn’t arithmetic — right currency symbol, right grouping, plausible-looking magnitude if you’re not doing the mental division. It’s the specific failure mode a founder should worry about most: the system that’s wrong and confident, in a domain where confidence is exactly what makes people stop double-checking.

And it’s not fixable by prompting harder. “Be careful with the division,” “double-check your math,” “think step by step” — you can spend an afternoon on that and still be gambling on a token predictor doing exact arithmetic. It isn’t a calculator. It’s a very good guesser about what the next character looks like, and 1458186 looks a lot like a valid rupee amount.

The fix: give the model nothing to compute

We stopped asking. We wrote insight-render.ts, which pre-computes every derived number outside the model — the rupee strings, the comparisons like “over budget,” the totals. By the time the prompt runs, the only job it has with numbers is to copy them verbatim into a sentence.

That’s the whole principle, and it’s the transferable one:

Never let an LLM perform arithmetic or unit conversion on data you hand it — not even trivial-looking division or scaling. Compute every derived numeric fact outside the model and pass in finished strings. Give the model things to phrase, never things to calculate.

This is more restrictive than most prompt-engineering advice, and deliberately so. The moment a number in your output is one the model derived rather than copied, you’ve reintroduced the failure. Draw the line at “copy, don’t compute” and it’s easy to enforce in review.

The second trap: a workaround that masks the next bug

The same test session surfaced a related one worth flagging. On the gpt-5 reasoning family, sending temperature: 0 is a hard 400 error — the parameter isn’t supported. The obvious fix is to catch that error and strip the parameter.

The trap is how you catch it. If you match on the error code alone and blindly re-strip, you’ve built a machine for hiding future bugs: the same generic 400 code can mean something completely different next time, and your “known workaround” will silently swallow it. So we match on the specific parameter name and the error code together, and only strip temperature once we’ve confirmed that parameter is actually the cause. A different 400 gets to surface as itself.

Both bugs come from the same instinct — trusting a confident-looking response. The model’s confident wrong number, and the API’s confident-looking error code that means more than one thing. In both cases the fix is the same shape: don’t let one signal stand in for the thing you actually need to verify.