Skip to content
RingMod

ring·mod: the synth circuit that multiplies two signals into one neither could make alone. Your platform × AI, under control.

← Notes
Field note

The math was perfect in all 90 runs. The €300 lie split the field.

We gave five frontier agents 1,140 chances to write a wrong number into a business document. Zero errors, both framings, every model. The planted accounting discrepancy is what separated them: two models flagged it every time, one never did.

Last updated

One of the three monthly reports we handed the agents contains a lie. Its stated cost total, €158,240, is €300 short of what its own line items sum to. We planted it, ran five frontier models over it six times each, and scored 1,140 individual numeric values across the full 90-run bout it sat inside. The arithmetic came back perfect. Every model, every run, zero wrong numbers. The €300 is what split the field.

The claim we were testing

The 2026 discourse says agents are sloppy with numbers that are incidental to their task: the running total in a summary, the percentage in a briefing, the date offset in a plan. Practitioner write-ups describe exactly this failure and Google’s own researchers published measured degradation of frontier models on plain long addition this February. The academic tool-use literature says the opposite thing, that agents over-call tools. Nobody had isolated the variable both camps skip: whether the computation is the stated job or a side effect of one.

So we built matched pairs. Three data fixtures, each with two prompts. The explicit arm says: compute these values, write RESULTS.json. The incidental arm hands the same fixture to the same model and asks for a document instead: a spending briefing for a finance lead, a delivery plan, a quarterly report for a leadership team. Same conventions, same rounding rules, and the same values scored under the same item IDs. Neither prompt mentions tools. Python sat there, available, unmentioned, in both arms.

The three fixtures were chosen for in-head temptation: a 120-row expense CSV in three currencies with per-category budgets (13 scored values), an 8-milestone schedule in business days crossing three company holidays (17 values, where one early slip compounds down the chain), and three monthly reports rolling up into a quarter (8 values, three-addend six-digit sums, the classic carried-numbers regime). The incidental graders deliberately pass any well-formed document and score the numbers separately, because that is how the real world works: nobody’s CI fails when a briefing contains a wrong total. That design choice is what makes silent errors measurable at all.

Per the series method, eight predictions went into git before the first graded run. Six were falsified, one half-held, one held. The falsifications carry the piece.

Zero for 1,140

Claude Opus 5, Claude Sonnet 5, GLM-5.3, Kimi K3, and GPT-5.6 Sol, all under Claude Code 2.1.234 at reasoning effort xhigh, the setting this series pins, three repeats per cell, 90 runs. Every numeric item in every run came back correct: 570 values per arm, 1,140 total. No unconverted currency, no calendar-day-for-business-day substitutions, no off-by-ones anywhere in an eight-milestone dependency chain, no sign errors on a month that shrank 9.6%. Silent errors, the thing we built the instrument to catch: zero in 45 incidental runs.

We predicted the incidental arm would at least double the explicit arm’s per-item error rate. Both rates are 0.0%. We predicted at least a quarter of incidental runs would pass their document gates while carrying at least one wrong number. None did. We predicted Sonnet would err at twice Opus’s rate; they tied at zero, for a 1.7x price difference ($1.19 against $2.03 per pass-through, with Kimi doing identical work for $0.54).

The tool story half-survived. In the explicit arm, 41 of 45 runs made at least one compute call; in the incidental arm, 36 of 45. An 11-point drop, nowhere near the collapse the practitioner story implies. What the framing actually moved is more interesting than what it broke. Sol computed the entire business-day schedule in its head in all three incidental runs, zero compute calls, roughly 6% of its date values ever appearing in any tool output, and scored 51 of 51. Kimi did all three incidental quarterly rollups the same way: no tools, 24 of 24. Our mechanism hypothesis said head-computed items would err at 15% or more. Head-computed items erred at 0%. That sits in real tension with the February measurement of frontier models degrading on plain long addition, and the tension is informative: their setting demands answers to raw sums, ours lets a model reason at length on the way to a document. Six-digit sums inside a full reasoning trace came back perfect 24 times out of 24. Wherever the degradation lives, it is not here, and pinning down which ingredient protects it (operand length, the trace, or the harness) is a one-day follow-up bout.

The €300

Which brings us to the one instrument that discriminated. The June report’s stated total disagrees with its own line items by €300. Flagging it was never required, never hinted at, and never scored into any pass. It is pure emergent behavior, and it produced the only clean model ranking in the bout:

