ChatGPT multiplies two five-digit numbers and misses by 913,200

The wrong answer that passes for a right one

Someone asked ChatGPT to multiply 57,897 by 12,832. It answered 742,021,104. The true product is 742,934,304.¹

The answer has nine digits, the right count. It opens with the right three, 742 million. It is off by 913,200, which sounds like a lot until you set it against three-quarters of a billion: the miss is about 0.12%. Nothing marked it as suspect. A part of a program that had actually multiplied would either get the answer or fail in some obvious way, not land a tidy figure a hair off the truth.

The reason is that no part of the model multiplied anything. A language model predicts text: given the characters so far, it produces the next piece, then the next. It has no separate unit that does arithmetic. It generated those nine digits the way it generates words, by extending a pattern. When a small sum is common enough to sit all over the training data, that pattern reproduces the exact answer. When the problem is a rare product this size, the model still produces something the right shape, and shape is all it has to go on. On zero-shot multi-digit multiplication, off-the-shelf GPT-4 solves the problem by matching against arithmetic it has seen rather than running the procedure, which is why the output looks like an answer without being one.²

Predicting text explains how a wrong answer can look so right. It does not yet explain why the wrongness tracks size so cleanly, small sums right and large ones lost. For that, watch what the accuracy does as the numbers grow.

Common sums come out right, rare ones fall apart

Measured across problem sizes, the fall-off is steep. GPT-4, answering without help, is right most of the time on three-digit multiplication and essentially never right by five digits.

The team that measured this reads the curve the same way: a transformer reduces a multi-step task to matching against fragments of computation it saw in training, instead of executing the full procedure.² A three-digit product has enough near-neighbors in the training data that the match often lands. A five-digit product almost never does, which is why the example above, a five-digit case, sits in that bottom row.³ To see why the match gets harder rather than more precise as the numbers grow, back up to what the model is handed when it reads 57,897. It is not five digits.

The number never arrives as digits

Before the model sees anything, a tokenizer cuts the text into tokens, the units the model actually reads. For numbers, OpenAI's current tokenizers cap a numeric token at three digits. The splitting rule is written into the source as \p{N}{1,3}, and it is the same in cl100k_base, used by GPT-3.5 and GPT-4, and in o200k_base, used by GPT-4o.⁴ So a long number is broken into runs of up to three digits, and the breaks fall wherever the rule puts them, not on the ones, tens, and hundreds a person lines up to multiply. The cut is not even stable between neighbors: 380 is a single token, while 381 comes through as two, 38 and 1.¹ A controlled study confirms the scheme: GPT-3.5 and GPT-4 assign separate tokens to one-, two-, and three-digit numbers.⁵

This is a different failure from the one in letter-counting. There, the trouble is that the characters are hidden inside a token the model cannot see into. Here the tokens are made of digits, in plain view, but their boundaries land in the wrong places, so the positional structure a multiplication depends on is scrambled before the first partial product is ever formed.

Chunked digits are a fact about OpenAI-style tokenizers, not every model. LLaMa and PaLM tokenize numbers one digit at a time, so their numbers arrive with place value intact.⁵ Those models still miss large multiplications, but for the reason in the next step, not this one. Even a model handed one clean digit per token would fail, because there is nowhere for the carrying to happen.

Nowhere to keep the carry

The model writes its answer left to right, and it computes each token in a single forward pass with no place to set down a partial result. Multiplying by hand means building a stack of partial products and a running carry, held on paper as you go. The raw model has no paper. A reverse-engineering of why a normally trained transformer fails at multiplication found the cause. The model settles into a solution that lacks the long-range dependencies the task needs. It never caches and retrieves the pairwise partial products, so the carry has nowhere to live.⁶

The fix is external, and it takes one of two forms. The first is to let the model write the intermediate steps into its own output, a scratchpad it then reads back. A model that keeps its steps this way climbs from under 1% on four-digit multiplication to essentially 100%.⁷⁸ That is the whole subject of thinking out loud. The second is to hand the sum to a calculator: a model can be trained to call an external tool and fold the returned number back into its text,⁹ which is what tool use covers. Even a smaller change helps at the margin. Rewriting a number with commas so the model reads it right to left already improves GPT-3.5 and GPT-4.⁵

This is where modern products get large arithmetic right. A reasoning model spends a long built-in chain of steps; a chat product routes the sum to a code interpreter. Both wrap an external fix around the same next-token core, and neither adds an arithmetic unit. The December 2025 report that measured the jump from under 1% to full accuracy was careful to claim no more than that: purpose-built training closed the gap in one controlled setting, with no suggestion that reasoning models had solved multiplication on their own.⁷ The failure at issue is the raw model with all of that turned off. That the accuracy comes back the moment the steps are written down tells us the missing thing is working memory, not any knowledge of how to multiply. Which leaves the question the fixes route around: when the raw model does land a sum, what is it doing?

The sums it gets right are the least understood

Two things about that are established. There is no exact digit-by-digit carrying circuit inside these models, and accuracy falls as the numbers grow.²⁶ What is genuinely unresolved is how a model represents and combines numbers when it succeeds, and two careful studies of the same territory describe it differently. One finds a bag of heuristics: sparse sets of neurons that each fire for a specific pattern, such as an operand falling in a certain range, whose unordered combination accounts for most of the model's arithmetic, with no general algorithm underneath.¹⁰ The other finds more structure: numbers laid out along a helix, added by a rotation that turns one operand's helix onto the sum's.¹¹ They agree it is nothing like the human carrying method, and they disagree on what it is instead.

Both also study a narrow slice: two-digit operands, 0 through 99, on mid-size open models like GPT-J and Llama-3.1-8B,¹¹ nowhere near a frontier model working a five-digit product. The one case that has been mapped in full is a toy. A small transformer trained on nothing but modular addition has been reverse-engineered down to its circuit, which converts addition into rotation on a circle using Fourier components.¹² That cleanliness comes from the toy's single task. It is not a chatbot multiplying, and this is exactly where an explanation can overreach: anyone who offers that circuit as how ChatGPT multiplies has stepped from what is known onto what is merely hoped. Below this point, the people who build these models cannot yet draw the answer.