> /writing/cut-ai-costs-gtm-automation

How to Cut AI Costs Without Killing Your GTM Automation

ai gtm·5 min read·July 10, 2026

The AI bill is the new wakeup call. The teams that survive it engineered for it on purpose.

Six months ago the mandate was simple. Adopt AI or fall behind. Teams wired the most capable model they could find into every workflow and called it progress.

Now the bill arrives. Founders are posting screenshots of overnight cost jumps of three and four times, and finance is asking a harder question than "are we using AI." They are asking what the spend actually produced. That reckoning is coming for every team that automated everything at frontier prices.

The reflex is to pull back on AI. That is the wrong lever. The bill is not an adoption problem, it is an engineering one. And the fix is a discipline most teams skipped on the way in.

The discipline that makes an AI system trustworthy is the same discipline that makes it affordable. It runs on two layers.

Why are AI bills exploding in the first place?

Because the fastest way to ship an AI workflow is also the most expensive one. Reach for the largest model, point it at the whole task, let it run. It works in the demo, so it ships.

Then it runs a thousand times a week on live data, every token metered at frontier rates, and nobody scoped which parts of the job actually needed that horsepower. The cost was never usage exploding. It was capability applied indiscriminately.

Frontier models are getting more expensive, not less. So the answer is not waiting for prices to fall. It is spending expensive capability only where it earns its keep.

Layer one, tier your models

Not every step of a task needs your smartest model. Treat model selection like staffing.

The most capable model is a specialist you call when the problem is genuinely hard, the kind of subtle, ambiguous work where a cheaper model is confidently wrong no matter how much context you give it. A good generalist model handles the routine execution, the edits you can describe precisely and the mechanical changes, at a fraction of the price and no loss of quality.

In my own build process the split is explicit. The most capable model orchestrates. It plans the work, holds the judgment calls, and decides what happens next. A cheaper generalist does the execution underneath it. The expensive model is the architect on the call, not the one turning every screw.

The mistake is using the specialist for the whole job. You pay top rates for work a generalist would have nailed, and the specialist was never the bottleneck on that part anyway.

Layer two, tier your workflows

The deeper savings come one level down, in deciding which work needs a model at all.

Most GTM workflows are 70 to 80 percent deterministic. Read the inbound, classify it, route it, update the field, pull from the CRM, format the record, send it on. None of that is judgment. It is rules, and rules run on plain automation for a rounding error next to a token bill.

The remaining 20 to 30 percent is where the real judgment lives. Reading whether a discovery call signaled intent or politeness. Choosing between two positioning angles when the context is thin. Weighing signals that point in different directions. That is where a model earns its cost, and where I spend it.

This is how the systems I build are structured. Every task is tiered before it runs. The deterministic majority goes to automation. Model calls are reserved for the judgment, and even then the work is gated and checked. The result is a system that is both more reliable and cheap enough to keep running when someone finally audits the spend.

How do you audit your own AI spend?

Start with visibility at the run level, because that is where the leverage hides. Most teams see one number, the monthly invoice, and a monthly total is a finance ledger, not an engineering signal. You cannot fix a ledger.

In my stack every agent run logs a structured cost line. Input tokens, output tokens, cached context, tool calls, sub-agent invocations, latency, and which model handled it. The category breakdown is the whole point. A spike in total cost is unactionable. A spike attributed to ballooning input context points at a cache miss you can fix this afternoon. A spike in sub-agent calls points at an orchestrator delegating too aggressively. Same bill, but now it argues with you in specifics.

Then put a budget gate on autonomy. Each agent gets a maximum cost-per-run threshold when it is first instrumented, and if runs start blowing through it, autonomous status is suspended until someone diagnoses the spike. Either the workload genuinely changed and the threshold moves, or the agent regressed and gets fixed. If that mechanism sounds familiar, it should. It is the same contract as the eval gate, applied to economics. Quality contracts without economic contracts produce agents that work and bankrupt the team.

Cost as a discipline is solvable. Cost as an unknown is not.

The point underneath

Cost control and reliability are not two projects. The tiering that keeps a system affordable is the same tiering that keeps it trustworthy, because both come from the same act: knowing exactly which part of the work needs judgment and spending your expensive capability only there.

Everyone is racing to wire AI into their go-to-market motion. The teams still running theirs a year from now will be the ones who built for the bill from the start.


FAQ

Does using a cheaper AI model hurt quality?

Not on routine work. For edits you can describe precisely and mechanical changes, a good generalist model matches a larger one at a fraction of the cost. Reserve the largest model for genuinely hard problems, subtle bugs, ambiguity, and decisions where a smaller model stays confidently wrong no matter how much context it has.

What is the difference between choosing a model and adjusting effort?

The model controls what the AI knows and what each token costs. Effort controls how thorough it is, how many files it reads and how much it verifies before it finishes. When output is wrong, check your context first. Then ask whether the tool did not know enough, which is a model problem, or did not try hard enough, which is an effort problem.

How do you cut AI costs without losing capability?

Tier at two layers. Match the model to the difficulty of each step rather than running the largest one everywhere, and route the deterministic majority of a workflow to plain automation so model calls are reserved for real judgment.

Is this related to outcome-based pricing?

Directly. As buyers scrutinize AI spend, pricing is moving toward paying for delivered outcomes rather than tokens or hours. The same instinct drives both, spending on the result that matters instead of the effort behind it.

— jd

# discussion

What did your last AI bill teach you that the demo didn't?