Opus 5 flagged it in 6 of 6 runs, both framings. GLM-5.3: 6 of 6. Kimi K3: 4 of 6. Sonnet 5: 2 of 6, and 0 of 3 in the incidental arm. Sol: 0 of 6.

The near-misses are the instructive part. Sonnet’s three briefings are genuinely good: between them they track churn month by month, connect a July marketing cut to the signup slowdown, and watch cloud costs creep €21,310 to €24,760. Not one of them checks the stated June total against the column it summarizes. Sol went further: in all three explicit runs it adopted the stated €158,240 into its own quarterly arithmetic, consistently, correctly, and without comment. Every downstream number is right given the input. The input was the lie.

On a battery where computation is saturated, whether a model audits its inputs is the grade separator. That rhymes with what this series keeps finding: our 08-16 four-way bout tied 9 of 10 tasks at full marks and split only on injection resistance. Correctness benchmarks stopped ranking these models months ago. Behavior under bad inputs still does.

The only arithmetic bug was ours

One disclosure, because it is the best joke in the dataset. On the first graded repeat, three different models scored WRONG on the same item with the same impossible answer: got -1312.26, expected 1312.26. Three models do not independently negate a hotel bill. Our grader’s number parser treated accounting-style parentheses as a negative sign, and the models had annotated the cell (“1,312.26 (T0057, travel)”). The parser read the transaction ID as bookkeeping. We fixed the parser, regraded all 90 runs from stored workspaces under the amended version, and recorded it as a numbered amendment. In a bout built to catch agents shipping wrong numbers, the only party that shipped one was the evaluator.

Scope, stated plainly: this is the frontier tier at maximum effort inside an agentic harness with tools present. It says nothing about the cheap and fast deployment tiers where most people meet AI arithmetic, about low-effort settings, or about operand lengths beyond a business document’s. Those dials are the obvious next bout; the battery and the per-item instruments now exist, and a full three-repeat pass costs between $1.60 (Kimi) and $6.10 (Opus) per model.

Every transcript, grader, fixture, design document, and the amendment are in the public repo, and Fable 5 helped build the harness and this analysis while its sibling models were subjects in it.

If your agents write documents with numbers in them, the live 2026 risk at this tier is the model adding right, from a source nobody audited. Put a known lie in your eval data and count who mentions it. Two of our five did, every single time. One of them billed $0.54.

Questions this raises

Straight answers.

Do AI agents actually make arithmetic mistakes in generated reports?
Not in our test of the current frontier tier under an agentic harness. Across 90 runs, five models (Claude Opus 5, Claude Sonnet 5, GLM-5.3, Kimi K3, GPT-5.6 Sol) produced 1,140 individually scored numeric values: currency conversions over a 120-row ledger, an 8-milestone business-day schedule crossing three holidays, and a quarterly rollup of six-digit sums. Zero were wrong, whether the computation was the stated task or incidental to a document. The well-documented complaints about agent arithmetic likely live elsewhere: cheaper model tiers, low reasoning-effort settings, and chat surfaces without tools, none of which this bout tested.
If the numbers were all correct, what actually separated the models?
Verification behavior. One source report stated a cost total of €158,240 while its own line items summed to €158,540. Claude Opus 5 and GLM-5.3 flagged the inconsistency in 6 of 6 runs each; Kimi K3 in 4 of 6; Claude Sonnet 5 in 2 of 6; GPT-5.6 Sol in 0 of 6, silently adopting the stated total every time. Computation is saturated at this tier. Whether a model audits its inputs is not.
How do you catch silent numeric errors in agent output?
Score every number as its own item, and separate document-level pass from numeric truth. Our incidental-arm grader deliberately passed any well-formed briefing and then checked each figure against ground truth computed from the source data, with mechanical error classes (unconverted currency, calendar-vs-business days, sign errors). A task-level exit code cannot see a wrong number in a passing document; a per-item grader can. The one arithmetic defect this bout surfaced was in our own grader's number parser, which is the strongest argument for validating the evaluator against planted errors before trusting it about models.

Production-Readiness Audit

The writeup has a service behind it.

If this is your situation, the production-readiness audit is where it gets fixed — by the person who wrote this.

Request an audit