Every tool and model we run

I read a post this week from Corey Ganim listing the AI stack he runs his business on.

Six lines: Claude Code and Codex as the workbench, GrokBot as the workforce, Slack for communication, a second brain in GitHub, Composio for tool access, GoHighLevel for CRM. Nine thousand people looked at it.

That surprised me for about four seconds, and then it did not, because almost nobody publishes what they are running.

You get case studies and launch threads. You almost never get the list.

The trouble with the list is that it stops exactly where it gets useful. Six product names tell you what somebody signed up for.

They do not tell you which two of the six the business would die without, or why a piece of work goes to one model instead of another. So here is ours, with all of that attached.

One caveat. A few of our integrations run against client accounts where publishing the method would be a problem for them, so those stay unnamed. Everything else is here.

Six product names tell you what somebody signed up for. They do not tell you which two the business would die without.

The nine things we would not survive losing

We run nine agents. Each one sits on a single project and stays there, and I talk to them the way I would talk to a person who owns that project. Underneath them, this is what is load-bearing.

• Claude Code. Nine persistent agents, one project each. The substrate everything else hangs off.
• Codex. On a separate ChatGPT Pro subscription, on purpose. The second model lane, and the code reviewer.
• GitHub. Code, the merge gate, and two build runners on our own hardware.
• Linear. Work tracking, and the backing store behind every agent status page.
• Supabase. Application databases, plus the memory that survives a restart.
• Vercel. All site hosting, across two teams.
• Replicate. Every image and every video. One platform by policy, not five accounts.
• Composio. Third-party API access, mainly mail and publishing.
• Browser automation. For the services that never shipped an API.

One of those matters more than its one-line job suggests. Every agent starts each session with no recollection of the previous one, so anything that has to survive the night is written into Supabase or it is gone.

And the browser automation line is duller than the thing deserves, but that detail is not mine to publish.

The twenty we would grumble about and replace

Below the load-bearing nine sits a second tier we use constantly and could swap inside a week.

• Booking and mail. Cal.com for scheduling, Resend for transactional mail, AgentMail so every agent has its own inbox.
• Research and reference. Exa, Perplexity, Context7 for library documentation, Mobbin and ScrapeCreators for design and social reference.
• Search and analytics. DataForSEO for ranking and listing data, Google Search Console, Bing Webmaster Tools, PostHog for product analytics.
• Media. ElevenLabs for voice, Pexels and Coverr for stock footage, Epidemic Sound for music.
• Plumbing. Namecheap and DNS Made Easy for domains, Railway for one worker that fit nowhere else, and OpenRouter, which for us is not a general gateway but one specific cheap lane.

That is the whole inventory. Roughly thirty services, nine of which are structural. One is worth singling out.

Bing Webmaster Tools is the one everybody forgets, and it is not cosmetic: Yahoo and DuckDuckGo both read from Bing's index, so a site missing there is missing from three engines at once. We learned that the expensive way.

If you were rebuilding what we have from scratch you could get most of the way there with a credit card and a weekend.

The part you cannot sign up for

That last line is not true, and the reason it is not true is the piece every stack list misses. You could buy all thirty services in a weekend and you still would not have what we have.

Sitting on top of them are 380 command-line tools we wrote ourselves. Not scripts somebody left behind.

A maintained set the agents use constantly, and it is the answer to what we actually run.

Here are a few, so this is not abstract.

• The merge gate. And the review tooling around it. Nothing lands without a second model looking at it.
• A fleet scanner. It walks every repo looking for broken invariants, paired with something that closes the findings instead of filing them. A list of known problems that nobody works is just guilt with a timestamp.
• Heartbeats. They wake an idle agent and push it to finish what it started.
• Hub sync. Every agent's public status page mirrors its Linear project, so nobody maintains a second thing.
• A model-usage tracker. It counts what every model actually moved, which is where the two counting findings below came from.
• A mail sender. Mandatory signature, and a set of guards on it.
• A deploy protocol. It refuses to run against a dirty working tree. That one exists because we shipped from one once.
• Enforcement hooks. They block bad agent behavior at the moment it is attempted, rather than writing a rule in a document and hoping.

That last one is worth dwelling on. A rule you have to remember is a rule you will break, and an agent is no better at this than a person.

Every behavior we genuinely depend on is either enforced by something that intercepts the action, or it is a wish.

Knowing which of your controls are walls and which are only promises is one of the more uncomfortable audits you can run on your own system.

A list of known problems that nobody works is just guilt with a timestamp.

Every model in service, and where it runs

Five models are doing work at any given moment, and they are not interchangeable. The split is not about which is best. It is about which is the cheapest one that can finish the job.

