EmiraHow it works
Most trackers show you a number and leave you to trust it. This page describes the actual path from your input to the entry in your day, including the parts where Emira looks something up, and the parts where it estimates.
Six stages. The interesting one is the fourth, where the system decides how hard to work before it answers.
Whatever you sent, whether a sentence, a recording, a photo, a barcode or a link, becomes the opening message of a conversation rather than a form submission. That matters later: corrections are follow-up messages, not a re-entry.
Text · Voice · Photo · Barcode · Recipe link
Your goals, the nutrients you track, foods you have marked as ones you eat often, and any recipe you referenced are added to the request. This is what stops 'yoghurt' from resolving to a random yoghurt when you have eaten the same one for a month, and it is explained in full below.
Profile · Goals · Food preferences · Recipes
Instead of answering immediately, the model first decides what it does not know and what would settle it: which products to search for, whether a nutrition table is needed, whether the amount is already stated. It produces a plan, not an answer.
Planned lookups, not a guess
A barcode goes straight to the product catalogue. A named product goes through semantic search over the catalogue, and only falls through to a web lookup when the match is not confident enough. A recipe link is fetched and read. Results are cached, so the second time is free.
Catalogue · Semantic search · Web lookup · Recipe extraction
Everything gathered is laid out together and a final pass decides the actual ingredient list: what the food was, how much of it, which source each number came from, and how confident that is. Product references and nutrition tables outrank a generic web page.
Amount · Nutrition basis · Source · Confidence
The meal enters your day with plausible amounts rather than stopping to interrogate you. Where an uncertainty would actually change the total, Emira offers one optional refinement. Structured edits apply directly; anything you type goes back through the model as an explicit change.
Logged first, refined only where it matters
These are measured medians from our own benchmark runs, not targets. Each one names the run it came from.
Median over 100 German-language product queries against a 10,004-row catalogue; the 95th percentile is 0.29 ms. This is the step behind a barcode scan, which is why scanning feels instant.
benchmark/LOCAL_CATALOG_RETRIEVAL_BENCHMARK.md · measured 2026-07-12
Median model latency across 19 real meal photos with an accompanying sentence. The slowest case took 3.37 s. A second, cheaper model was roughly 2.6x slower at 3.06 s median.
benchmark/vision_comparison/results/2026-07-31 · measured 2026-07-31
Median across 8 nutrition pages, from 0.73 s to 6.04 s. This is the step that runs when you paste a recipe link and the page has to be read before anything can be logged.
benchmark/out/web_nutrition_extractor_benchmark.json · measured 2026-07-31
Stage two, in detail
Everyone eats the same twenty or so things most weeks. Those are exactly the items a tracker gets wrong most often, because a common name covers an enormous range: “yoghurt” runs from roughly 45 to 130 kcal per 100 g depending on which tub you buy.
A food preference is a product you have marked as one you eat often. It is stored as a stable product identity, not as a name, which means it points at a specific record with specific nutrition values rather than at a word.
Before any analysis begins, your preferences are handed to the model as context. When you then write “yoghurt with granola”, the ambiguous half of that sentence resolves to the tub in your fridge instead of a population average. No scanning, no picking from a list, no correcting the same entry every morning.
Two details matter. A preference influences which product is chosen; it never overrides an amount you stated. And it stays a suggestion: if you scan something else, the scan wins, because a barcode is the stronger source of truth.
An earlier version answered directly from the model and looked up less. It was faster and noticeably worse, and not because it failed to find foods: but because it was confident about amounts it had no way of knowing. Across benchmark runs, portion and serving errors dominated; retrieval errors were the smaller problem.
So the design moved the other way: plan first, look up what can be looked up, and keep the origin of every number attached to it. That costs about a second, and it is the difference between a total you can correct and a total you can only accept.
If you want the practical version of this, meaning which way of logging to use for which meal, that is on the ways to log a meal page. If you want to know how well it does, the accuracy page is the honest account, including what is not measured yet.