All payments made in the preview are in test mode. Read more
claudetokenoptimization.com

Audit

What a Claude Token Audit Finds: 8 Patterns That Waste Money

Most Claude bills are not mysterious — they are eight recurring waste patterns stacked on top of each other. Recognise two in your own setup, and you already know why the rest are worth handing off.

Figures last verified 2026-09-19

This page is part of the Audit hub, which covers the whole topic end to end.

Last updated 19 September 2026. This page is a pattern catalog, not a pricing table. Where list prices appear for orientation, they were checked against Anthropic’s published Claude API pricing on that date (Haiku 4.5 $1/$5, Sonnet 5 $2/$10, Sonnet 4.5/4.6 $3/$15, Opus 4.5+ / Opus 5 $5/$25 per MTok in/out). Confirm live on Anthropic’s docs. [VERIFY: 2026-09-19]

Not affiliated with Anthropic. Claude Token Optimization is an independent site and audit service. Claude® and related product names are trademarks of Anthropic PBC. Plan prices, model rates, and usage limits change; always confirm on Anthropic’s own docs. [VERIFY: 2026-09-19]

Teams ask for an audit when the invoice jumped, the seat bar keeps hitting red, or nobody can explain which workflow owns the spend. The findings below are what that review usually surfaces — not every team has all eight, but almost every team has two or more.

Use this page as a self-check. If you recognise a pattern, start with the linked playbooks for cutting token usage, Claude Code token habits, and the LLM cost framework. If you recognise several and still cannot prioritise, that is exactly when a written review pays for itself — soft CTA at the bottom, no price on this page.

The eight patterns at a glance

#PatternQuick recognition sign
1Bloated standing contextSystem/project text re-sent every turn
2No prompt cachingStable prefixes never marked cacheable
3Always-Opus / no routingOne model for every task class
4Claude Code stuffingFull files, fat sessions, rare /clear
5Retry & rewrite loopsLong wrong answers, then rewrite-everything
6Wrong meter (seats vs API)Dark seats, shared logins, confused bills
7No attributionUnlabeled keys, invoice surprise
8$/MTok obsessionCheapest rate card, expensive finished tasks
Recognition signs only — detail for each pattern follows.

1. Bloated standing context

Recognition: Project instructions, custom system prompts, style guides, and “always include” policy blocks that grow every quarter and never get a delete pass. Every turn re-pays the whole stack.

Why it burns: Input tokens on standing text are charged on every request (unless you cache them — pattern 2). A 4k–8k instruction blob on a high-volume workflow is a silent tax that looks like “normal usage.”

Fix direction: Cut ruthlessly, split rare rules into on-demand tools, and measure prefix length before you argue about models. Pair with the standing-context tactics in eleven ways to cut token usage.

2. No prompt caching on stable prefixes

Recognition: The same long system prompt or tool schema ships on every call, and nobody has ever checked Anthropic’s prompt caching docs — or caching was tried once, misconfigured, and abandoned.

Why it burns: Stable prefixes are the highest-leverage place to stop re-paying full input rates. Teams that skip caching often discover they were rebuying the same thousands of tokens hundreds of times a day.

Fix direction: Identify what is truly stable across calls, structure the prompt so the cacheable block is contiguous, and verify cache hits in usage metrics before declaring victory. Caching a moving target wastes the feature; caching a clean prefix is Stage 3 Reduce work in the cost framework.

3. Always-Opus / no model routing

Recognition: Default model is Opus (or the newest flagship) for classify, extract, draft, and deep reasoning alike. No written task-class map. Downgrades feel “risky,” so nobody tries.

Why it burns: At list price, Opus input/output is several times Haiku for the same token counts ($5/$25 vs $1/$5 per MTok). [VERIFY: 2026-09-19] Routing every triage call to Opus is expensive productivity theatre.

Fix direction: Write defaults by task class with a quality check and an escalate path. Routing without shortening standing context still burns the fat prefix — do both. Model choice is Reduce; attribution proves it stuck.

4. Context stuffing in Claude Code

Recognition: Sessions that never use /clear, agents that pull entire files “just in case,” and long-running coding threads where the window is mostly stale diffs and failed attempts.

Why it burns: Coding agents multiply tokens: tool results, file reads, and retries all re-enter context. A fat session is not diligence — it is a growing meter.

Fix direction: Prefer targeted reads, clear between unrelated tasks, and treat session hygiene as a cost control. Practical habits live on how to reduce token usage in Claude Code.

5. Chat retry loops and verbose habits

