Cutting Agent Costs: A Practical Checklist

Four levers meaningfully cut AI agent costs: the right model, caching, a lean context, and batch processing.

Why costs spiral fast

An agent doesn't call the model once — it often calls it dozens of times per task, for planning, tool use, intermediate steps. Without deliberate control, you frequently pay top price for work that never needed it.

Lever 1: model routing

Not every subtask needs the strongest model. Mechanical work — classifying, formatting, simple summaries — goes to a cheap, fast model. Complex planning and hard decisions stay with the strong model.

Lever 2: caching

When an agent repeatedly sends the same long prefix (system prompt, tool definitions), prompt caching means that part doesn't have to be recomputed every time — as long as requests follow each other within a short time window.

Lever 3: keep context lean

Disable tools you're not using, clear context between unrelated tasks, pre-filter verbose log or test output instead of passing it through whole, and offload detail knowledge into skills instead of dragging it along in CLAUDE.md permanently.

Lever 4: batch processing

For large volumes of non-urgent requests (bulk classification, evaluations), a batch API beats individual calls — significantly cheaper, in exchange for no immediate response.

These four levers combine: the cheapest model that still does the job, with a cached prompt prefix, a lean context, processed in batch.

EXAMPLE

A nightly job classifies 8,000 support tickets by urgency. Instead of querying each ticket individually and synchronously with the strongest model: classification rules and examples form a shared, cached prompt prefix, a cheap model handles the actual classification, and all 8,000 requests run together through the batch API instead of one by one.

🛠️ EXERCISE — TRY IT YOURSELF

Analyze one of your own recurring agent workflows against the four cost levers and identify where at least one of them goes unused.

List your workflow's steps and mark which model currently handles which step.
Check: is there a long, repeated prompt prefix (system prompt, rules, examples) that would benefit from caching?
Check: does the workflow run time-critically/synchronously, or could part of it run as a non-urgent batch instead?

✅ SELF-CHECK

☐ Is at least one mechanical substep currently running unnecessarily on an expensive model?
☐ Do you know whether your prompt prefix gets reused within the cache TTL, or gets rewritten every time?
☐ Is there a part of your workflow that doesn't need an immediate answer and would fit batch processing?

QUICK QUIZ

Which combination typically cuts the cost of a nightly bulk classification job the most?