How to Prompt AI for Maths (And When Not To)

TL;DR: AI does arithmetic unreliably by design, not because a particular model is having a bad day. Ask it to show its work, force a real code tool where the surface offers one, and verify anything consequential yourself. For high-stakes numbers with no easy way to double-check them, don't use a chat window as your calculator at all.

Why does AI get math wrong in the first place?

Because predicting the next likely token and running an exact calculation are two completely different jobs, and a plain chat model only does the first one. Unless a code tool is attached, every digit in its answer is a prediction, produced the same way it predicts the next word in a sentence, not the output of an arithmetic operation.

Two mechanisms make this worse specifically for numbers. A model's tokenizer chops long digit strings into arbitrary chunks rather than reading them as one value, and there is no calculator running underneath the text generation unless the product explicitly wires one in. We go deep on both of those, with the tokenizer's exact splitting behavior and worked date-arithmetic examples, in why AI gets dates and arithmetic wrong. This post assumes that mechanism and spends its time on the part that actually changes what you do next: when a prompt alone is enough, when you need to force a tool, and when you shouldn't be asking a chat window at all.

The part worth internalizing before anything else: a wrong number from a language model looks exactly like a right one. Nothing in the tone, formatting, or confidence of the answer tells you which you got.

When is it actually fine to just ask?

More often than the "AI can't do math" folk wisdom suggests, as long as the task and the stakes match what prediction is good at.

Asking is fine for:

• Order-of-magnitude estimates. "Roughly how much would a 15% raise on a $72K salary be?" doesn't need six decimal places, and a plausible-sounding round answer is genuinely useful here.
• Explaining a method, not executing it. "Walk me through how compound interest works" is a language task about a math concept, not a math task.
• Translating a word problem into a formula. Turning a messy paragraph into a clean equation is exactly the kind of pattern-matching a language model is built for. You still compute the final number separately.
• Low-stakes numbers you'll eyeball anyway. Splitting a lunch bill three ways is self-correcting: if the total looks off, you'll notice before anyone pays.

None of these require a code tool, a verification pass, or particular caution, because being wrong is cheap and obvious. The moment either of those stops being true, the next two sections apply.

How do you make it show its work instead of just an answer?

Ask for the steps as a deliverable, not as an afterthought. A bare final number gives you nothing to check; a visible chain of steps gives you something to read before you decide whether to trust the conclusion.

Do not give me a final number first. Instead, list every step of this
calculation on its own line, in the form:
  step description → operation → result
Only after every step is listed, write FINAL ANSWER: followed by the
result. If any input is ambiguous, name the ambiguity before you
compute anything.

Solve this twice, independently: once directly, and once by breaking
it into the smallest possible sub-steps you can check one at a time.
If the two approaches disagree, report the disagreement instead of
picking one.

This doesn't make the underlying prediction more accurate. What it does is convert "trust the number" into "read the working," which is a task you're actually equipped to do.

How do you get it to compute instead of predict?

Ask explicitly for a real calculation, and use the tool if the surface has one. This is the actual fix, not a better-worded prompt: a code interpreter runs real arithmetic in a real interpreter and returns what that interpreter produced, instead of a predicted digit sequence.

All three major vendors document this plainly, and each names roughly the same boundary: simple arithmetic gets answered directly, non-trivial math gets run as code. Anthropic's own tool documentation states it as a rule Claude follows automatically: "Claude runs code when the request benefits from computation or file handling", starting that list with "Non-trivial math (large numbers, many steps, precision-sensitive results)", while it "answers directly without running code" for "Simple arithmetic and well-known math facts" (Code execution tool, read September 2026). The same page adds the detail almost nobody acts on: "If you want Claude to run code for a borderline request, ask explicitly" (its own example is asking it to "run code to verify this").

OpenAI's Code Interpreter exists for the same reason: it "allows models to write and run Python code in a sandboxed environment to solve complex problems in domains like data analysis, coding, and math" (Code Interpreter, read September 2026). Google's Gemini API code execution tool works the same way and describes its own loop plainly: "The model can then learn iteratively from the code execution results until it arrives at a final output" (Code execution, read September 2026). Note Google's stated limit too: Gemini can write code in other languages on request, but "can't use the code execution tool to run it" outside Python.

Use your code execution tool to compute this. Print the code before
you print any result. Do not state a numeric answer that didn't come
from the tool's output.

Which kinds of math should you never hand to a chat window alone?

The ones where a wrong digit does real damage and you can't cheaply check it yourself. That's the actual test, not "is this hard math" or "is this a big number." A messy 40-line spreadsheet formula is hard and low-stakes if you'll review it before it matters; a single percentage in a contract clause is easy and high-stakes if nobody rechecks it before it's signed.