Recognition: Prompts that ask for exhaustive answers, then a second prompt that says “rewrite the whole thing.” Long wrong drafts kept in the thread. Users who treat the chat as a scratchpad instead of a finished-task machine.

Why it burns: Output tokens are often the expensive half of the rate card, and retries duplicate both input history and failed output. Verbosity without a success criterion is how one “quick ask” becomes three paid essays.

Fix direction: Define done-when up front, ask for diffs not rewrites, and start a clean thread when the old one is mostly noise. See the retry and brevity tactics in cut token usage.

6. Wrong meter: seats vs API confused

Recognition: Finance tracks seat subscriptions while builders burn API keys (or the reverse). Shared logins hide who is driving usage. Dark or unused seats sit on the bill while a few power users hit limits.

Why it burns: Optimising the wrong meter produces false savings. Cancelling an unused seat while an unlabeled API key runs overnight does not reduce cost — it reduces visibility.

Fix direction: Inventory every meter (seat plans, Console/API, Claude Code paths), map owners, and kill shared credentials. Attribution (pattern 7) is how you keep the map honest inside the Measure → Attribute loop.

7. No attribution — unlabeled keys and invoice surprise

Recognition: API keys named “test” or after a laptop. No project tags. The monthly invoice is a lump sum. One person discovers they were 60% of spend only after a finance escalation.

Why it burns: Without attribution you cannot Reduce safely — every cut feels political. Teams argue about models while unlabeled traffic keeps growing.

Fix direction: Tag keys and workloads, set alert thresholds, and review attributed spend weekly. Unlabeled spend is a finding, not a rounding error. The framework page spells the loop; this pattern is why audits start with a token map.

8. Optimising $/MTok instead of cost-per-finished-task

Recognition: Spreadsheets that crown the cheapest list price the winner. Migrations to a “cheaper” model that need more retries, longer prompts, or human cleanup — so total cost per shipped task goes up.

Why it burns: Rate cards measure tokens; businesses pay for finished work. A model that is 2× per MTok can be cheaper per task if it succeeds in one pass. The reverse is also true: Haiku on the wrong task can be expensive when it loops.

Fix direction: Score cost per finished task on a held-out set, then route. Pair rate-card literacy with task economics — the same philosophy as Stage 3 Reduce in the LLM cost framework.

How these stack (why “we already tried caching” is not enough)

Patterns compound. Always-Opus on a bloated uncached prefix inside a stuffed Claude Code session with unlabeled keys is not eight separate problems — it is one bill. Fixing only the model while leaving standing context fat moves the needle less than a sequenced pass: Measure what is actually charged, Attribute it, Reduce the biggest drivers, Monitor so the win sticks.

That sequence is why an audit is not a lecture about prompt tips. It is a prioritised change list tied to your paste: which patterns are present, which burn the most, and what to do Monday.

What the audit delivers

A written Claude token audit on this site is built for teams that recognise themselves above and want a second pair of eyes. Typical deliverable:

  • Token map — where tokens go across standing context, tools, and task classes.
  • Waste drivers — which of the eight patterns (and any cousins) show up in your paste, ranked by likely impact.
  • Change list — concrete edits and process changes, not generic slogans.
  • Monday plan — a short ordered set of first moves so the report does not die in a Slack thread.

See a sample of the written report shape if you want the format before you paste anything. Retention and handling notes live on privacy & retention.

Scope and turnaround

Soft path: paste the prompts / workflows you want reviewed → receive a written report → typical turnaround is about two business days after a complete paste. Exact scope (what to include, what stays out) is confirmed on the audit page so checkout and delivery stay clear.

This findings page deliberately does not show a dollar amount. Price is only rendered on the audit checkout page so it cannot drift across the site. When you are ready: start the Claude token audit — paste, written report, Monday plan.

FAQ

Is this the same as reading a blog checklist?

No. The eight patterns are the checklist. An audit applies them to your paste and ranks what to fix first. Self-serve the playbooks when one pattern dominates; hand off when several stack.

Do I need API access logs?

Helpful but not always required. Strong audits often start from prompts, project instructions, and a description of volume. Logs improve attribution; paste quality improves the change list.

Will you tell us to switch models?

Only when the evidence says so. Many findings are standing context, caching, and session hygiene — cheaper than a model migration and faster to ship.

Next steps

  1. Skim the eight patterns and mark which ones you already recognise.
  2. If one pattern dominates, open the matching playbook: cut usage, Claude Code, or the framework.
  3. If two or more stack and prioritisation is unclear, paste for a written audit.

Waste patterns are boring once named. Naming them on your stack — and deciding what ships Monday — is the part most teams would rather not do alone.

Keep reading