# Audit and price your own AI stack

Everything below this line is written for an agent, not for a person. Paste it into your agent's
instructions, or hand it over as a one-off job. It produces the same three tables published at
bluhook.com/learn/our-ai-stack-and-what-it-costs: a load-bearing inventory, a model routing table,
and a monthly cost picture with the gaps named.

Work through the sections in order. Do not skip to the summary. If you cannot verify something,
write UNVERIFIED next to it rather than estimating. An invented number is worse than a blank.

---

## A. Build the inventory

List every external service this business pays for or depends on. Look in all of these places
before you claim the list is complete:

1. Package manifests and lockfiles, for SDKs that imply an account.
2. Environment files and secret names. Names only. Never print a value.
3. CI and deploy configuration, for services called during a build.
4. Any MCP or tool configuration your agent runtime uses.
5. Scheduled jobs and cron definitions.
6. DNS records, which reveal mail, analytics and verification vendors nothing else mentions.
7. The billing inbox, if you have access to it. This catches everything the code does not.

For each service, record: what it is, the one job it does here, and whether the code paths that
use it run daily, occasionally, or never.

## B. Split load-bearing from convenience

For every service, answer one question and write the answer down:

> If this vanished at 9am with no warning, what stops?

Load-bearing means the business stops or degrades badly, and there is no same-week substitute.
Convenience means it would be annoying and you would replace it inside a week.

Be strict. Most stacks have fewer load-bearing pieces than their owners expect, and the surprise
is usually that something nobody thinks about, such as the DNS host or the queue, is holding more
weight than the tool everyone talks about.

Flag separately: anything load-bearing with **no** documented recovery path, and anything that is
load-bearing but is on a free tier or a personal account rather than a company one.

## C. Attach a number to each one

Produce a monthly figure for every service. Mark each as one of:

- **Flat.** A subscription. State the amount and whether it is the list price or the amount
  actually invoiced. Say which.
- **Metered.** Usage-billed. State this month's spend so far, the trailing month, and, critically,
  whether a hard cap exists.
- **Free tier.** State what the limit is and how close current usage is to it.

Then flag every metered service **without a hard spending cap**. Each one is a way to lose money
overnight. Recommend a cap for each, set where hitting it is embarrassing rather than fatal, and
confirm whether the provider's cap actually stops spending or only sends an email. Those are very
different products and the documentation often blurs them.

## D. Model routing

Build a table with one row per model in service: the model, where it runs, what it is used for.

Then check the two rules.

**Rule 1. The five reserved jobs.** These keep the strongest model available, no justification
needed:

1. Reasoning and planning in the main session.
2. Creating an image or a video.
3. Defining how a website or interface looks.
4. Prose a person will read.
5. Judging whether work is good enough to ship.

Everything else must justify a stronger model in one line, and almost nothing can. Reductions
(summarizing, classifying, extracting over bulk input) belong on the cheapest tier available.

Report every place the current setup violates this in either direction: expensive models doing
mechanical work, and cheap models doing any of the five.

**Rule 2. The reviewer is never the writer.** Whatever model or agent produces a piece of work
must not be the one that approves it. Check the review path for code, for content, and for
anything with a quality gate. If the same model sits on both sides, say so plainly. The failure
is not that the reviewer is lenient. It is that it shares the writer's blind spot exactly, so the
same defect passes twice.

## E. Find out where the tokens actually go

Before recommending a cheaper model, check the shape of the sessions. Long-running agent sessions
re-send their accumulated history on every turn, and that re-reading can dominate the cost while
producing nothing.

If this stack runs on Claude Code, `npx ccusage@latest` reads the local session logs and prices
them against published API list rates. Report the split between cache reads and everything else.
If the cache-read share is very high, the fix is session hygiene, not a downgrade.

For any other runtime, find the equivalent: total input tokens against output tokens per session.
An input-to-output ratio in the hundreds means you are paying for memory, not for thinking.

## F. Output

Return exactly this, and nothing else:

1. **Load-bearing table.** Service, job, monthly cost, cost type, recovery path or UNKNOWN.
2. **Convenience table.** Service, job, monthly cost.
3. **Model routing table.** Model, where it runs, what it does.
4. **Total monthly**, split into flat and metered.
5. **Risks**, ranked. Every uncapped metered service, every load-bearing item with no recovery
   path or on a personal account, and every violation of the two routing rules.
6. **The three changes** that would cut the most cost with the least loss of capability. For each:
   what to change, the expected saving, and what gets worse.

State your confidence per number. Where you could not verify something, the entry reads
UNVERIFIED and the summary says how many entries are unverified. Do not round a guess into a
figure that looks measured.