How to use AI with fewer tokens: 9 techniques to cut cost without cutting quality

The cost of using AI through an API, and the usage limits in apps, are both counted in tokens, yet most teams only notice they are spending tokens when the bill arrives or when they hit a limit.

This article gathers 9 token-optimization techniques confirmed by Anthropic's official documentation, with a step-by-step cost example to show how much each technique saves and what risk comes with it.

Prices and parameters come from the Pricing, Prompt caching, Effort, Token counting and Context editing documents of the Claude Platform, checked as of October 20, 2026; many other providers have similar mechanisms, but names, prices and conditions differ, so each provider's documentation needs to be checked.

Click Star already has an article on using GPT well and one analyzing the Claude models; this one focuses on tokens.

Key points

• A token is the unit for billing and limits, and the token count of the same content depends on the model, the language and the content type: Anthropic states that the text tokenizer from Claude 4.7 produces about 30% more tokens for the same text, so count your own Vietnamese text instead of assuming.
• Measure before optimizing: Anthropic's token counting is free and returns the input token count before you send the request; the API response also reports the tokens read from the cache, written to the cache and not in the cache.
• The technique with the biggest effect is usually choosing the right model: at the same moment, the input price is US$4 for Opus 5.5, US$2 for Sonnet 5.5 and US$0.10 for Haiku 5.5 per million tokens, a gap of up to 40 times between the two ends.
• Prompt caching cuts the price of repeated input to 5% of the standard price on Opus 5.5 and Sonnet 5.5 (10% on Haiku 5.5, 2.5% on Fable 5.1), and the Batch API cuts 50% for work that is not urgent; according to Anthropic's pricing page, these two discounts stack.
• Once caching is in use, output becomes the biggest cost (the output price is 5 times the input price on all 4 current models), so limiting output length and choosing the right effort level matter as much as trimming input.
• In Click Star's illustrative example (a support bot handling 100,000 requests a month), caching cuts list-price cost by about 68% on Sonnet 5.5, and moving to Haiku 5.5 with caching cuts it further, provided quality still passes on your own test set.

What a token is and why bills differ from expectations

A token is a piece of text (a word, part of a word, punctuation) that the model processes; each request is billed by the number of input tokens and the number of output tokens, at different unit prices.

Input includes everything you send: system instructions, tool definitions, attached documents, the whole conversation history and the new question. Output includes the answer and, for a model with thinking, the thinking too. Anthropic states that thinking counts toward the max_tokens limit and toward output tokens.

There are 4 sources of surprise. First, the conversation history is resent on every turn, so cost grows with the length of the conversation. Second, output costs 5 times input on the current Claude models. Third, thinking is also output tokens. Fourth, images and PDFs also convert to tokens and can be large.

Step 0: measure before optimizing

• Count tokens before sending. The token counting endpoint accepts the same input as a message-creation request (system instructions, tools, images, PDFs as base64) and returns the input token count; it is an estimate that can differ slightly, it is free, and it has a requests-per-minute limit by usage tier (5,000 at the Start tier). It does not use caching and does not support some server-side tools.
• Read the usage fields of the response. Total input tokens equal the tokens read from cache plus the tokens written to cache plus the input tokens not in the cache; if both cache fields are 0, the prompt was not cached (usually because it was shorter than the minimum).
• Measure cost per passing task, not just per request. A cheap model that must redo a task 3 times can cost more than a mid-priced one.

Technique 1. Choose the right model for each job

The current input prices per million tokens: Fable 5.1 is US$10, Opus 5.5 is US$4, Sonnet 5.5 is US$2, Haiku 5.5 is US$0.10 (up to 100,000 tokens per prompt). Anthropic suggests Haiku for simple tasks, Sonnet for most production workloads and Opus for the most complex reasoning.

How to do it: run the same set of real task samples on 2 to 3 models and pick the cheapest model that meets the criteria for each kind of work; Click Star describes a 14-day trial process in its article analyzing the Claude models.

