· 6 min read · AI

Read This Before Your Next Token Bill

#AI #Agents #Automation

Most of the tokens your coding agent uses don’t go into the fix. They go into full test logs, the same files read again on every retry, and tool definitions from MCP servers you forgot were connected.

Below is how to cut that. It works the same on Claude, GPT, Gemini, or anything else.

Find out where it’s going

Your invoice shows the total. It won’t show which task or job used it.

Check three places:

  1. Your coding agent. On a subscription you run out of usage and context, not money. Most agents have a command that shows what’s loaded and how much you’ve used.
  2. Anything automated. Cron jobs, CI bots, Slack bots, scripts hitting the API. Nobody watches these, so this is where surprise costs come from.
  3. Your product. If users trigger AI features, track cost per feature and per user. Track cost next to whether the task worked. Cutting tokens by 30% means nothing if the agent now fails twice as often. Failed runs and retry loops are usually the biggest waste.

Keep AGENTS.md short

AGENTS.md, CLAUDE.md, GEMINI.md, Cursor rules: it’s loaded on every run, so every line costs you every time.

Keep:

  • Things the agent would find slowly, like custom scripts or which test command is the real one

  • Things it can’t find in the code, like “we’re moving off library X, don’t add new usages”

  • Traps it keeps falling into that only show up in CI or prod Remove:

  • Anything your linter already enforces

  • Things every model does anyway, like “write tests”

  • Anything one ls or grep answers

  • Docs meant for humans

Check what your MCP servers cost

Every connected tool adds its name, description, and schema to the context. Some official MCP servers have close to a hundred tools, which is tens of thousands of tokens before you type anything. Look at your agent’s context view to see it.

  • Only connect the servers a project needs.
  • Use a CLI when there’s a good one (gh, aws, gcloud, kubectl). The agent runs one command instead of loading every tool. If you build MCP servers, don’t make every endpoint its own tool. Fewer tools, short descriptions, small schemas.

Stop feeding it junk

If one of 800 tests fails, don’t let the agent run all 800 after every change. Run the one test and stop at the first failure:

Terminal window
npx vitest run src/utils/date.test.ts -t "parses ISO dates" --bail=1

Jest, pytest, and Go have the same options. For full runs, save the log to disk and only give the agent the failures:

scripts/test-brief.sh
#!/usr/bin/env bash
LOG=.agent/last-test.log
mkdir -p .agent
npx vitest run "$@" --reporter=dot > "$LOG" 2>&1
STATUS=$?
if [ $STATUS -ne 0 ]; then
  grep -n -A 25 "FAIL" "$LOG" | head -n 80
  echo "--- full log: $LOG ---"
fi
exit $STATUS

Output tokens cost several times more than input with almost every provider. Don’t let the agent rewrite a 600 line file to change 3 lines, narrate each step, or write long reviews when “pass” is enough.

Limit retries. Each attempt carries more context than the last, so it costs more. After 3 failed attempts on the same error, have the agent write down what it tried and stop.

Understand caching

Providers cache the start of your prompt. When the next request starts with the same content, that part is often 50 to 90% cheaper.

So starting a fresh session to save tokens can cost more, because the cache has to be built again. Some providers also charge to write to the cache. Anthropic charges 1.25x normal input for a 5 minute cache and 2x for a 1 hour cache, then 0.1x on each reuse. The 5 minute cache pays off after one reuse, the 1 hour cache after two.

  • The cache matches from the top: tools, then system prompt, then messages. A change near the top breaks everything after it.
  • Put stable content first and changing content last. No timestamps or user IDs in the system prompt.
  • Don’t add tools or edit instructions mid-session.
  • Caches are per model. A fallback to another model starts from zero.
  • Sub-agents build their own cache, so don’t use them for small jobs.
  • Check cached tokens in your usage data. If it’s zero where it shouldn’t be, something is breaking the cache.

Pick models by cost per task

If a regex, SQL query, linter, or script can do it, don’t use a model.

Otherwise, compare models on what it costs to finish a task, not the price per token. A cheaper model that needs more turns and retries can cost about the same.

  • Small models for short, simple jobs: titles, classification, extracting fields, summarizing logs, searching code.
  • Frontier models for hard bugs, changes across many files, and planning.
  • Another provider when it fits the job better, like a larger context window or image and video input.

Keep memory small

Working memory is for the current session and can be dropped when it ends. Long-term memory is saved and only loaded when relevant.

Only save something long term if a future run will act on it. Give it a clear key, a date, and an instruction:

key: flaky-test:checkout-timeout
date: 2026-10-02
note: checkout.spec.ts times out on CI only, caused by the payment mock.
      If it fails again, rerun once before investigating.

A memory named note-1 with a paragraph of context makes the agent read all of it to decide if it applies.

When not to bother

Don’t optimize single words in prompts. Optimize what runs often and costs a lot. A job that runs hundreds of times a day is worth fixing. One that runs weekly for a few cents isn’t.

Don’t optimize something you’re still building. It will change.

On a flat-rate plan, your limit is context and usage caps, not money. Focus on what loads every session: your instructions file, MCP servers, and memory.

Start by opening the transcript of your last long agent session and see what you’re paying for.