Numbers you can trust, and the receipts to prove it.
Every macro traces to a named USDA food you can check yourself. We test each recipe four different ways before you see it, and when an ingredient cannot be verified, we tell you instead of guessing.
Here is a real recipe run through the demo, exactly as it appears there: a per-serving panel, and every ingredient matched to a named USDA food with its own grams and calories.
| Ingredient | Matched USDA food | Grams | Calories |
|---|---|---|---|
| 1 lb elbow macaroni | Macaroni, dry (USDA pasta, enriched) | 454 | 1683 |
| 3 cups shredded sharp cheddar | Cheese, cheddar | 315 | 1285 |
| 1 cup whole milk | Milk, whole, 3.25% milkfat | 244 | 149 |
| 1 cup heavy cream | Cream, heavy | 237 | 812 |
| 4 tbsp butter | Butter, salted | 57 | 407 |
| 1/4 cup all-purpose flour | Flour, wheat, all-purpose, enriched | 31 | 115 |
| 1/2 cup grated parmesan | Cheese, parmesan, grated | 50 | 209 |
| 1 tsp mustard powder | Spices, mustard seed, ground | 2 | 10 |
| 1/2 tsp paprika | Spices, paprika | 1 | 3 |
67 g total carbs − 2.5 g fiber = about 64 g net carbs per serving
Where our numbers come from
Most macro tools ask a model to guess a recipe’s totals. We do the opposite. We use language models only to read your recipe into ingredients and amounts. The actual numbers come from code that looks up each ingredient in the USDA food database and does the math. That is a deliberate line: the model handles words, the code handles anything that has to be correct.
The payoff is that every number is traceable. Paste a recipe and you see each ingredient matched to a specific USDA food, with its own calories, protein, carbs, and fat, just like the table above. Nothing is a black box. If you want to check a line, you can.
When we are not sure, we say so
Sometimes an ingredient has no good match, or a unit cannot be converted safely. When that happens we do not paper over it with a plausible-looking number. We flag the line and leave it out of the total, and you see that it was left out. A quiet wrong number is worse than an honest gap, because you cannot catch what you cannot see.
How we test our own numbers
Grounding in real data is the start, not the finish. Before a recipe’s numbers reach you, they go through several independent checks, each designed to catch a different kind of mistake.
A second opinion
We ask a general model for its own quick estimate of the same recipe and compare. It is not precise, but a large gap is a smoke alarm that tells us to go look. This exact check caught two real errors in our own numbers before launch.
Rules that must always hold
Some things are true no matter how a recipe is written. A pound is sixteen ounces, so both must give the same answer. Double an ingredient and its numbers double. Dry pasta has more carbs per gram than cooked pasta, never the reverse. We test all of these automatically on every build.
A silent-mistake detector
A separate check scans for the sneaky failures: a main carb source quietly dropped to zero, or a pantry item matched to some unrelated packaged food. These are the errors that pass every ordinary test, so we hunt them on purpose.
We manufacture the hard cases
We do not wait for a tricky recipe to trip us in the wild. We generate difficult ones on purpose, brand-name products, unusual units, count-measured items, and run them through the same engine to find the next gap before you do.
What we found doing this
This is not theory. These checks caught a recipe where a pound of dry pasta was being read as cooked pasta, which roughly halved its carbs, and later a case where grated parmesan matched a fat-free topping instead of real parmesan. The honest figure for that baked mac and cheese is about 64 g of net carbs per serving. We fixed the matches, re-checked them, and re-engineered the dish down to single-digit net carbs, every number still grounded. That is the whole point of testing your own work: you find your mistakes before your customers do.
Macros are estimates for general information only, not medical or dietary advice.