You've probably had this exact moment. You ask an AI a math question. It lays out the steps beautifully, explains the logic like a patient tutor, walks you through each stage with total composure — and then hands you a final number that's just… wrong. Not wildly wrong, usually. Confidently, plausibly, subtly wrong. The kind of wrong you might not even catch.
It feels absurd. How can something that writes working code, explains quantum physics, drafts legal arguments, and reasons through genuinely hard problems fumble arithmetic that a $2 calculator nailed in 1975?
The instinct is to think the model is "just not good at math yet" — a gap the next version will close. But that's not really it. The truth is more interesting: the AI is doing something completely different from what you assume it's doing when it "solves" a math problem. It was never calculating in the first place.
Once you see what's actually happening under the hood, the mistakes stop being mysterious and become totally predictable — and, crucially, easy to work around. Let's break it down, no math degree required.
The Core Idea: An LLM Doesn't Calculate — It Predicts
Here's the single most important thing to understand, and everything else in this article follows from it.
When you type 4827 × 391 = into a calculator, the calculator executes a rule. It runs a precise, deterministic multiplication algorithm — the same steps every time — and returns the one correct answer. It doesn't "think." It computes. Give it the same input a million times and you get the same output a million times, guaranteed.
An LLM does nothing of the sort. It doesn't compute anything. At its core, it does exactly one thing: it predicts the next most likely chunk of text, based on the statistical patterns it absorbed from a massive pile of training data.
So when you ask it a math question, it isn't multiplying. It's asking itself, in effect, "Given this string of characters, what text most plausibly comes next?" — the same process it uses to finish the sentence "The capital of France is ___." It's pattern-completing its way to an answer that looks like the kind of thing that follows a math question, not calculating its way to one.
For language, this is genuinely miraculous. For math, it's a fundamental mismatch. Here's why, in one line:
Language is statistical. Math is exact.
In writing, "close enough" is not just acceptable — it's how language works. Several different words could reasonably finish most sentences, and picking a slightly different one still produces something fluent and correct. There's flexibility, tolerance, wiggle room.
Arithmetic has none of that. There is exactly one correct answer to 4827 × 391, and being close counts for absolutely nothing. 1,887,357 is right; 1,887,000 is just as "wrong" as 42. A system optimized to produce the most probable-looking continuation is playing a game with tolerance built in — and then being graded by a subject with zero tolerance.
This is the deep reason an LLM can explain how to solve a problem flawlessly while getting the answer wrong. Explaining the method is a language task — it's describing a familiar pattern in words, which the model excels at. Executing the calculation is not a language task at all. The model is fluent in the description of math without being able to do the math. It's like someone who can perfectly recite how to ride a bike but falls over the moment they get on one.
Reason Two: The Tokenizer Scrambles Numbers
There's a second, sneakier culprit — and if you read my earlier post on how tokens work, this will click instantly. If you didn't, here's the short version.
Before a model ever "sees" your text, that text gets chopped into tokens — chunks the model treats as single indivisible units. For words, this works beautifully. For numbers, it quietly sabotages everything.
The problem: the model does not see 87439 as the value eighty-seven thousand, four hundred thirty-nine. It sees one or more arbitrary tokens — maybe 874 and 39, maybe 8 + 743 + 9, depending entirely on how that particular tokenizer happens to split it. And here's the kicker: to the model, that token is just an ID in a vocabulary. The token for a number chunk is no different in kind from the token for "apple" or "idea." It's a symbol. It carries no built-in sense of quantity, of place value, of which digit is in the tens column versus the thousands column.
Think about what arithmetic actually requires. To multiply or add by hand, you rely entirely on positional structure: you line up the ones, the tens, the hundreds; you carry the 1 from one column to the next; the position of each digit is the whole game. That's the exact structure tokenization blends away. The model is being asked to do column-based math on numbers whose columns have been mashed into word-like blobs before it even starts.
This isn't just theory — it precisely predicts what we observe:
- Models handle
3 + 4almost perfectly. Small single-token numbers, seen constantly in training, with tons of clean examples to pattern-match against. - Models fall apart on
8743 × 4397. Unfamiliar multi-token number patterns the model rarely (if ever) encountered in exactly that form, requiring real column arithmetic it fundamentally can't perform.
Neither case involves actual calculation. In both, the model is pattern-matching. The small sums just have vastly better patterns available to match against. It's not doing easy math correctly and hard math incorrectly — it's recognizing familiar answers and guessing at unfamiliar ones.
(Interesting side note: researchers have found that changing how numbers are tokenized — for instance, forcing single-digit tokens, or aligning them right-to-left the way we actually do arithmetic — measurably improves models' math performance. That's strong evidence that tokenization really is a core part of the problem, not a side detail.)
Reason Three: It Learned From Words, Not Numbers
Now stack a third factor on top of the first two.
LLMs learn from an ocean of human text — books, articles, websites, forums, code. And that corpus is overwhelmingly language, not computation. The model read enormous amounts of writing about math, but comparatively little that would teach it to treat numbers and operators as mathematical entities governed by rigid, universal rules.
The consequence is subtle but important. The model learned that the string 2 + 2 = 4 is a common, expected sequence of text — the way it learned that "peanut butter and ___" is usually followed by "jelly." What it did not learn is the underlying rule of addition that makes 2 + 2 = 4 true and would let it reliably compute 2837 + 4991 it had never seen before. It memorized the appearance of correct math without absorbing the machinery that generates it.
So common results — small sums, famous constants, textbook examples — are effectively baked in as familiar text patterns, and the model reproduces them reliably. But step off that well-trodden path — big numbers, long multiplication, multi-step word problems, anything requiring genuine calculation rather than recall — and there's no reliable pattern to lean on. At that point the model does what it always does when it's uncertain: it generates a confident, plausible-looking guess. And because of everything we covered in the hallucination discussion, it delivers that guess with exactly the same self-assured tone it uses for things it's certain about.
That false confidence is arguably the most dangerous part. A tool that was obviously bad at math would be safe — you'd never trust it. A tool that's subtly, confidently, occasionally wrong is far trickier, because it lulls you into trusting numbers you should be checking.
"But It Shows Its Work Now" — Doesn't Reasoning Fix This?
Fair question. You've probably seen newer models "think step by step," lay out their reasoning, and get math right far more often than older ones did. So is the problem solved?
Not really — and understanding why not is genuinely useful, because it's a widespread misconception.
Chain-of-thought prompting (asking the model to show its work step by step) does improve math accuracy, sometimes dramatically. But here's the misconception: it does not give the model a calculator in its head. It doesn't turn a probability engine into a symbolic reasoner. There's no hidden arithmetic unit that switches on.
What it actually does is nudge the model to generate intermediate steps that resemble careful reasoning. Breaking a big problem into smaller pieces steers the model toward better statistical patterns at each step — and each small step (7 × 8, then carry the 5...) is more likely to match something familiar from training than one giant leap to the final answer. So the scaffolding helps. A lot, sometimes.
But it's still prediction with better scaffolding, not calculation. The model is now guessing in smaller, more-familiar increments — which improves the odds — but it's fundamentally still guessing. That's why step-by-step reasoning makes models better at math yet never reliable at it. You've upgraded the quality of the guessing; you haven't replaced guessing with computing.
For a quick estimate or a small sum, better guessing is often good enough. For anything where a wrong number actually costs you — money, a medical dosage, an engineering spec, a financial model — "improved guessing" is not a foundation you want to build on.
The Real Fix: Don't Make the Model Do the Math
Here's the reframe that turns all of this from discouraging into genuinely practical.
The solution to LLMs being bad at math was never "wait for a model smart enough to become a calculator." That's the wrong goal. Making a language model internally reliable at exact arithmetic is fighting against the very thing that makes it a good language model. The right solution is architectural, and it's beautifully simple:
Let the LLM do what it's great at, and hand the math to a tool that's great at math.
This is called a hybrid system, and it plays to each part's strengths. The language model handles what it's genuinely brilliant at: understanding your messy, ambiguous, real-world request; figuring out what actually needs to be computed; setting up the problem; and explaining the result in plain language afterward. Then, for the actual calculation, it hands off to a deterministic tool — a calculator, a line of Python, a spreadsheet formula — that follows exact rules and returns the one correct answer, every time.
The model orchestrates. The tool computes. Neither tries to do the other's job.
This is exactly why modern AI systems increasingly run code or call a calculator behind the scenes rather than "doing the math in their head." When a model writes and executes a small Python snippet to evaluate 4827 × 391, you get 1,887,357 — reliably — because a real computation engine produced it, not a probability distribution over plausible-looking digits. The model's job was to recognize that a calculation was needed and route it correctly; the computer's job was to actually calculate.
This "model reasons, tools compute" principle is the design philosophy behind adaptive workspaces like Xenition (disclosure: it's a product I work on). Instead of trusting the chat to crunch numbers in its head, the right surface for the job opens itself — a spreadsheet with real, executing formulas for financial work; a code editor that actually runs for anything computational; a document for the write-up around it — and the system routes each part of your request to the tool built to handle it. The language model stays the brain; the exact work happens where exactness actually lives. Whether you use a workspace like that, a plain "run this in Python" instruction, or just paste the numbers into a spreadsheet yourself, the underlying move is identical: stop asking the writer to be the calculator.
What This Means for You, Practically
Whether you're a casual user or building on top of these models, a handful of habits will save you from confident-but-wrong numbers:
Don't trust raw LLM arithmetic — especially when it matters. Big numbers, long calculations, chained operations, percentages, and anything financial, medical, or legal are exactly where quiet errors hide. The model's calm, confident tone is not a signal of correctness; it sounds identical whether it's right or wildly off.
Make it use a tool. The single highest-leverage move: explicitly ask the model to "use code to calculate this" or work in an environment where it can actually execute the computation. This one instruction converts unreliable guessing into a real, verifiable answer. If your tool supports running code or has a calculator/spreadsheet surface, use it for anything numeric.
Split the labor deliberately. Use the model for what it's good at — interpreting your problem, choosing the right formula or approach, explaining what the numbers mean, catching conceptual mistakes. Let a calculator, script, or spreadsheet handle the exact figures. You'll get the best of both: language intelligence and numerical correctness.
Sanity-check anything important. Even with tools in the loop, glance at the result and ask "does this order of magnitude make sense?" A quick estimate in your head catches a surprising number of errors — from the model and from your own setup.
Be especially careful with multi-step word problems. These stack the risks: the model has to parse language (its strength) and do several calculations (its weakness), and one small arithmetic slip early cascades through everything after it, producing a confident final answer built on a broken step.
The One-Sentence Version
LLMs are bad at math because they don't actually calculate — they predict likely-looking text, and their tokenizer scrambles the exact positional structure that numbers depend on. They're extraordinary language engines, not calculators, and no amount of "reasoning" fully changes that.
So stop asking the brilliant writer to be a calculator. Let the model think, frame, and explain — and let a real tool do the counting. Play each to its strengths and you get both fluency and correctness. Fight their nature and you get neither.
What's the most confidently-wrong math answer an AI has ever given you? Mine once produced three flawless paragraphs of justification for a multiplication result that was simply, serenely incorrect. Share yours in the comments.
Top comments (2)
The “model orchestrates, the tool computes” framing is probably the most practical takeaway here.
I’ve found that the important distinction isn't really whether an LLM can get a calculation right, but whether the architecture gives it a reason to be trusted when exactness matters. Letting the model interpret the problem and delegate deterministic work to a calculator, code, or spreadsheet creates a much cleaner boundary.
The part about confident errors is especially important. A visibly wrong answer is easy to catch; a plausible number wrapped in a convincing explanation is much more dangerous.
I’m curious how you see this evolving as models get better at tool use — do you think the long-term solution is better internal reasoning, or simply better routing between models and deterministic tools?
You've put it better than my article did — "whether the architecture gives it a reason to be trusted when exactness matters" is exactly the right frame. The trust comes from the boundary, not from hoping the model gets lucky.
On where it's heading: my bet is firmly on better routing, not better internal arithmetic. Even if models improve their in-head math, you'd still be trusting a probabilistic process for something that has a deterministic right answer — and "usually correct" isn't good enough for money, dosages, or specs. A calculator is provably right; a model is plausibly right. Why give up a guarantee?
I think internal reasoning keeps improving, but its real job becomes knowing when to delegate — recognizing "this needs exact computation" and routing it out — rather than doing the computation itself. The frontier isn't a model that's a better calculator; it's a model that's better at knowing it shouldn't be the calculator.
And yes — the confident-plausible-wrong answer is the genuinely dangerous case. A boundary that separates "reasoning" from "computing" also gives you a natural place to verify, which the all-in-one-head approach never does.