What Does a Personal AI Assistant Cost? A Reproducible Worksheet

Image: Aaron Lefler on Unsplash.

The cost that matters is cost per successful task: everything you spent, including failed runs, retries, hardware, hosting and your own time, divided by the tasks that actually worked. A token price on its own tells you very little.

This worksheet shows how to calculate it with your own numbers. It contains no vendor prices, deliberately. Prices change often; fetch current ones from each provider's official pricing page and write the date next to them.

It is part of the AI harness engineering guide.

Define the workload before estimating cost

Cost depends on what you ask the assistant to do. Write the workload down first.

Input	Example
Tasks per month	200 meeting briefs, 300 document questions, 100 email drafts
Typical input size	Five notes of about one page each
Typical output size	One page
Quality bar	Must pass your evaluation suite
Latency need	Brief ready within two minutes
Data constraints	Health and finance notes stay local

Split costs into two kinds:

fixed, which you pay even in a quiet month: hardware, hosting, subscriptions, backups;

variable, which grow with use: tokens, tool and API calls, extra compute.

Account for every cost category

Category	Measure or assume	Notes
Model usage	Measure tokens in and out per run	Include retries and failed runs
Tool and API fees	Measure calls per run	Search, transcription, paid connectors
Hosting	Assume monthly price	Servers, managed databases
Storage and backups	Assume monthly price	Including off-site copies
Hardware	Assume purchase price ÷ useful months	Only the share used for the assistant
Energy	Measure or estimate watts × hours × your tariff	Matters for always-on local machines
Maintenance time	Estimate hours × your hourly value	Updates, credential reviews, restore tests
Correction time	Measure minutes spent fixing outputs	Often the largest hidden cost

Keep measured and assumed values in separate columns. When someone challenges the result, you can show which numbers are evidence and which are judgment.

Measure cost per attempt and per successful task

Your harness should already write a receipt for every run. Add usage to it: tokens, tool calls, retries, duration and whether the run passed. The logging guide covers receipts.

Then the formulas are simple:

variable cost per run      = model cost + tool cost
monthly variable cost      = sum of variable cost over all runs, including failed ones
monthly total cost         = monthly variable cost + fixed costs + maintenance time + correction time
successful tasks           = runs that passed your success criteria
cost per successful task   = monthly total cost ÷ successful tasks

The denominator is the trap. If 20% of runs fail, the cost per successful task is higher than the cost per run, and the failed runs still cost money. A cheap configuration that fails often can cost more per success than an expensive one that rarely fails.

Report quality next to cost. Cost per successful task only means something if "successful" is defined by your evaluation suite.

Compare local, cloud and hybrid scenarios

Build at least three scenarios on the same workload:

Scenario	Model usage	Hardware	Hosting	Maintenance
Cloud	Provider fees per token	Your existing computer	Little or none	Low
Local	No per-token fees	Purchase or existing GPU machine	None	Higher
Hybrid	Fees for hard tasks only	Modest local machine	Little	Medium

Then vary usage. Low, expected and high volumes often change which scenario wins. Local setups tend to look better at high, steady volume because the hardware cost is spread over more tasks. Cloud setups tend to look better at low or bursty volume. Whether that holds for you depends on your numbers, which is the point of the worksheet.

Quality has to be equal for the comparison to be fair. If the local model fails twice as often on your tasks, include the correction time and the failed runs. The local hardware guide explains how to test that, and the local vs cloud guide covers the privacy side of the same choice.

Set budgets that actually stop work

Budgets in a spreadsheet do not stop anything. Budgets in the harness do.

Limit	Enforced by	At the limit
Steps per run	Harness loop	Stop with reason step_limit
Time per run	Harness timer	Stop with reason timeout
Spend per run	Harness, from token counts	Stop before the next model call
Spend per day or month	Harness counter, plus provider-side limits where offered	Pause new runs and notify you
Concurrency	Job runner	Queue rather than start

Two rules matter at the limit:

1. Stop visibly. The receipt says which limit was hit and what was left unfinished.
2. Do not reroute silently. Hitting a cloud budget must not quietly move sensitive tasks to a different provider.

Test each limit once with a deliberately small value, and check the receipt shows the right stop reason.

Update prices and interpret the results

Before deciding:

• fetch current official prices for every provider in the scenarios, and record the date,
• rerun the worksheet with measured usage from at least a week of real runs,
• check the result against what matters besides cost: privacy, latency and maintenance time.

A cheaper setup that sends sensitive data somewhere you did not intend is not cheaper. A local setup that eats five hours a month of your time may not be either. The worksheet makes those trade-offs visible; it does not make them for you.

Frequently asked questions

Is running a model locally always cheaper?

No. It depends on volume, hardware you already own, energy prices, maintenance time and whether the local model passes your tasks as often.

Should I count failed runs and retries?

Yes. They cost money and time even though they produce nothing usable. Leaving them out flatters every scenario.

How should I value hardware I already own?

Use its resale value or the share of its remaining useful life spent on the assistant, and state the assumption.

Can I guarantee a monthly cap with every provider?

Not everywhere. Enforce your own cap in the harness, and use provider-side limits where they exist as a second line.