Levelsio builds Caltrack with Claude Code on a VPS and Grok vision

• Caltrack started as a chat memory failure, then became a VPS app with CSV import, a Telegram bot, Termius SSH logging, and daily dashboards in levelsio's build note.
• The logging loop uses photos too: levelsio said food scans run through xAI Grok vision in his Grok note, then clarified the connected API as Grok 4.2 vision in his API reply.
• The killer feature is database memory: the coding agent can query the SQLite food log when levelsio asks what to eat next, as his memory reply put it.
• The same VPS workflow also powered a native iOS side quest, with Claude Code building through a headless Mac Mini and streaming an iOS simulator back over SSH in levelsio's serve-sim clip.

According to Anthropic's Claude Code overview, Claude Code is an agentic coding tool that runs in the terminal. levelsio used that shape for something more interesting than a demo: a personal database app born from a diet log that chat could no longer keep straight. The odd pieces are the useful ones, Grok vision for food photos, SQLite as memory, and a VPS-to-Mac-Mini build path for native iOS work.

After Claude chat started losing track after about a week, levelsio exported the diet data as CSV, pasted it into Claude Code on a VPS, and asked it to build Caltrack.

The product spec inside levelsio's post was tight:

• Goal: about a 500 calorie daily deficit.
• Protein target: about 150g, roughly 2g per kg of bodyweight.
• Inputs: Telegram bot for casual logging, Termius SSH for granular logging.
• Dashboard: daily calories, protein, maintenance calories, targets, deficits, and food entries.
• Conversation layer: questions like "how am I doing" and "what to improve" against the server-side data.

The Telegram part maps to the standard Telegram Bot API: messages go in, the app writes structured food data, and the dashboard stays current.

The app requirements came from small nutrition arguments, not from a blank product canvas.

levelsio framed the plan as food-heavy, saying it is "literally 80% food and 20% exercise" in his food-versus-exercise reply. He also told one commenter the 300 to 500 calorie deficit was meant to preserve muscle while losing fat in his deficit reply.

The food database needed enough detail to catch calorie traps:

• levelsio's Oikos post called out a Portugal Oikos Greek yogurt page showing 3.2g protein per 100g.
• Low carbs were part of his own experiment, and his lifting reply said he had been breaking lifting records that week.
• Meal weights were mostly logged after cooking, according to his weighing reply.

Photo logging is the automation layer. levelsio said Caltrack scans food photos with xAI Grok 4 vision to calculate intake, while his follow-up named the connected API as Grok 4.2 vision.

The workflow still mixes estimation and measurement. levelsio's scale reply said photos can guess "pretty well," but he uses a scale at home.

xAI's image understanding guide covers image inputs for Grok models. Caltrack uses that capability as a meal-entry shortcut, not as a replacement for the food log.

The sharpest line in the thread was about memory. Chat apps got messy and forgot context, while the coding agent could check the SQLite database before answering what to eat next, according to levelsio.

marckohlbrugge picked up the same missing primitive. marckohlbrugge's reply said it was strange that ChatGPT-like apps still lack a proper built-in database, and his follow-up argued that such a database would unlock many use cases.

That is the Caltrack pattern in one sentence: chat for questions, SQLite for state, Claude Code for changing the app when the workflow changes.

Caltrack sits inside a broader habit: levelsio said everything he does is on a VPS now because local AI coding costs battery and slows deployment in his VPS post.

The tradeoff showed up immediately. levelsio's safety note warned that coding agents can wipe files, adding that in this case the damage would be on the server and covered by backups.

The negative version is a locked surface. levelsio's Tesla Maps post complained that Tesla will not let him install Waze or Google Maps on the car screen, which is exactly the kind of personal software itch he can solve only when he controls the runtime.

The same week, levelsio used the VPS pattern to build and test a native iOS app without sitting at a Mac GUI.

The moving parts were:

• Native target: levelsio said he would go fully native with Swift in his Swift reply.
• Build host: his Mac Mini clarification described a Hetzner VPS SSH'ing into a MacinCloud Mac Mini to run Xcode headless.
• First run: levelsio's first build post said the app was made on the VPS, built on the Mac Mini, screenshotted, and sent back as a link.
• API glue: Claude Code ran on the same server as the site and created an API route consumed by native Swift elements, according to levelsio's API route post.
• Testing: the serve-sim clip showed a web-based iOS simulator streamed through an SSH tunnel.

levelsio called AI-assisted iOS easy after starting the day before in his one-day reply. DannyLimanseta's reply captured the creator-side effect: seeing the native Swift build made him want to try it instead of Expo.