Close Enough: The Calorie Log I'll Actually Keep

I’ve written before about the health data warehouse I built and the Attia coaching framework I layered on top of it. Sleep, HRV, resting heart rate, APAP therapy data, workouts, weight, blood pressure. Nearly two years of it, landing in SQLite every night, deduplicated and corrected.

There was one input the system could never reach on its own: what I actually ate.

That’s not a small gap. If you’ve read the Attia post, you know protein is one of my levers: I’m aiming for roughly a gram per pound of goal bodyweight while I work my weight down toward 165. You cannot manage that with a feeling. You manage it with a number. And the number for food only exists if I log the food.

So nutrition was the weak link. Not because the data was hard to get. Because it was the one thing I had to enter by hand, every day, which meant it was the one thing I kept quietly abandoning.

The problem isn’t the data. It’s the friction.

I use Lose It to track food. It’s a good app. But like most nutrition apps, it doesn’t hand you a clean API to your own data. It’ll sync calories to Apple Health and nothing else: no protein, no carbs, no per-item detail. So the exact numbers I most need for the Attia framework were trapped in an app that would only whisper “calories” to the rest of my system.

The deeper problem is the same one that kills every food log eventually: the tax. Open the app, search the food, pick the closest match, set the serving, repeat for every component of the meal. Thirty seconds of fiddling per item. Do that three times a day and the friction wins. It always wins.

I didn’t want a better app. I wanted to remove the tax.

What I started with

I didn’t build the hard part. Someone already had.

There’s a small open-source project, loseit-cli (MIT licensed), that reverse-engineers Lose It’s private web API: the GWT-RPC calls its own website makes. That’s the genuinely difficult, tedious work: figuring out the wire format, the byte-array quirks, how a food search and a diary write are actually encoded. I stood on that.

What I wanted was different in shape: not a command-line tool, but an MCP server, a bridge that lets a Claude session talk to Lose It in plain language and then feed the results into my health database. So I took their client as the engine and built the car around it.

What I tweaked

A few things mattered enough to call out.

I pointed it at my account. The reverse-engineered pieces are pinned to whatever version of Lose It’s website was live when they were captured, and to whoever captured them. First run, it politely tried to log food as a stranger named Rich. I re-captured the current values from my own session and wired those in. (This is also the part that will break someday when Lose It ships a new website. I documented the two-minute fix so future-me isn’t confused.)

I stopped trusting the search order. Lose It personalizes food-search results by what you’ve eaten recently, so the same query returns a different order every time you ask. My first automated dinner cheerfully logged an avocado as a turkey BLT sandwich because it picked “result #3” twice and got two different foods. Now it selects by name, and refuses to log at all if it can’t find the food it was told to. A wrong entry is worse than no entry.

I split reads from writes. Writing food uses that fragile private API. But reading my diary and syncing to the database uses Lose It’s data-export endpoint instead: a stable, boring ZIP of CSVs. The stuff my health tracking actually depends on doesn’t break when Lose It redecorates.

I caught Lose It lying about my protein. When I wired the daily totals into my database, the numbers looked wrong. Lose It’s own daily protein rollup reported about 30 grams on a day I’d eaten closer to 130. Its per-item data was right; its daily summary was broken. So the sync sums the actual items rather than trusting the headline number. Trust, but verify. Even the source.

I added a way to log a meal that isn’t in the database. More on that in a second, because it’s the whole point.

Logging dinner by describing it

Here’s the workflow I was actually after. Last week I had dinner at a place called Red Mesa. I ordered the Mayan Salad (butter lettuce, quinoa, a green chile vinaigrette, avocado, Cotija, toasted pepitas) and added shrimp.

That dish is not in any database. In the old world, logging it meant searching six ingredients, guessing six portions, and giving up somewhere around the vinaigrette.

In the new world, I describe it. I can type out the menu description, or just share a photo of the plate, and work it out in conversation: butter lettuce, quinoa, half an avocado, a sprinkle of Cotija, a handful of pepitas, a couple tablespoons of vinaigrette, six or seven shrimp. We land on an estimate, call it 600 calories and 34 grams of protein, and it goes into my diary as one entry, macros and all, then flows into my database with everything else.

No app. No six searches. A sentence and a photo.

Close enough is the entire point

Here’s the thing I have to keep reminding myself, and the thing I most want to say to anyone who tries this:

Logging something close is more important than logging something exact.

That salad estimate is not precise. The restaurant used more oil than I think. The avocado was bigger or smaller than “half.” The shrimp were six or they were eight. If I demand precision, I will weigh my food or I will quit, and I know which one I actually do.

But precision was never the job. The job is a decision I can trust: did I hit my protein, roughly? Am I over my calories, roughly? A meal logged approximately, every single day, tells me that. A meal logged to the gram, twice, before I abandon the whole thing, tells me nothing.

Adherence is the lever, not accuracy. The best tracker is the one you keep using. Everything I built here is in service of that one idea: take the friction out so the log survives contact with a normal, busy day. If “close” is what it takes to keep logging, then close is not a compromise. Close is the strategy.

What this unlocked

The moment nutrition started flowing in automatically, my weekly review stopped guessing. Protein trend, calories against budget, the same before/after analysis I run on sleep and HRV, now with food in the picture. The last major input to my health is finally in the warehouse with everything else, and I get it there by describing my dinner instead of dreading a form.

I’ll be honest about the caveats, because I always am: this leans on an unofficial, undocumented API. It’s against Lose It’s terms of service, it’s for my own account and my own data only, and it will break the day they change their site. That’s a real cost. For me it’s worth it, because the alternative isn’t a cleaner integration. The alternative is not tracking at all.

And not tracking is the one thing my health goals can’t afford.