Stop wasting tokens. Start with these four checks.

Open an expensive turn

By a turn, I mean the work from a user’s message to the agent’s answer. That can involve several model calls and tool results. Open the trace, the record of those steps, and inspect the input sent to each model call. The final answer alone won’t show you what it cost to get there.

Keep the broader operating budget in view, but use this checklist to find avoidable token spend inside the turn. Work through system prompt, tool output, caching, and model choice in that order. Keep a representative set of turns and their expected results so you can compare each change.

For the wider budget, including review and failed attempts, read The real cost of running an AI agent.

System prompt: am I stuffing too much in it?

Read the assembled input the model actually receives. The prompt file in your repository may be only part of it: your application can add instructions, examples, reference material, and tool definitions before sending the request.

Ask what each part is doing for this task. A classifier needs the categories, decision rules, and examples that help it distinguish them. It probably doesn’t need the instructions for writing a report or every tool available elsewhere in the product. Move task-specific material to the task that uses it; remove stale and duplicated instructions.

Don’t make the prompt shorter by removing the rule that prevents a wrong answer. Keep the output requirements, permission boundaries, and instructions for missing information. Check whether the edited version still makes the right decisions. Clearer instructions can be worth more than a smaller word count.

Tool output: what are my tools sending back?

Tools can send back a bloated response that eats up tokens just to interpret it. Open the exact text passed to the model, including the fields hidden when your interface displays a neat summary.

Consider a support-ticket classifier. This is a hypothetical example: the tool returns the customer’s message and ticket status, then repeats the whole ticket inside a raw-data field. It also includes avatar URLs and display settings. The application may need some of that information; the classifier doesn’t need a duplicate copy of the ticket.

Give the model a view of the response that fits its job. Preserve the message, status, timestamps, source reference, and any uncertainty that affects classification. Remove the duplicate and irrelevant display fields. If a field can vary, don’t silently replace it with a shared default.

The Thesis Finance cost investigation dated July 25, 2026 records an offline replay of 11 captured options turns using the founder’s own harness: $2.09 → $0.90 per turn after tool-payload and caching changes. A live production before-and-after was not recorded. That result supports investigating these levers; it isn’t a savings forecast for another agent.

Caching: am I actually getting reuse?

Make sure you have caching locked down. Caching lets you avoid “paying full freight” for tokens already ingested. More precisely, prompt caching can reuse an eligible, unchanged prefix of the input: the material at the beginning that stays identical between requests. The model still generates a new answer.

For Claude, put stable material before changing material. A timestamp inserted ahead of otherwise identical instructions can break reuse. Moving it later helps only if the eligible stable prefix was actually written to cache. Minimum input lengths and cache lifetimes also apply; check the rules for your model and provider.

Then read the usage returned by the API. Claude exposes cache_read_input_tokens for reads and cache_creation_input_tokens for writes. Inspect successive calls inside the tool loop as well as across user messages. A cached system prompt doesn’t prove the growing conversation is being reused.

Keep cache reads, writes, uncached input, and output separate when checking cost. Prompt caching doesn’t store a finished answer for replay, and it doesn’t eliminate the cost of new output.

Model choice: is it more than the job needs?

You don’t need the latest and greatest model for your simple classification task. If the job is assigning a ticket to a known category, test a less expensive candidate on the same examples and decision rules before making a frontier model the default.

Look at the wrong classifications and the ambiguous tickets, not just the easy ones. Check whether the candidate follows the required format, knows when to flag uncertainty, and needs more attempts to finish. Lower token rates don’t guarantee a cheaper turn if the model generates more text or takes more tool steps.

Don’t sleep on open source either. Include suitable open-source or open-weight models in the comparison, while checking the actual license and deployment requirements. If you self-host, count serving capacity, operations, and maintenance; if you use a hosted endpoint, count its charges. Available weights don’t make inference free.

Choose the model that meets the quality bar for this part of the workflow. A stronger model may still earn its place on a difficult judgment even when a simpler step can run elsewhere.

Run the checklist on a real turn

Pick an expensive turn and write down what you find: instructions it didn’t need, fields it didn’t use, input it could reuse, and a model choice worth testing. Change a lever, compare the same cases, and keep the failures visible. A lower bill is useful when the result still does the job.

The age of token maxing is over. We’re now in the age of token optimization. Start by looking at what you’re asking the model to read.