Technique 2. Lower the effort level for simple work

The effort parameter controls how many tokens the model spends on the whole response: explanations, tool-call parameters and thinking. There are 5 levels: low, medium, high, xhigh, max. The default is medium on Opus 5.5 and Haiku 5.5, and high on the other models.

Anthropic describes low as the most efficient level, suited to simple tasks that need speed and low cost, and with tools, lower levels tend to combine several operations into fewer calls and drop preambles.

Note that effort is a behavioral signal, not a hard token budget; and on Opus 5, Anthropic says changing effort does not reliably shorten the visible response, so a short answer must be requested in the prompt.

Technique 3. Limit output: length and format

Because output costs 5 times input, each unnecessarily long answer costs more than each unnecessary attachment.

Request a specific length and format (for example "at most 120 words, 3 bullet points"), ask it to skip restating the question and the opening pleasantries, and use a structured format (compact JSON) when the result goes into another system.

Set max_tokens as a hard limit but with room for both thinking and the answer, because if thinking uses up the limit, the answer gets cut off; Anthropic advises setting a large value at higher effort levels.

Technique 4. Prompt caching for repeated parts

Caching reuses the start of a prompt that has already been processed. There are 2 ways to turn it on: automatic (one cache_control field at the top level, with the cache point moving along as the conversation grows) and manual (cache_control on individual blocks, up to 4 points).

Pricing relative to the standard input price: a 5-minute cache write is 1.25 times, a 1-hour cache write is 2 times, and a cache read is 0.1 times (0.05 times on Opus 5.5 and Sonnet 5.5, 0.025 times on Fable 5.1). That means the 5-minute cache pays off after 1 read, and the 1-hour cache after 2 reads.

Conditions for it to work. The prompt must reach the minimum length (512 tokens on all 4 current models, 1,024 to 4,096 on older models); the prefix must match byte for byte, and the cache point must sit on the last block that stays unchanged between requests.

The most common mistake is putting the cache point on a block that holds a timestamp or per-request content: then every request writes the cache and never reads it. The default lifetime is 5 minutes and is refreshed at no cost each time it is used; use 1 hour when the gap between uses is between 5 minutes and 1 hour.

Sending parallel requests before the first one completes will not hit the cache, because the cache entry only exists after the first response begins.

Changes that lose the cache: changing tool definitions (which invalidates every level), changing the system prompt, changing the speed (fast or standard), changing the thinking parameters or the request-level effort. So keep tools and system instructions stable, put the fixed part first and the changing part last.

Technique 5. The Batch API for work that is not urgent

The Batch API processes asynchronously at a 50% discount on both input and output, suited to work such as bulk classification, summarizing a document archive or scoring old data. According to Anthropic's pricing page, this discount stacks with the caching multipliers. Limits: it cannot be used with fast mode; and not every job can wait.

Technique 6. Manage context in long conversations

In agents or long conversations, context grows on every turn. Anthropic recommends server-side compaction for long conversations, and also offers context editing: clearing old tool results when the prompt passes a threshold (default 100,000 tokens, keeping the 3 most recent tool uses) and clearing old thinking blocks.

This mechanism is in beta, needs a beta header, and clearing tool results invalidates the cache from the cleared part, so a minimum clear amount should be set to make it worthwhile.

For the SDK-side summarization approach, Anthropic cites a typical result of going from about 100,000 tokens to 2,000 to 3,000 tokens, but that approach is marked as discouraged in some SDKs.

Technique 7. Keep tool definitions and tool results compact

Tool definitions are input tokens on every request, and changing them invalidates the cache at every level. Include only the tools needed for the task, write short and precise descriptions, and have the tool return the needed data instead of the whole record. Long tool results are the most common source of context bloat in agents.

Technique 8. Clean the input

Do not paste a whole document when only a part is needed: extract the relevant passage (possibly through a search step first), drop repetition, signatures, long paths and surplus data. Images and PDFs convert to many tokens; send only the pages or image regions needed.