That bottom row covers more real situations than it sounds like: a loan or lease payoff figure feeding a legal notice, a medication dosage conversion, a payroll or tax calculation, a structural or electrical tolerance, an actuarial or compounding-interest number a client will act on. In every one of these, the honest move is to let AI help you build the calculation (the formula, the spreadsheet, the code) and to get the actual number from a tool built and audited for that exact job, or from the person whose training covers exactly this kind of error.

This isn't a claim that the model can't technically compute these correctly with the tool forced on. It's a recognition that "technically capable, unverified, high consequence" is a bad combination regardless of which technology is behind the number. The rule holds for a spreadsheet formula you didn't check either.

The test is worth applying explicitly rather than going on instinct, because instinct tends to key off how hard the math looks rather than what happens if it's wrong. A gnarly multi-variable optimization you'll review line by line before it ships is lower-risk than a single, simple-looking percentage that goes straight into an invoice nobody rereads. Ask yourself two questions before you hit send on a prompt with real consequences attached: what happens if this specific number is wrong, and how would I actually find out that it was? If the honest answer to the second question is "I wouldn't, until someone complained," that's the signal to route the number through a dedicated tool or a person instead of a chat window, no matter how confident the draft answer sounds.

How do you verify a number before you actually rely on it?

By a method that doesn't just reread the same answer and nod. Rereading a calculation checks whether it reads plausibly, not whether it's correct, and those are different things.

• Reverse it. Ask the model to work backward from its answer to the original inputs and confirm they reconcile. A one-way calculation that "checks out" going forward can still be wrong; a calculation that survives being run in both directions is stronger evidence.
• Recompute by a different method. If the first pass was a direct formula, ask for an estimate by rounding, or a different decomposition of the same problem, and see whether the two land close together.
• Run it in a fresh conversation. Open a new chat, paste the same inputs, and see if you get the same number. Two matching answers from independent runs is a better signal than one confident one, and it's a cheaper version of the same move as restarting a conversation that's gone off track: a clean context beats trying to argue a stuck one into agreeing with you. This is also the same instinct behind red-teaming your own prompt applied specifically to a number instead of a claim.
• Put the actual number through a real calculator or spreadsheet. For anything with real consequences, this step isn't optional. It's the whole point of the previous four.

None of this is exotic. It's the same discipline you'd apply to a junior colleague's spreadsheet: read the steps, ask for a second method, and check the number that's actually going to matter before it leaves your hands. And if the number you got back is simply wrong, the fix isn't to argue with the model in place; it's the same one covered in what to do when the first answer is bad — narrow what actually went wrong and ask again with that gap closed, rather than repeating the same prompt and hoping.

Worked example: fine to prompt directly

Scaling a recipe across a mix of metric and imperial units is a genuinely common, genuinely low-stakes math task, and a good demonstration of "show the work" earning its keep without needing a code tool at all.

Scale this recipe from 4 servings to 11 servings. Show each ingredient's
original amount, the scaling factor, and the new amount on its own
line. Keep the units as originally given (don't convert metric to
imperial or vice versa) unless a conversion is unavoidable, and flag
any ingredient where rounding to a sensible kitchen measure changes
the scaled amount meaningfully (for example, 2.75 eggs).

Original (4 servings):
- 220g flour
- 2 eggs
- 1.5 cups milk
- 3/4 tsp salt

If you'll be standing in a kitchen eyeballing the result anyway, a visibly wrong scaling factor is obvious the moment you read the line. That's exactly the profile where prompting directly, with the working shown, is the right amount of caution.

Worked example: when not to

A loan payoff figure is the opposite profile: the consequence of a wrong number is real (you send the wrong amount, or a lender disputes it), and independent verification isn't something you can eyeball the way you can a recipe.

I have a loan with these terms: principal $18,400, annual rate 6.25%,
24 monthly payments remaining, standard amortization. Write out the
amortization formula and, using your code execution tool, generate
the full payment schedule showing principal and interest per month
and the exact payoff balance after the 24th payment. Show the formula
and the code, not just the final number.

Even with the tool forced on and the formula shown, the honest last step is not to wire that number straight into a wire transfer or a legal notice. It's to run the same schedule through a dedicated amortization calculator or your lender's own statement and confirm the two agree, because a compounding calculation is exactly the kind of chain where one wrong intermediate step propagates invisibly through every payment after it. Ask AI to build the schedule. Get the number you actually act on from a tool built for that one job, or from your lender directly.

The honest summary is short. Prompting for math works when the mechanism producing a number is a real calculation, not a prediction, and when you have a cheap way to check the result if it's wrong. Show the working, force the tool, verify by a second method, and for anything where the stakes and the difficulty of checking both run high, treat the AI's number as a draft that a calculator, a spreadsheet, or a professional gets to confirm.