編碼智能體的 token 費用從何而來，以及降低成本的 7 個方法

Your coding agent answered a one-line question, and that request still carried the entire session's history. Nothing broke. Anthropic's docs say it plainly: a one-line question in a session that has been open all day still draws usage for the whole conversation.

That's the part of the bill that's easy to miss. This article shows where a coding agent's tokens actually go, then walks through seven levers to cut them, in the order that usually pays off first: measure, cache, scope, control output, route, batch, and budget.

Where the tokens go

Anthropic's Claude Code cost docs spell out the mechanics. Claude Code sends your full conversation with every request. Each time Claude uses a tool, it sends another request carrying that batch of tool results. So every new request re-sends the history that came before it. With prompt caching, that history is billed at the cheaper cached rate, but it's still billed.

The same page lists the usual reasons usage climbs in a long session:

• Long context. Every request carries everything that came before it.
• Cache misses. Your first message after a break longer than the cache lifetime reprocesses the full context.
• Background work. Scheduled tasks, subagents and agent teammates each send their own requests.
• Compaction. /compact reads the conversation it summarizes, so compacting a large context is itself a large request.

Output adds its own cost. On Anthropic's current price table, output tokens cost five times the base input rate for every model listed, and the cost docs note that extended thinking tokens are billed as output.

So the bill has three drivers: how much context each request carries, how often that context is re-sent at full price, and how much the model writes back. Each lever below targets one of them.

Lever 1: Measure before you change anything

You can't cut what you can't see. In Claude Code, run /usage. The Session block shows token usage by model, split into input, output, cache read and cache write. From v2.1.251, a Prompt cache (main) line adds the share of input tokens served from cache, the number of misses and, when Claude Code can tell, a likely cause.

On a Pro, Max, Team or Enterprise plan, the same screen attributes usage to skills, subagents, plugins and individual MCP servers, and recommends changes for anything behind 10% or more of recent usage. Run /context too, to see what fills the context window before you've typed anything.

If you call the API directly, the numbers are in every response. Anthropic returns cache_creation_input_tokens, cache_read_input_tokens and input_tokens in usage; OpenAI reports cached input under usage.input_tokens_details.cached_tokens. Log them per request, per feature, before you touch anything else.

Lever 2: Make caching actually hit

Prompt caching is the biggest lever when the same prefix is sent over and over, which is exactly what agents do. Per the Anthropic prompt caching docs, cache reads cost 0.1x the base input price (0.05x on Opus 5.5 and Sonnet 5.5), 5-minute cache writes cost 1.25x, and the default cache lives 5 minutes, refreshed for free each time it's used. On OpenAI, prompt caching is on by default for supported models.

Claude Code caches for you. If you build your own agent on the Anthropic API, put stable content first and mark the end of it:

import anthropic

client = anthropic.Anthropic()
repo_guide = open("docs/agent-context.md").read()  # large and stable
diff_text = open("change.diff").read()             # different every call

response = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=1024,
    system=[
        {"type": "text", "text": "You review pull requests for this repo."},
        {"type": "text", "text": repo_guide,
         "cache_control": {"type": "ephemeral"}},
    ],
    messages=[{"role": "user", "content": diff_text}],
)
print(response.usage)

Three traps from the docs break caching silently:

1. A breakpoint on content that changes. Put a timestamp or the user's message in the marked block and the prefix hash never matches, so you pay for a cache write on every request and never get a read.
2. Prompts below the minimum. Shorter prompts aren't cached and no error is returned. If cache_creation_input_tokens and cache_read_input_tokens are both 0, nothing was cached.
3. Changing tools mid-session. Modifying tool definitions invalidates the entire cache, because tools sit at the start of the prefix.

Lever 3: Scope the context

The cheapest token is the one you never send. The Claude Code cost docs list the habits that keep context small:

• /clear between unrelated tasks. Stale context is paid for on every later message. When you want a fresh start, /clear costs nothing; /compact is a large request.
• Keep CLAUDE.md short. It loads at every session start. The docs suggest under 200 lines and moving workflow-specific instructions into skills, which load only when invoked.
• Trim MCP servers. Disable servers you aren't using with /mcp. The docs add that CLI tools such as gh are still more context-efficient than MCP servers.
• Filter verbose output. A hook can return only the failing lines of a test run instead of the full log.
• Write specific prompts. "Improve this codebase" triggers broad scanning; "add input validation to the login function in auth.ts" doesn't.

Lever 4: Control output

Because output costs more per token, small changes here add up. For simple tasks, the docs suggest lowering the effort level with /effort, or disabling thinking in /config on models that allow it. On models with a fixed thinking budget, the MAX_THINKING_TOKENS environment variable lowers the budget; adaptive-reasoning models use effort levels instead.

On the API, set max_tokens to what the task needs, and ask for the format you'll actually use: a diff instead of a rewritten file, a list of findings instead of an essay.

Lever 5: Route each task to the right model

Not every step needs your strongest model. The cost docs say Sonnet handles most coding tasks well and costs less than Opus, which they reserve for complex architectural decisions and multi-step reasoning. For simple subagent tasks, they suggest model: haiku.

Per the subagents docs, a project subagent named Explore overrides the built-in one and keeps its own model field. Save this as .claude/agents/explore.md to run codebase exploration on a lower-cost model:

---
name: Explore
description: "Searches and reads the codebase to answer questions without making changes."
tools: Read, Grep, Glob
model: haiku
---

Find the files and symbols relevant to the question. Return paths,
line references and a short summary, not full file contents.

Route by task, not by habit: cheap models for search and summarizing, the big one for design decisions.

Lever 6: Batch what doesn't need an answer now

Some agent work isn't interactive: running an eval set, reviewing a backlog of files, generating docs overnight. The Message Batches API offers a 50% discount on all usage compared with standard prices. Most batches finish in under an hour, and results are available once every request completes or after 24 hours, whichever comes first. The docs also note that batch and caching discounts stack.

Lever 7: Set budgets that stop runs

Every lever above lowers the average cost. Budgets cap the worst case. For headless runs, Claude Code's CLI can stop once estimated spend reaches a limit:

claude -p --max-budget-usd 5.00 "Fix the failing tests in src/auth"

The flag works in print mode only and checks against Claude Code's own client-side estimate. Above that, the cost docs list workspace spend limits in the Claude Console and spend limits per organization, group or member on Team and Enterprise plans. If you use agent teams, watch them closely: the docs say they use about 7x more tokens than standard sessions when teammates run in plan mode, and each teammate keeps consuming tokens until it exits.

A 10-minute token bill checklist

1. Did you check /usage and /context (or the API usage fields) before changing anything?
2. Is your cache hit rate visible, and are misses explained?
3. Is the cache breakpoint on the last block that stays identical across requests?
4. Do you /clear between unrelated tasks?
5. Is CLAUDE.md under 200 lines, with workflows moved to skills?
6. Are unused MCP servers disabled?
7. Are effort, thinking and max_tokens matched to the task?
8. Do exploration and simple subagents run on a cheaper model?
9. Is non-urgent bulk work going through a batch API?
10. Does every headless or automated run have a spend cap?

The order matters. Measure first, then fix the levers that touch every request (caching and context), and only then tune the rest.

If you want the full playbook, I wrote LLM Cost Control: The Builder's Guide to Cutting Your Token Bill. It's a 40+ page PDF that covers the same seven levers in depth, how token billing works, prompt caching done right, a worked end-to-end example, a 30-day plan, emergency cost triage and a pre-launch checklist.

This article was written with the assistance of AI and reviewed by the author.