For Vietnamese, count test samples because tokens depend on language and content type, and Anthropic says to recount when changing models.

Technique 9. Split the work, do not cram one giant prompt

Splitting a complex task into small steps lets a cheap model handle simple steps (classification, extraction) and a stronger model handle hard ones. This is the way to use Haiku as the first layer and move up to Sonnet or Opus only when needed. In exchange you need to design the flow and check for errors at each step.

Cost example: a customer support bot

This is an illustrative example by Click Star based on list prices, not a measurement. Assumptions: 100,000 requests a month; each request has 6,000 fixed tokens (system instructions and knowledge), 300 tokens of new question and 400 tokens of answer; prompts under 100,000 tokens; with caching, assume 1% of requests must rewrite the cache and 99% read it.

• Sonnet 5.5, no cache: input 630 million tokens times US$2 is US$1,260; output 40 million tokens times US$10 is US$400; total about US$1,660.
• Sonnet 5.5, with cache: cache write 6 million tokens times US$2.50 is US$15; cache read 594 million tokens times US$0.10 is US$59.40; new input 30 million tokens times US$2 is US$60; output US$400; total about US$534, down about 68%.
• Sonnet 5.5, with cache, answers cut from 400 to 250 tokens: output falls to US$250; total about US$384, a further drop of about 28%.
• Haiku 5.5, no cache: input 630 million tokens times US$0.10 is US$63; output 40 million tokens times US$0.50 is US$20; total about US$83.
• Haiku 5.5, with cache: about US$30 (write US$0.75, read US$5.94, new input US$3, output US$20).

Two observations. Caching sharply cuts the input side but output is still US$400, so after caching, answer length is the biggest lever. And switching model only makes sense when your test set shows quality still passes; a drop from US$534 to US$30 means nothing if the cheap model answers wrongly more often.

Click Star's view. A sensible order of priority for most teams: measure, then choose the model and the output length, then caching, then batch and context management. Each technique added makes the system more complex, so add one only when measurement shows the cost is significant.

For users of chat apps

This part is general principle, not based on the features of any one app, because each app's features and limits differ and change often.

• Open a new conversation for each different task instead of stretching one conversation, because a long history is resent on every turn.
• Paste exactly the needed part of a document instead of the whole file, and say which part to read.
• Ask for the answer's format and length from the start to avoid having to ask again.
• Write one stable block of instructions for repeated work (role, tone, format) and reuse it instead of rewriting each time.
• Verify results cheaply: ask it to list sources or points to check instead of asking it to rewrite the whole piece.

A 14-day plan

1. Days 1 to 3: measure the current state with real tokens and cost per passing task for the 3 most expensive jobs.
2. Days 4 to 6: rewrite prompts to have the fixed part first, limit output length and set the effort level explicitly.
3. Days 7 to 9: turn on caching, measure the hit rate through the usage fields and fix the cache point if the rate is low.
4. Days 10 to 12: test a smaller model for simple work on your own sample set; move non-urgent work to the Batch API.
5. Days 13 to 14: set cost alerts and put tokens and cost per passing task into the weekly report.

Metrics to track

• Cost per passing task (not just per request).
• The share of input tokens read from cache out of all input tokens.
• Average output tokens per request and the share of answers cut off by max_tokens.
• The share of tasks that need redoing or manual fixing after lowering the model or effort level.
• Average input tokens by conversation length.
• The share of work moved to the Batch API.

Common mistakes

1. Optimizing input and forgetting output, when after caching output is the largest cost.
2. Putting the cache point on a block with a timestamp or per-request content so it never hits the cache.
3. Constantly changing tool definitions or system instructions and losing the cache.
4. Lowering the model or effort level without a quality test set.
5. Setting max_tokens too low when using thinking, so the answer gets cut off.
6. Using one long conversation for many different tasks.
7. Assuming Vietnamese token counts equal English token counts instead of testing.
8. Sending whole documents or images when only a part is needed.