Why Does AI Get Dates and Arithmetic Wrong?

TL;DR: AI gets math wrong for three separate reasons: a tokenizer that chops numbers into chunks of at most three digits, no calculator inside the model unless you attach one, and no clock at all. Date arithmetic hits all three at once. Supplying today's date, forcing code execution, and decomposing the chain fixes most of it.

Why does AI get dates and arithmetic wrong?

Because none of the three things you assume are happening are actually happening. The model is not reading your number as a number, it is not running a calculation, and it does not know what day it is. Each of those is a separate, documented mechanism, and each has a different fix.

The failure is not that the model is careless. It is that a language model predicts the next token, and a plausible-looking digit is a perfectly good prediction. Wrong math and confident fabrication share that root cause, which is why they feel like the same problem. They are not, and we covered the fabrication half separately.

What does a number actually look like to a model?

Not like a number. It arrives pre-chopped into pieces, and the pieces do not respect place value.

OpenAI publishes its tokenizer as an open library, so this is checkable rather than theoretical. In o200k_base, the pattern that splits text before any merging happens contains one rule for digits, and cl100k_base carries the same rule:

\p{N}{1,3}

That is a hard cap. A run of digits can never become a single token longer than three digits, and the match is greedy from the left. That rule is in OpenAI’s own openai_public.py (read August 27, 2026). Running the library today, version 0.14.0, on o200k_base gives these splits:

Look at the last two rows. An ISO date, the format everyone reaches for to be unambiguous, splits the year across two tokens. A comma-separated number splits exactly on its thousands boundaries.

This is a studied effect, not a curiosity. Aaditya K. Singh and DJ Strouse examined it directly in Tokenization counts: the impact of tokenization on arithmetic in frontier LLMs, noting that "popular models like LLaMa and PaLM opting for single-digit tokenization while GPT-3.5 and GPT-4 have separate tokens for each 1-, 2-, and 3-digit numbers" (arXiv:2402.14903, read August 27, 2026).

Why does the tokenizer make arithmetic harder?

Because arithmetic runs right to left and the tokenizer runs left to right, so the digits that need to line up are not lined up.

When you add two numbers on paper you start at the ones column and carry leftwards. A model that receives 123 + 4 for one operand and 98 + 7 for another has no aligned columns to work with. It has to reconstruct place value from chunks that were cut at the wrong points.

The same paper found the fix and the evidence for it in one sentence: "right-to-left tokenization (enforced by comma separating numbers at inference time) leads to largely improved performance." Adding commas costs you nothing and moves every boundary onto a thousands group.

The more interesting finding is what the errors look like. The authors report that "model errors when using standard left-to-right tokenization follow stereotyped error patterns, suggesting that model computations are systematic rather than approximate." The model is not guessing randomly. It is doing something structured with badly cut inputs, which is exactly why the wrong answers look so reasonable.

Is there a calculator inside the model?

No. There is a calculator next to the model on some surfaces, and whether it is switched on changes the failure mode completely.

With no tool attached, the model produces digits the way it produces words: by prediction. With a code-execution tool attached, it writes Python, the Python actually runs, and the number comes back from an interpreter. All three major vendors ship this and describe it plainly.

• OpenAI's Code Interpreter lets models "write and run Python code in a sandboxed environment to solve complex problems in domains like data analysis, coding, and math" (Code Interpreter guide, read August 27, 2026).
• The Gemini API's code execution tool generates and runs Python, and "The model can then learn iteratively from the code execution results until it arrives at a final output." Google also notes the limit: "You can still ask Gemini to generate code in another language, but the model can't use the code execution tool to run it" (Code execution, read August 27, 2026).
• Anthropic's code execution tool documents when the model reaches for it. "Claude runs code when the request benefits from computation or file handling", and the first item on that list is "Non-trivial math (large numbers, many steps, precision-sensitive results)". The list of things it answers without running code starts with "Simple arithmetic and well-known math facts" (Code execution tool, read August 27, 2026).

That last pair is the practical detail almost nobody acts on. The model decides whether your sum is trivial. Anthropic's own advice for when it guesses wrong: "If you want Claude to run code for a borderline request, ask explicitly". So ask.

Why doesn't the model know what today's date is?

Because there is no clock in a language model. There is only whatever the surrounding product decided to tell it.

Anthropic publishes the system prompts its consumer apps use, which makes the mechanism visible. The overview page states that claude.ai and the mobile apps "use a system prompt to provide up-to-date information, such as the current date, to Claude at the start of every conversation", and adds the line that matters for anyone building on the API: "These system prompt updates do not apply to the Claude API" (System prompts, read August 27, 2026).

Read the published Claude Opus 5 system prompt and you can see the seam. One line begins "It answers the way a highly informed individual in May 2026 would if talking to someone from" and then stops, because what follows is not a date but a double-brace template token, {{currentDateTime}}, which the product fills in (Claude Opus 5 system prompt, read August 27, 2026). The same prompt states the model’s own limit plainly: "Claude's reliable knowledge cutoff, past which it can't answer reliably, is the end of May 2026."