The agents I talk to run a top-tier model, because those are the ones making decisions.

Engineering agents sit on Claude Opus 5.

The two design agents run Fable 5.1, which turned out to be unusually good at page design and graphics in a way I did not expect from a language model.

Anything those agents spawn drops to Sonnet by default, enforced by a hook that rewrites the request on its way out rather than by asking politely.

Jobs that are pure reduction, summarizing a transcript or classifying a pile of rows, fall further to Haiku automatically from the shape of the instruction alone.

The two lanes that are not Claude

Spec-tight code goes to the Codex lane on the separate OpenAI subscription, which keeps it off the Claude allowance entirely.

That lane is set to GPT-6 Astra, OpenAI's newest and strongest coding model, which shipped this week as a limited preview and which we have access to. GPT-5.6 Terra, the previous one, is the fallback.

Being straight about the split, because it is the kind of thing these posts always smooth over: across the same seven days Astra moved 7,084,887 tokens and Terra moved 89,750,720. Do that division yourself.

Astra needs a newer Codex binary than one path in our setup was resolving, so calls kept falling through to the fallback.

The configuration is the interesting part and the volume has not caught up to it yet.

There is also a cheap lane off the Claude plan entirely: GLM 5.3-flash, a cheap, fast model from the Chinese lab Z.ai, metered through OpenRouter at roughly ten cents a task.

It is built for the token-heavy grunt work, the big sweeps and log reductions and bulk first drafts. I will be straight about it: it is wired in and we have barely used it.

That is a habit problem, not a plumbing problem, and we are fixing it this week.

Then we counted how often we actually use it

Now the measurement that embarrassed us, and it landed while this article was being written. Everything above describes where work goes when an agent hands it off.

So we counted how often that happens. Over the same seven days the agents made 22,225 tool calls and spawned 195 of them out to a cheaper model.

That is 0.88%. Seventy-two percent were shell commands the agent ran itself, and another thirteen percent were reads and edits it did itself.

The router is not broken. Zero Fable tokens in that window came from spawned work, so it does exactly what it claims on every job that reaches it.

Almost nothing reaches it.

We had solved where delegated work goes without noticing that our agents hardly delegate, and the GLM lane tells the same story from the other end: wired up, priced, and carrying almost none of the volume it was built for.

156 worker runs in its entire history, every one of them on the default lane rather than the cheap one.

A rule you have not measured is not a rule

I am leaving that in rather than tidying it, because it is the most useful thing in this section.

A routing rule you have not measured is a routing rule you do not have.

We wrote ours, published it, believed it, and it was governing under a hundredth of the work.

For what it is worth, we got this number wrong twice before printing it, once by measuring a window that had not closed and once by counting the same files four times through symlinks.

The percentage barely moved either time. The absolute counts moved a lot.

If you set up tiering this week off the back of the last piece, go and count what actually got delegated before you congratulate yourself. I did not, and this is what counting found.

Images and video get picked per job

The generative side is its own set, and it is the one place we pick per job rather than per tier:

• GPT-Image-2. For anything carrying label or regulatory text. It is the only one that reliably does not garble a brand line.
• FLUX 1.1 Pro. General images. And FLUX Kontext Max to delete one object from a scene without re-rendering the whole thing.
• Nano Banana Pro and Nano Banana 2. Google's image models.
• Recraft V3. Vector, plus its upscaler.
• Kling v2.6 Pro and Wan 2.5. Video.
• Gemini 3.6 Flash. It judges the output, because the model that made a thing does not get to grade it.

Two rules decide all of it

You do not need to remember any of those names. You need the two rules underneath them, because the rules are portable and the model list will be wrong in a month.

Rule one. Five kinds of work always keep the strongest model available, no justification required:

• Reasoning and planning in the main session.
• Creating an image or a video, start to finish.
• Defining how a website looks, before anyone writes a line of CSS.
• Prose a person is going to read.
• Judging whether something is good enough to ship.

That last one gets skipped constantly and it is the expensive mistake, because a weaker judge waves through weaker work and you do not find out for a month.

Everything outside those five has to say in one line why it needs a bigger model, and almost nothing can.

Rule two. The model that did a piece of work never gets to be the model that checks it. Claude writes the code, Codex reviews it. Codex writes it, Claude reviews it.

Same idea as not letting somebody mark their own homework, and the failure mode when you ignore it is not that the reviewer is too soft.

It is that the reviewer has exactly the same blind spot, so the bug they both cannot see sails straight through with two approvals on it.

The reviewer has exactly the same blind spot, so the bug they both cannot see sails through with two approvals on it.

Ninety-eight percent of it was re-reading

Here is the finding I did not expect, and it is the most useful thing in this piece.

