What a personal AI system costs

Whenever I describe RafeOS to people, the first question is almost always the same. Doesn't all of this cost a fortune in AI? Agents reading your email, ranking your reading, writing your morning briefing: surely the token bill runs away from you.

The honest answer is no, and the reason is more interesting than the number. An agentic personal system is genuinely affordable, but that isn't luck. It's the product of a few deliberate decisions about which calls are allowed to be expensive. Treat everything as a job for a full agent and you would overpay handsomely. Get those decisions right and the spend is small and, more importantly, bounded.

This is the post where I show the working. Every figure is early state and indicative, and I'm still firming the numbers up, but it's the shape of the discipline, which transfers directly to anyone wiring AI into a product (and it is also one I can talk about it publicly, which is not true with some of my other work).

The cheapest call is the one you don't make

If there's one idea to take from this post, it's this. Most of the conversation about cost assumes the only question is which model you reach for. The sharper question, the one I had to design around, is whether you need a model at all.

A lot of what a personal system does all day isn't a judgement call. Has a measurement not been logged in three days? Is this Tube line reporting anything other than good service? Has this thread been sitting unanswered past my two-week boundary? None of that needs a model. It needs a few lines of plain code with a clear rule, and plain code is free, instant, and rarely wrong.

So the real spine of RafeOS cost isn't one boundary but three tiers, and the discipline is pushing every job to the cheapest tier that can actually do it:

• Deterministic rules (no model at all). Anything that can be expressed as a rule over data I already hold: thresholds, dates, status flags, presence. The cheapest call is the one you don't make.
• A cheap, fast model (classification and ranking). The narrow judgement calls. Is this email action-needed or noise? Which of these reading items earns a slot today? Real judgement, but narrow judgement, and a small model like Claude Haiku does it well for almost nothing.
• A frontier model (genuine reasoning and voice). The work that needs depth, or has to read as if a thoughtful person wrote it. Claude Sonnet territory: the weekly briefing's one reflective pass, the rare thing that earns the big model's money.

The mistake I sometimes see is treating every job as the top tier because "it's all agents now". That's a lovely demo and a terrible budget. Most of what the system does sits in the bottom two tiers, and a fair chunk doesn't touch a model at all.

When I built the messaging triage, model-based scoring on its own wasn't reliable enough. The fix wasn't a bigger model. It was a salience layer of deterministic rules underneath the scoring, doing the cheap, obvious filtering before anything reached a model. Cheaper and better. That pattern recurs across the system: rules first, model only for the bit that genuinely needs reasoning.

Library call or session

The three tiers tell you whether to use a model and which one. A second, narrower line decides how you call it, and this is relevant in a subscription versus per-call costing scenario.

The question is whether the calling code already knows what it needs the model to do. If it does (a known step with a known shape, like "classify this message" or "summarise this thread"), it doesn't need a whole agent. It needs a single model call: one prompt in, one structured answer out, no session, no tools, no reasoning loop. There's a small rafeos_llm helper for exactly that.

