The most expensive mistake in AI agents is not picking the wrong model. It is putting a model where no model belongs. I run agents and automations every day — batch content pipelines, SEO audit crews, translation runs across six locales, plus the scheduled jobs that keep this site alive — and the discipline that actually controls the bill has three layers: delete the model where code will do, tier the model where one is needed, and move metered work onto flat-rate capacity wherever latency allows. Model selection, the thing every cost guide leads with, is only the middle layer.
Here is how I apply all three, with the real systems behind each.
Layer 1: The cheapest model is no model
This site regenerates its sitemap every five minutes. A newsletter pipeline sends issues on schedule. Cache invalidation fires automatically whenever content changes. Total LLM cost of running all of it: zero. They are a Laravel scheduler command, queue jobs, and model observers — deterministic PHP that an AI helped me write once and that has run unattended ever since.
That distinction — AI builds the automation versus AI is the automation — is where most 24/7 agent budgets die. The classic money furnace is the heartbeat: an agent polling "any pending tasks?" every ten minutes through a frontier model. Polling a queue is not reasoning. It is if (count > 0). A cron job checks it for free, forever, and wakes an agent only when there is real work to judge.
Before you optimize which model handles a recurring task, ask whether the task needs a model at all. In my experience auditing my own stack, the majority of "agent activity" — status checks, file moves, feed fetches, structured extraction from predictable HTML — is deterministic work wearing an AI costume. Even my Claude Code status line, the thing that watches my sessions all day, is a 40-line bash script, not a model call.
Layer 2: Tier by verifiability, not by task type
When a model genuinely is required, the standard advice says "simple tasks get cheap models, hard tasks get expensive ones." That's directionally right and operationally useless, because agents are bad at pre-classifying their own difficulty. The rule I actually route by: how mechanically can I verify the output?
- Output verifiable by a script → cheapest capable model. When I translated a couple hundred blog posts into five additional locales, the pipeline had hard checks — length ratios, preserved markdown structure, untouched code blocks, valid JSON per locale. A cheap model failing those checks gets caught and retried for pennies. Paying flagship rates there buys nothing a validator doesn't already guarantee.
- Output verified by my judgment → mid-tier. Batch content work like the 594 prompt-library descriptions I generated in six waves: each unit is small, reviewable at a glance, and the blast radius of a weak one is tiny.
- Output that IS the judgment → frontier model, full effort. Architecture decisions, refactors of production services, anything where a subtle mistake ships. This is also where I stop economizing on thinking tokens — a wrong cheap answer costs more than a right expensive one.
The price spread makes this routing worth engineering. At current Anthropic list prices, Haiku 4.5 runs $1/$5 per million tokens in/out against $5/$25 for the Opus tier — a 5x spread on every token, before the two multipliers below. The same logic drives how I structure subagents: exploration and search workers run cheap models in their own context windows and return conclusions only, while the orchestrating session stays on the expensive model. I break down the tool-side version of that arithmetic in how advanced tool calling cut my agent costs.
Layer 3: Stop paying interactive prices for background work
Two API-level levers apply to almost every recurring agent job, and they stack:
- The Message Batches API is 50% off input and output for asynchronous work. Every one of my batch jobs — content generation, translation, enrichment — is latency-tolerant by definition. If a job runs on a schedule, it can almost always wait the minutes batch processing takes, and half price is the reward.
- Prompt caching cuts repeated input to a tenth of list price. An agent that carries the same system prompt, tool definitions, and reference documents into every call is re-buying the same tokens all day. Cache that stable prefix once and each subsequent read costs 0.1x. For a 24/7 agent whose prompt scaffold dwarfs its per-task input — which describes nearly all of them — this is the single biggest line-item cut available.
And one lever that pricing pages don't mention: subscription arbitrage. My daily interactive work runs inside a Claude Code Max plan — flat rate, not metered. The API meter only runs on headless jobs. So any workload that can happen inside a session I'm already paying for, does: audits, batch rewrites dispatched to subagent workers, one-off migrations. The metered API is reserved for what genuinely must run unattended at 3 a.m. Most solo builders have this exactly backwards, scripting everything against the API while their flat-rate seat sits idle.
The token side: waste is a cost multiplier on every layer
Routing decides the price per token; hygiene decides how many tokens you buy. Two habits with outsized returns:
Trim what agents carry. Every enabled tool schema, every bloated system prompt, every "just in case" file read is paid for on every single call. I keep unused skills switched off in my own config for exactly this reason — an agent hauling forty procedure documents into every request is a recurring charge disguised as preparedness. My notes on Claude Code token management cover the session-level version.
Compress where tone doesn't matter. For internal pipeline steps — planning, extraction, intermediate reasoning — terse prompts and terse output formats cut real money at volume. I tested an aggressive version of this idea in the Caveman skill experiment, and the broader principle survives even where the gimmick doesn't: verbosity in machine-to-machine steps is pure spend.
Context length itself is a cost control, not just a quality control — long polluted sessions burn tokens and degrade output, which is why context management shows up in my cost playbook at all.
A worked example: my daily SEO check
The shape of all three layers in one small system, one I actually run: a scheduled agent that checks this site's indexation health daily (build log here).
- No-model layer: fetching sitemaps, hitting URLs, diffing counts — plain scripted HTTP, zero tokens.
- Tier layer: interpreting anomalies ("indexed count dropped 4%, these 12 URLs went noindex — why?") — one model call on real reasoning, with only the diff as input, not the raw crawl.
- Flat-rate layer: the whole thing runs as a scheduled session under the subscription rather than metered API calls.
The naive build — an agent that "monitors my SEO 24/7" by continuously reading pages through a frontier model — does the same job for orders of magnitude more money. Same output. Different architecture.
The audit that starts everything
You cannot route what you have not measured. One week of logging every model call with its task type and token count will show you a distribution that surprises you — mine did, and it is why the no-model layer became layer one in this playbook instead of a footnote. Look for three flags: recurring calls with near-identical prompts (caching or cron candidates), calls whose output a script could validate (downgrade candidates), and calls where the model returns raw tool output instead of conclusions (subagent candidates).
Cost optimization for agents is not a hunt for a cheaper model. It is an architecture stance: deterministic code at the bottom, cheap verifiable inference in the middle, expensive judgment at the top, and flat-rate capacity soaking up everything that doesn't need to run at 3 a.m.
The architecture is the entire savings: the content pipelines, schedulers, and audit crews named in this post all sit on that four-layer split rather than on metered frontier calls. What they look like assembled is on the projects I've shipped.
