Life in Pixels, replayed.
Six months of my own daily data can be asked questions in plain language, and below are the twenty-six questions from the eval, played back one real run at a time: what the router decided, which days it pulled or computed, the answer it wrote, and what the validator said about it before anything was shown.
Nothing on this page is live. Every run is copied from evals/results/2026-09-22.json in the repo, and the data behind it is a seeded synthetic export shaped like mine, because mine stays on my machine. The answers are the model's, as recorded; when the validator disagreed with one, you will see that too.
In plain terms: you pick a question, and you watch the tool decide what kind of question it is, find the right days, write an answer, and then check its own answer before showing it.
01Pick a question and watch each step it took
the router and the answer are model calls, retrieval and the check are code, and the code gets the last word02What adding week-long summaries changed, and what it did not
In plain terms: adding week-long summaries fixed the one question about a whole week and found the same days as before for every other question.
03The same pipeline as an MCP server
The router, the validator and the model call are exposed over stdio as a local MCP server with two read-only tools, so Claude Desktop and Claude Code can ask the data questions while the data stays on the machine, a question sends only its evidence to the model provider, as the command line does, and list_days sends nothing anywhere and is capped at 100 days, and there is deliberately no write tool, and the config and the two tool schemas are in the repo.
In plain terms: RAG is how the answers get found, and MCP is a standard plug that lets Claude use that same search as one of its own tools, so I can ask my data questions from inside Claude, the log stays on my laptop, and only the days a question needs go to the model.