Why photo calorie counting runs 40 percent low, and the chip fix

Before building Kaloro I read the one-star reviews of photo calorie apps. The most frequent complaint was the same everywhere: "It counted low." Not a competitor's mistake, a physics one.

What the model cannot see

It sees the food on the plate. Three things it does not see: the oil that went into the pan, the butter or olive oil added at the end, the real diameter of the plate. In home cooking those three are 20 to 50 percent of the meal. A photo of menemen shows two eggs; it does not show the butter. The model says 200, reality is 390.

A better model does not fix this, because the information is not in the photo. Train a model to "assume average oil" and you are wrong on average.

The fix: make the assumption visible

Kaloro writes what it assumed on every result: "1 plate, about 400 g, normal oil." Below it, two chips:

• Cooking: light, normal, generous oil
• Portion: small, normal, large

The number updates as you tap. This turns an accuracy problem into an interface problem: the model guesses the average, the user pulls it to reality in two taps. An estimate whose assumptions are visible can be fixed; a bare number can only be wrong.

How we measured

An accuracy gate: 15 to 20 real meal photos with known recipes and a reference table. A localised system prompt for Turkish food made a 19-point difference; mercimek stopped being "red lentil soup". The code has an f_scan_fix counter: does the user actually use the chips? If not, it is a story we tell, not a product.

Where it sits in the app

The model call goes through a Cloudflare Worker to Gemini; the photo is discarded in the same request and never written anywhere. That also reduced the privacy policy to a paragraph. Guardrails are in the code too: 1,200/1,500 kcal floors, a 0.75 kg per week ceiling, no goal weight under a healthy BMI.

Lesson: in an AI product, "a better model" is rarely the answer. Making it easy for the user to tell the model what it cannot know is.