xAI says the same thing about Grok in blunter terms: "Grok has no knowledge of current events or data beyond what was present in its training data", followed by the remedy, "To incorporate realtime data with your request, enable server-side search tools" (xAI models, read August 27, 2026).

So when a model tells you confidently that a deadline is 43 days away, ask yourself which date it counted from. Nothing in the answer will tell you.

What do vendors actually publish about knowledge cutoffs?

They publish them, they publish them in different units of precision, and at least one vendor publishes two different values for the same model.

Anthropic splits the concept in two, and defines the difference: the reliable knowledge cutoff is "The date through which the model’s knowledge is most extensive and reliable", while the training data cutoff is the broader range of data used (Models overview, read August 27, 2026). For Claude Haiku 4.5 those two dates are five months apart. A model can have seen data it cannot be relied on to recall.

xAI contradicts itself. docs.x.ai/developers/models gives February 1, 2026. The Grok 4.6 page's own at-a-glance table gives January 2026. Both were live on August 27, 2026, and neither page references the other. We are reporting both rather than picking one.

And Google's Gemini API models index carries no cutoff at all. Fetching ai.google.dev/gemini-api/docs/models on August 27, 2026 returns zero occurrences of the string "cutoff" anywhere in the page.

Why is date arithmetic the worst of both problems?

Because it stacks an invented starting point on top of unreliable counting.

A duration question is two operations. First, resolve what today is. Second, count days across month lengths and a leap-year rule. The first is guessed unless you supplied it. The second is arithmetic on numbers that arrived in three-digit chunks, in a string format that splits 2026 into 202 and 6.

There is a tell worth learning. 1461 is the number of days in a four-year span containing one leap day, and it tokenizes as 146 + 1. Any answer that leans on a round figure, four years as roughly 1,460 days, is a place where the model reached for a familiar quantity instead of counting. So is any answer that is exactly 365 times something.

Worked example: a real date calculation

A contract was signed on 14 November 2025 with an 18-month term. Today is 27 August 2026.

The prompt that invites a wrong answer:

We signed the contract 18 months ago. When does it renew, and how
long have I got to give 90 days notice?

Three things are undetermined: what 18 months ago is anchored to, what today is, and whether notice runs from the renewal date or the anniversary. The model will fill all three silently.

The rewrite:

Today is 2026-08-27. Treat that as authoritative and do not use any
other date.

Facts:
- Contract signed: 2025-11-14
- Term: 18 months from the signature date
- Notice required: 90 calendar days before the renewal date

Answer these four questions in order, one line each, showing the
count for each:
1. The renewal date.
2. Days elapsed from signature to today.
3. Days remaining from today to renewal.
4. The last calendar date on which notice can be served.

State the day of the week for lines 1 and 4. If any input is
ambiguous, stop and ask instead of assuming.

The verified answers, computed with a date library rather than by a model: renewal is Friday 14 May 2027; 286 days have elapsed since signature; 260 days remain; and the notice deadline is Saturday 13 February 2027, which is 170 days away. That last detail is the point of asking for the weekday. A deadline that lands on a Saturday is a deadline you need to serve on the Friday.

Why does one wrong step ruin a long calculation?

Because every later step treats the earlier one as fact. A single wrong intermediate is not an isolated error; it is a wrong input that the rest of the chain processes correctly.

This is also why writing the steps out helps. Jason Wei and colleagues established the effect: "prompting a 540B-parameter language model with just eight chain of thought exemplars achieves state of the art accuracy on the GSM8K benchmark of math word problems" (arXiv:2201.11903, read August 27, 2026). Intermediate steps are not decoration. They are the mechanism, and they double as an audit trail you can actually read. We go deeper on the technique in our chain-of-thought guide.

The follow-up result is the one worth stealing for daily use. Xuezhi Wang and colleagues proposed self-consistency, which "first samples a diverse set of reasoning paths instead of only taking the greedy one, and then selects the most consistent answer by marginalizing out the sampled reasoning paths", and reported a gain on GSM8K of "+17.9%" (arXiv:2203.11171, read August 27, 2026).

You cannot marginalise over sampled paths in a chat window. The manual version: run the same calculation in three fresh chats and see whether the answers agree. Two out of three matching is not proof. Three different answers is a definitive result, and it costs ninety seconds.

Which prompts actually fix this?

Six habits, seventeen blocks. Copy the ones that match how you work.

Give it today's date, every time

Today's date is {{DATE}}. Use it as the sole reference for anything
time-relative. Never infer the current date from your training data.
If a calculation needs a date I have not given you, ask for it.

Before answering, restate: (a) the date you are treating as today,
(b) every other date I supplied, in ISO format. If your assumed
today differs from mine, say so and stop.

Make the working the deliverable

Show every arithmetic step on its own line, in the form
  operand OPERATOR operand = result
No step may combine two operations. Put the final answer last,
prefixed with ANSWER:.

Answer in two parts. Part 1: the calculation, step by step, with
units on every line. Part 2: one sentence of interpretation. Do not
begin Part 2 until Part 1 is complete.

Force the tool

Use your code execution tool for every number in this answer. Do
not compute anything mentally. Print the code you ran and its raw
output before you interpret it.

