Why
My data was everywhere. None of it talked.
My sleep lived in one app, my meals in another, what I read in a third, my money in a fourth. Each one knew a slice of my day and nothing about the rest.
I wanted one assistant that sees the whole picture and acts on it: notices a short night before I mention it, connects an article I saved to the thing I am working on, and stays quiet when there is nothing worth saying. I did not want to send my health, finances and reading habits to a third party to get it.
So I built the capture apps first, one per part of life, each useful on its own. Then I built the assistant on top, on hardware I own. I use it every day.
A real morning
What happens when my sleep data lands
Sleep arrives
traq.health pulls last night's sleep from the wearables and merges it into one record.
A signal, not a copy
traq.health sends giskard a short sleep_recorded event with the night's headline numbers. giskard keeps no copy of the health database.
A routine wakes up
The signal starts the morning memo, a short markdown prompt with a trigger and a list of tools it may use.
giskard reads what it needs
Sleep and recovery live from traq.health, recent screen time from traq.devices, then calendar, weather, open threads and goals.
A local model writes it
The memo is written on a model running at home, marked as background work, so a chat message would be served first.
It's waiting on my phone
The memo becomes today's brief, visible to every conversation that day, and a notification lands on my phone.
--- name: Morning Memo on_signal: source: traq_health event_type: sleep_recorded servers: [health, calendar, weather] result_artifact: daily_brief: true --- Write a short memo for today: health, calendar, open threads, one focus.
The routine is a prompt, not code. This is a shortened version of the real file.
The map
How it fits together
Apps tell giskard when something happens and giskard reads their live data when it needs details. Every local model call goes through one router. Click any box for details, or follow a walkthrough.
Scroll sideways to see the whole map.
Reading the map
Rose lines are events an app sends to giskard: a workout finished, a night of sleep recorded, an article saved.
Teal lines are giskard reading an app's live data, over MCP or a plain API, when it needs details.
Amber lines are model calls. All of them stay on the home server.
Violet dotted lines cross the internet. The food app is the one product that runs in the cloud.
The pieces
Each app is useful on its own
Every app has its own database, API and clients and does one job without giskard. Connected, they give the assistant a picture of my day that no single app has.
One record of my body, merged from Whoop, Garmin, Withings, lab results and what I log by hand: one value per metric per day, with its source. Its insights (training load, HRV trend, sleep debt) are plain arithmetic, no language model.
Log a meal by photo, chat, barcode or text, and a vision model estimates the items and macros. The one multi-user product, on AWS, with iPhone and Android apps and an MCP server that Claude and ChatGPT can use too.
Save anything worth reading, watching or hearing from the phone or the browser. It learns from my ratings and builds a morning reading deck; each save tells giskard, which links it to what I am working on.
Records where my hours go on the Mac and iPhone. A local vision model describes each block of time and writes a short narrative of the day, which giskard uses to know what I was actually doing.
A weekly-review cockpit for money: net worth, holdings, transactions and goals across accounts. Its advisor runs on a local model and never applies a suggestion on its own.
A recorder for iPhone and Mac that transcribes, tells speakers apart and writes meeting notes, all on the device.
The door to every local model. Each request says which service sent it and how urgent it is, so a voice reply is not stuck behind a batch job. It starts and stops the inference engines and shows who is using the GPU.
Runs an agent inside a throwaway microVM, with permissions and credentials applied from outside where the agent cannot reach them. The candidate sandbox for giskard's coding runs.
Design decisions
Three choices I would make again
Apps own their data. giskard asks.
Each app sends giskard a short event when something happens, then giskard reads the live details when it needs them. There is one source of truth per domain, and the apps keep working when giskard is off.
Trade-off: when an app is down, giskard cannot see its data. It says so ("health data unavailable") instead of guessing from yesterday.
One router for every local model call.
A home server has room for a couple of model calls at a time, and a coding run can hold one for many minutes. Charon tags every call with its service and urgency, serves interactive work first and can hold a slot back for it.
Trade-off: a running call is never interrupted, so heavy background work still costs latency. The router measures every wait, which tells me when that cost gets too high.
Capabilities are prompts. Hands are code.
The coach, the morning memo and the evening review are markdown files with a trigger and a tool list. Anything that must hold every time lives in code: each tool has an authority level, risky ones need my approval in chat, background runs refuse to execute code, and the heaviest tools are only handed to scoped sub-agents.
Trade-off: approvals add clicks. Small local models do not reliably follow rules written in a prompt, so the checks that matter cannot live there.
Privacy
Where data does leave home
Local-first is the default, not an absolute. This is the full list of what goes out, and why.
traq.food
A multi-user product, so it runs on AWS with Supabase. Meal photos and text are analysed by hosted Qwen models on Amazon Bedrock and Alibaba Cloud (EU region); the analysis worker runs on the home server and calls them.
Web search
Queries go to DuckDuckGo first, with Serper and Tavily as fallbacks. A local check screens every outgoing query and page fetch for personal details first.
Cloudflare
A tunnel for reaching home from outside, traq.world's share queue, and an offline copy of the reading library (including article text) so the phone works away from home.
Where the data already lives
Wearable data comes from Whoop, Garmin and Withings; calendar from Google (read-only); account data from banks and brokers; prices and exchange rates from public feeds.
Small services
Weather for my location, Wikipedia when the offline copy has no answer, GitHub for the Factory's pull requests, and Apple's push service for notifications.
Next
A per-run rule that keeps any work touching memory, health, journal or calendar context on the local machine, enforced in code.
Status
Not open source yet
All of this was written for one person on a trusted home network. Over the coming weeks I am preparing the components for release: hardening what assumed a private network, and removing anything personal.
If you want to run it yourself when it is out, or just want to follow along, the best place is LinkedIn.
The name
Why giskard
R. Giskard Reventlov is a robot in Isaac Asimov's The Robots of Dawn and Robots and Empire: plain-looking, in the background, and able to sense how people feel. That is the brief: empathic, capable, low-key.