If it doesn't (the task is open-ended, might take several steps, might need to choose its own tools), it gets a session. Interactive when I'm there to drive it (subscription-covered, so I don't watch the meter), or headless (e.g. claude -p) when it's a remote or scheduled one-shot, which costs pennies.

A session is a powerful, general thing, and you pay for that generality. A library call is a function that happens to use a model. Most of what a personal system does all day is the second kind, and reaching for a session every time is another way the bill runs away.

What the actual envelopes look like

Here are some of the real numbers, with a firm caveat: this is an alpha system, so the figures are indicative. The orders of magnitude are the most interesting thing.

• Email and message triage. The dominant line by a clear margin, not because each call is dear but because of the sheer volume going through email and messaging. The action-needed ranker runs on Claude Haiku with a hard daily cap. It's where I'd look first if costs ever crept up. I also need to work out how to be more efficient on token volume.
• The morning briefing. A handful of model calls a day. It isn't regenerated every time I glance at it; it's built once per block of the day and reused (more on that below), which keeps a composite-of-everything surface from being expensive. Its top section, the few things to do and to know, is assembled deterministically from tools I already have, so the most-looked-at part of my day costs almost nothing.
• The weekly health briefing. This one earns a single call to Claude Sonnet: its one genuine depth pass, where the reflective, joined-up reading is worth the money. One deliberate expensive call, not a hundred cheap ones dressed up as a session.
• A remote headless query. When I fire claude -p from my phone to ask the system something, a typical query costs a few pence. Cheap enough that I never think twice about asking.

To put rough numbers on it (estimates, mid-build; the proportions matter more than the pennies):

Triage dominates not because any single call is dear but because of the volume going through it. The daily briefing's phrasing runs on a better (more expensive) model, but it's snapshotted, so a handful of calls covers the whole day.

One small operational nicety: each tool has its own API key, so each tool's spend shows up as a separate line in the dashboard. I can see at a glance which part of the system is costing what, and that view tells me unambiguously that triage is the line that matters. It's good enough up to four or five tools.

Deciding what runs, and when

The envelopes above are the per-call story. The bigger cost decision is about the regularly-scheduled background jobs that run without me asking. Each one is a standing cost, so you have to actively decide what's allowed to run, and how often.

You could run everything on-demand, only making calls when there's an automated or human interaction. It would keep costs down, but it's not really practical as the multi-second response time makes for a terrible "live" experience. So pre-warming makes sense (forecast when you'll need it), as does smart caching.

A couple of compromises fall out of this in practice. I don't run things overnight; there's no point paying for a briefing at 3am that I'll never see. And I've made the schedule morning-heavy, partly because that's when I use it and because some of the input data only arrives at a certain time. A lot of the health context lands after I've slept, on the Oura sync, and running the health pass before that data exists would be paying for a worse answer. The schedule isn't "run everything as often as possible". It's "run each thing once, at the moment it can actually be useful".

There's a safety net under all of this: daily caps on the metered jobs. They've never tripped, because I haven't been aggressive about scheduling, but I keep them precisely because I can see how quickly this could add up if I stopped paying attention. A loop that misfires, a job set to run every five minutes instead of every morning, a triage pass let off its lead. The caps are there so a mistake costs me a fenced amount, not an open-ended one.

Generate once, reuse all day

The briefing points at one more lever, almost embarrassingly simple: don't regenerate what hasn't changed.

The morning briefing is built on a snapshot cadence. It's generated once every few hours for a block of the day and then served from that snapshot (to the dashboard, to my phone, wherever) rather than freshly composed on every page-load. If I open the Cockpit five times before lunch, I'm not paying for five briefings. I'm paying for one and reading it five times.

It sounds trivial written down, but caching the output of an expensive call is one of the highest-leverage things you can do to control AI cost, and it's the one most easily forgotten in the rush to make things feel live. Most personal data doesn't change minute to minute. Your model spend shouldn't either.

So what does it actually cost?

Here's where I have to be honest rather than tidy, because there isn't one clean number. There are three, and the gap between them is the whole point.

The direct cost of RafeOS (the cockpit and the tools it calls, the metered machinery that runs by itself) is roughly £20 a month. That's the figure most people mean when they ask what RafeOS costs, and it's small.

If I'm fairer and allocate a proportional share of the broader setup to RafeOS (some of the interactive building, the substrate it leans on, the bits that overlap with everything else I do) I'd put it nearer £80 a month. Reasonable people could argue that number up or down; the boundary between RafeOS and "the way I work now" is genuinely fuzzy.

And my total personal AI spend is around £200 - £250 a month. Most of that is not RafeOS. It's Anthropic and OpenAI subscriptions, some per-use costs (including the £20 above), a clutch of AI-first productivity tools (I love Wispr and Granola), the odd experimental thing I keep around to learn or compare. There's probably more adjacent spend (e.g. Google Gemini comes through my wider Workspace subscription).

RafeOS is a beneficiary of this spend, not the cause of it. If RafeOS vanished tomorrow, the £200 would barely move.

What this means for anyone building with AI

Add it up and the conclusion is almost anticlimactic. RafeOS runs for a small, bounded amount because the architecture refuses to let cheap jobs cost expensive money. Four habits do most of the work, and none of them is exotic:

• Don't call a model if a rule will do. The cheapest, fastest, most reliable tier is plain code. Reach for a model for genuine classification or reasoning, not for things a threshold can answer.
• Tier the models you do use. Narrow judgement on the small fast model, depth and voice on the frontier one. The model choice, not the call count, is where the money goes.
• Decide what runs and when. Scheduled background jobs are standing costs. Run each one once, at the moment its data exists and you'll actually use the output. Cap them so a mistake is fenced.
• Cache what you generate. Produce expensive outputs once and reuse them across surfaces. "Feels live" is rarely worth regenerating what hasn't changed.

That's the part that generalises, and it's the same restraint that makes any system affordable: know which operations are expensive, and only spend there when the job actually earns it.

There's a wider point underneath the numbers, and it's the honest answer to "should you do this too?". Cost discipline is, I think, what will hold some people back from building something like RafeOS. Not the engineering, but the running cost and the fear of it. My own stance is that it's an investment in understanding how this actually works: the real economics of agentic services, where model costs land, what the constraints and pressure points are. The value is genuinely there for me.

And paying attention to the bill is exactly what surfaced the next two moves: running a local LLM for the cheap, high-volume tiers, where the token economics start to favour it, and the data-and-privacy upside that comes with keeping more of this on my own hardware. You don't see either clearly until you've felt where the money goes.

This post was drafted with Claude and edited by me. The figures here are from June 2026 and a system still under active development, so treat them as indicative.