You have no calculator available. Therefore: write a short Python
script that computes the answer, and stop. Do not state a numeric
result yourself. I will run the script.

Decompose the chain

Do not solve this yet. First, break it into the smallest ordered
list of single-operation steps, numbered, with the inputs each step
needs. Wait for my go-ahead before computing anything.

Compute step 1 only. Give me the number and the operation. Stop
there and wait. I will confirm before you continue.

Verify by a different method

You have produced a result. Now verify it by a method that does not
reuse your earlier working: reverse the calculation from the answer
back to the inputs, and state whether it reconciles. If it does not,
say WHICH step disagrees.

Give me an order-of-magnitude estimate first, using round numbers
and no more than two operations. Then compute exactly. Then state
whether the exact answer is consistent with the estimate.

Compute this three separate ways: (1) directly, (2) by a different
decomposition of the same problem, (3) as a sanity check using
approximation. Report all three. If they disagree, report the
disagreement rather than reconciling it.

Guard the inputs

Before computing, restate every input as a labelled line with its
unit and currency. Flag any figure I gave you that is ambiguous
about units, currency, tax treatment, or inclusive/exclusive dates.
Do not proceed until the list is unambiguous.

For every date range in this task, state explicitly whether the
endpoints are inclusive or exclusive, and count both ways if I have
not specified.

Rewrite every number over 999 in my input with thousands
separators, echo the rewritten list back to me, then compute using
that list.

Audit before you act

List every number in your answer in a table with three columns:
value, where it came from (my input / your calculation / your
memory), and the exact step that produced it. Mark anything from
memory with UNVERIFIED.

Which single step in your working, if wrong, would change the final
answer the most? Recompute that step alone, from the original
inputs, without looking at your earlier result.

The last one is not a prompt at all.

BEFORE THIS NUMBER LEAVES MY HANDS:
  [ ] I supplied today's date rather than letting it be assumed
  [ ] The working is visible and I read it, not skimmed it
  [ ] A tool computed it, or I recomputed one step myself
  [ ] The magnitude passes a five-second smell test
  [ ] Any number going into a contract, invoice, filing or
      forecast has been checked in a spreadsheet by me

Nothing above replaces that final line. If the number is consequential, check it yourself. That is not a failure of prompting; it is what prompting buys you time for.

Worked example: a multi-step arithmetic task

The prompt that goes wrong quietly:

We sold 1240 units at 37.50. Stripe takes 2.9% plus 30 cents a
transaction, cost of goods is 11.40 a unit, and fixed costs were
4725.60 last month. What was our margin?

Everything here is a trap. Margin is undefined. The percentage fee and the per-transaction fee are different operations on different bases. And every figure is written without separators, so 1240 arrives as 124 + 0 and 4725.60 as 472 + 5 + . + 60.

The rewrite:

Compute this with your code tool. Show the code and its output.

Inputs:
  units_sold            = 1,240
  price_per_unit        = 37.50 USD
  processing_pct        = 2.9% of gross revenue
  processing_fixed      = 0.30 USD per unit sold
  cogs_per_unit         = 11.40 USD
  fixed_costs_month     = 4,725.60 USD

Produce, each on its own line, rounded to 2 decimal places:
  1. gross_revenue
  2. processing_fee_pct_component
  3. processing_fee_fixed_component
  4. total_processing_fees
  5. total_cogs
  6. net_profit  (1 minus 4 minus 5 minus fixed_costs_month)
  7. net_margin_pct  (6 divided by 1, as a percentage)
  8. contribution_per_unit  ((1 minus 4 minus 5) divided by units)

Do not round intermediate values. If "margin" is ambiguous, compute
net margin as defined above and say so.

The verified answers, computed with exact decimal arithmetic: gross revenue 46,500.00; percentage fee 1,348.50; fixed fee component 372.00; total fees 1,720.50; total cost of goods 14,136.00; net profit 25,917.90; net margin 55.74%; contribution per unit 24.71.

Notice what the rewrite actually did. It did not ask the model to try harder. It removed every ambiguity, named every output, separated the thousands, and moved the arithmetic onto a tool. That is the whole method.

What none of this fixes

It does not make a model good at mental arithmetic, and no amount of prompt engineering will. If your surface has no code execution, you are still reading predicted digits, and the best you can do is make them auditable.

It also does nothing about the model losing track of a figure you gave it forty messages ago, which is a context problem with a different fix, or about an answer that stops mid-chain, which we covered in why answers get cut off. Working that looks beautiful can still be wrong at step three, the general case we treat in why your answers are bad.

The honest summary is short. Numbers reach the model in chunks that break place value, there is no calculator unless you attach one, and there is no clock unless the product supplies one. Supply the date. Demand the working. Force the tool. Split the chain. Verify by a second route. Then check anything consequential yourself, because none of those five steps is a guarantee and pretending otherwise is how a wrong figure ends up in an invoice.

Prompt Architects does not do your arithmetic. What it does is keep the date header, the tool-forcing block and the audit prompt one click away instead of something you were going to retype from memory at the exact moment the number mattered. Our prompt enhancer and saved library exist for precisely that kind of block.