Auditing Your Workflow With Cheap AI Models: Token Math, Prompt Design, and the Observations-Ledger Pattern
Most "AI-powered" productivity summaries are expensive to run and useless to read. They cost more tokens than they should because they re-explain your whole day from scratch every time, and they read like a fortune cookie because the prompt never gave the model anything concrete to point at. You can fix both problems with cheaper models and better plumbing. This is the plumbing.
Why generic summaries fail
A typical AI daily summary looks like: "You had a productive day with some distractions in the afternoon." That sentence is true of almost every day anyone has ever had. It costs tokens to generate and costs nothing to ignore, which is the worst combination — you paid for advice you can't act on.
The failure isn't the model. It's the input. If you feed a language model a vague bucket like "3.2 hours on 'Browser'," it can only produce a vague sentence back. Task-interruption studies consistently find that context-switch cost is driven by what the switch was to and how long the return took, not by the raw duration of the distracting app. A summary that doesn't carry switch-level detail can't name a real leak — it can only gesture at one.
Token math: what a daily brief actually costs
Before optimizing anything, put a number on it. A daily brief needs, at minimum: a compact log of the day's app/window switches, some derived stats (longest focus block, number of switches, time-of-day distribution), and a prompt instructing the model to name specifics. Here's the arithmetic for a moderately active day — 140 window switches, 9 working hours:
| Component | Approx. tokens | Notes |
|---|---|---|
| Raw switch log (140 events, timestamp + app + title, truncated) | 1,800–2,600 | ~13–19 tokens/event after truncating titles to 40 chars |
| Derived stats block (focus blocks, streaks, hourly buckets) | 150–250 | Computed locally, not by the model |
| System + instruction prompt | 300–500 | Includes formatting rules and 2–3 few-shot examples |
| Output (brief + 2–4 named leaks with fixes) | 250–450 | Kept short deliberately — see prompt design below |
| Total per day | ~2,500–3,800 | Input-heavy, output-light |
At current pricing for small/cheap instruction-tuned models (roughly $0.10–$0.30 per million input tokens, $0.30–$0.60 per million output tokens on the low end of the market as of this writing), a single day's brief costs somewhere between $0.0004 and $0.002. Thirty days a month lands you between $0.01 and $0.06 — genuinely negligible. The real cost isn't dollars, it's context-window bloat if you're sloppy: send the same 140-event log with full window titles, no truncation, no dedup, and you can triple the input token count for zero gain in output quality. Truncate titles, dedupe consecutive identical switches, and drop events under 5 seconds before you ever call the API.
This is why local-first architecture matters here, not just for privacy. If the raw event capture and the stats derivation happen on-device — which is how the free watcher works — you only ever send a compact summary to the model, not a live stream of everything you did. That's what keeps the token math this small.
Prompt design: force specificity, don't hope for it
The single highest-leverage change you can make is refusing to let the model describe a category. "Browser" is not a leak. "Reddit at 10:40am for 22 minutes, right after a 51-minute focus block on the quarterly doc" is a leak, because it's falsifiable — you can check tomorrow whether it happened again.
Three concrete rules that make the difference:
- Require named entities, not categories. Instruct the model: "Never write 'social media' or 'browsing.' Name the specific app or site and the specific time window." If the underlying data doesn't have that granularity, the summary can't either — so capture it upstream.
- Require a mechanical fix, not advice. "Try to focus more" is not actionable. "Block Reddit between 10:30 and 11:30, the window where it interrupted your last three deep-work blocks" is. Ask the model to output a fix as an instruction to a rule engine, not as a suggestion to a human.
- Cap the leak count at 2–4. A list of eleven "insights" trains you to skim past all of them. Force the model to rank and cut. This also shrinks output tokens, which is the cheap side of the ledger anyway.
A rough prompt skeleton:
You are given a day's app-switch log and derived stats. Identify at most 3 specific time leaks. For each: - name the exact app/site and time range - state what it interrupted (task, duration of streak broken) - propose one mechanical fix (block rule, schedule, or notification change) Do not use category words like "distractions" or "social media." Do not give general advice. If no leak is clear, say so plainly.
The observations-ledger pattern
Once you're forcing specificity, a new problem shows up: the model has no memory of what it told you yesterday, so it can't tell you "this is the third day in a row this has happened," which is often the more useful fact than the leak itself. One-off vs. recurring is the difference between "meh" and "fix this now."
The fix is to keep a small, append-only ledger of past observations — not the raw logs, just the structured claims the model already made. Each entry is compact: date, leak name, time window, duration, and whether a fix was applied. On each new run, you feed the model the day's stats plus the last 7–14 ledger entries (a few hundred tokens, not the raw week of logs) and ask it to check for recurrence before naming anything new.
This does three things well:
- It turns single-day noise into a trend line without re-processing a week of raw events every day.
- It gives you an audit trail you can actually inspect — the ledger is just a small table, not a black box.
- It lets the model say "you already tried blocking this at 10:30 and it didn't work, the leak moved to 11:15" — which is a materially different insight than a fresh model call could produce.
The ledger itself is cheap to store (a day's entry is maybe 40–60 tokens) and cheap to read back. It's the single design choice that makes a daily brief compound in usefulness instead of resetting to zero every morning. If you want the mechanics of connecting this pattern to actual blocking rules rather than just narrative advice, that's covered in our Pro rule-engine notes.
Where this breaks
Cheap models are good at pattern-naming from clean structured input; they are bad at judgment calls with ambiguous input. If your event log has gaps (laptop asleep, meetings not captured, phone use invisible to a desktop watcher), the model will confidently narrate around the gap rather than flag it — so explicitly instruct it to say "no data" rather than infer. Also watch for anchoring: if yesterday's ledger entry says "Reddit at 10:30," a cheap model will sometimes report that time window again even when today's actual data shows something different. Always pass this day's stats as the primary source and the ledger only as secondary context, stated in the prompt in that order.
FAQ
Do I need a large/expensive model for this to work?
No — the task is closer to structured extraction and templated writing than open-ended reasoning, which is exactly what small instruction-tuned models are good at. The token math above assumes a cheap tier; bumping to a frontier model mostly raises cost, not accuracy, once your input data is already clean and structured.
How much history should the observations ledger keep?
7–14 days is enough to catch weekly patterns (a leak that only shows up on Mondays, say) without bloating the prompt. Beyond that, summarize older entries into a single "recurring leaks" line rather than keeping every daily row verbatim.
What's the minimum data I need to capture for this to be worth doing?
Timestamped app/window switches with enough title context to distinguish "writing docs" from "watching a video in the same browser." Duration-only tracking (just "browser: 3.2 hours") isn't enough — the model needs switch-level events to name anything specific, which is the whole point of the exercise.