Blog

Burnin assumes the food AI is wrong

4 min read

Photo calorie estimates are unreliable in every app, ours included. Burnin takes calories from a food database and measures your target from the scale.

Point any calorie app at a plate of food and it gives you a number. Ours is wrong by 79% on average, measured against 24 dishes weighed on a scale.

Most apps present that number as a fact: one figure, logged, with nothing to say how much of it was read and how much was invented. Burnin is built on the assumption that the model is wrong. Four decisions follow.

The model reads the photo. It does not do the arithmetic.

When an item’s name matches a food database entry well enough, the calories come from that entry, scaled by the portion. The model’s own calorie estimate is the fallback for a weak match or a miss.

One output, four fields {"items":[{"name":"chicken","quantity":1,"gramsEach":200, "estimate":{"calories":3 Chicken Breast, Protein: 52g, … name quantity gramsEach estimate "chicken" 1 200 3 Chicken Breast, Protein: 52g, … recovered, and logged replaced from the local food table
One output seen on 2026-09-21, from "i had 200 grams of chicken". The name, the count and the weight all came through. The only unusable field was the calorie estimate, which grounding replaces from the local food table anyway.

The model is good at reading a plate and naming what is on it. It is unreliable at arithmetic it was never the right tool for. So a Burnin entry grounded from the database runs the same calorie and macro maths as the manual food search, and an AI log and a hand-typed log of the same food come out numerically identical.

What grounding cannot fix is the portion. Ask the model for grams and it returns roughly 150 per item whatever the dish, so a light plate comes out nearly twice its real weight, and no database row can tell you how much was on yours.

Every entry says how much of it is a guess

A logged entry is the product of two independent guesses: whether the calories came from a database row or from the model, and whether the portion was stated or fell back to a stand-in weight.

Those are scored separately, and the lower one is what the entry shows. A verified database food at a made-up portion is not a confident entry, and neither is a precisely weighed food whose calories were invented. Showing the better of the two would be flattering and wrong.

Nothing is logged until you confirm it

Everything the model reads lands on an editable card. You change what is wrong and then you log it, or you dismiss it.

This one costs us: a one-tap “just log it” flow would feel faster, and in a demo it looks better. It also quietly writes a guess into your history and then reports that history back to you as fact.

Your target comes from the scale, not from a formula

The last one does the most work. Burnin derives your energy expenditure from what you logged against what your weight actually did, rather than from a formula applied to your height and age.

If you consistently under-log by fifteen percent, the measured expenditure comes out fifteen percent low with it, and the deficit it recommends stays right for you. A formula-based target compounds that error. A measured one cancels most of it.

So a bad photo number here is a product problem rather than a correctness emergency. What the loop cannot absorb is an inconsistent one: a single bad entry still moves the average, which is why it is worth fixing properly rather than papering over.

What we are not claiming

We are not claiming the number is good, and we are not claiming it transfers. It comes from 24 overhead photographs of small cafeteria plates. The one clinical comparison available has the commercial apps erring the other way, under-counting by 250 to 345 kcal, so some of our figure is an artefact of what was on those plates.

An app that shows you one confident calorie number from a photograph is making a claim nobody in this field can support, ours included.

Those four decisions are what we built once we accepted it.