When we went looking for where Fable was burning through the weekly allowance, the assumption was that it was doing too much expensive work and needed to do less of it. That was wrong.

Roughly 98% of the tokens Fable moved were the model re-reading its own accumulated conversation, over and over, rather than producing anything.

That comes out of ccusage, an open-source tool that reads Claude Code and Codex session logs on your own machine and adds up the input, output, cache-write and cache-read tokens each model actually moved. You can run it against your own logs tonight.

A long agent session carries its entire history forward on every single turn. The work is the small part. The remembering is the expensive part.

The fix was shorter sessions, not cheaper models

Which means the fix was not to downgrade the model. It was to recycle long sessions before they got fat. We did not reduce Fable usage by using Fable less on the jobs that need it.

We reduced it by not paying to re-read the same context on every turn. Across those seven days Fable took 13,536 turns, and the average turn re-read 499,000 tokens of accumulated conversation before it did anything. Half of them were above half a million.

I think this is the thing most people are getting wrong right now, including me until this week. If your agent costs are climbing, the instinct is to reach for a cheaper model. Check the shape of your sessions first.

You may be paying almost all of it for memory rather than for thinking, and no amount of downgrading fixes that.

Why the design agents kept the expensive model

It also explains why the design agents stayed on Fable and are staying there. Creating an image or a video, and deciding how a page should look, are on the short list of work that keeps the strongest model with no justification needed.

Cost discipline never meant demoting everything. It meant the expensive model stays exactly where it earns its price, and stops paying rent everywhere else.

The work is the small part. The remembering is the expensive part.

The constraint moved

One more thing that took me a while to get my head around. A flat plan does not mean free, and it does not mean unlimited. It means the scarce resource stopped being dollars and became capacity.

There is a shared weekly ceiling, nine agents draw against it, and when it is gone it is gone regardless of how much money is in the account.

That changes what you optimize for. Under metered pricing you are watching a number go up and deciding what to stop doing.

Under a plan you are deciding what deserves the ceiling, which is a better question and a more uncomfortable one, because it forces you to rank your own work rather than just spend less.

What we cut, and what it taught us

Two things went wrong recently and both are worth copying.

Our Vercel bill ran away from us one month, which for a handful of marketing sites is absurd. The cause was not traffic.

It was build volume: a scheduled job running every thirty minutes, preview deployments firing on every branch whether or not anyone was looking at them, and an operations snapshot being regenerated inside the build.

Three changes fixed it. The cron dropped to every six hours, previews got restricted to open pull requests only, and the snapshot moved out of the build entirely. Deployments went from around 4,500 a month to a target of under 800.

The second one is smaller and I like it more. Our OpenRouter account has a hard cap on it, and that cap fails closed. It does not send a warning email and keep spending. It stops.

Every metered service you run should have a ceiling like that on it, set at a level where hitting it is embarrassing rather than fatal, because the alternative is finding out at the end of the month.

If you want to do this yourself

Copying our list is not the useful part. Half of it is specific to running nine agents across four businesses and would be dead weight for anybody else.

The useful part is producing the same document for your own setup, because most people cannot, and the gap between what you think you are running and what you are actually paying for is usually where the money is.

So there is a worksheet below.

It is written for an agent rather than for you: paste it into whatever you are running and it will walk your accounts, sort what it finds into load-bearing and convenience, attach a monthly number to each one, and flag anything that is metered without a cap.

It will also ask you the two routing questions and tell you where your defaults are wrong.

We will publish this again every month

One more thing, and it is a commitment rather than a finding. This list was wrong twice while I was writing it. The desks changed models the morning of, and the delegation number landed after the piece was already published.

A stack post is a photograph of something that will not hold still, and most of them get published once and quietly rot.

So we are going to redo this one every month, recount, and show you what moved.

The 0.88% is the figure I most want to put back in front of you in thirty days, because we are fixing it this week and I would rather you watch that happen than take my word for it.

One instruction in the worksheet is worth calling out because it is the one people remove. It tells the agent to write UNVERIFIED next to anything it could not confirm, and to count those in the summary. Leave that in.

A stack audit that quietly rounds guesses into figures is worse than no audit, because you will act on it.

You are working in Claude Code. You may read this repository and run commands for this audit; ask me for anything you cannot access.

# 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: 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.

• The best AI model shipped. Our token burn dropped. (The routing rule in full, with a paste-in version for your own agent.)
• Why your AI fleet needs a GM (How the agents are supervised, and which controls are walls rather than promises.)
• Corey Ganim's stack post (The post that prompted this one.)
• OpenRouter (Where the cheap bulk lane runs, and where the hard cap lives.)
• Replicate (Every image and video model in the table above.)