Your Claude bill is mostly input tokens, not output. The API is stateless, so every turn you resend the full conversation history: the system prompt, the tool definitions, the docs you pasted in, and every prior message. On a long agent loop or a Claude Code session, that resent context piles up fast, and you pay for it on every single request. Output is the small side of the invoice.
So the levers that actually move your bill are the ones that shrink what you send, cut the per-token rate, or stop you from resending dead context. This guide walks through the concrete ones, first-party first, then a third-party proxy (pxpipe) that takes a different angle, and finally where a mock API fits while you’re still building.
If you want the pricing fundamentals first (how the meter works, what a token is, how caching and batching are billed), our Claude API cost explainer covers that ground. This post stays focused on cutting the bill, so we won’t restate pricing theory at length.
Lever 1: Prompt caching
Prompt caching is the highest-return change for most agent workloads. You mark a stable prefix (system prompt, tool definitions, long reference docs) as cacheable, and Claude stores it. On the next request that starts with the same bytes, you read from the cache instead of paying full input price to reprocess it.
The economics are strong. Cache reads cost about 0.1x the base input rate, so you save up to ~90% on the cached portion. Cache writes cost more than a normal input token: 1.25x for the 5-minute TTL, or 2x for the 1-hour TTL. That write premium is why caching pays off only when you reuse the prefix. Break-even is roughly 2 requests for the 5-minute cache and about 3 for the 1-hour cache. If a prefix gets hit once and thrown away, caching costs you money; if it gets hit dozens of times, it’s close to free after the first write.
The catch is that caching is a prefix match at the byte level. Any change inside the cached region invalidates it and forces a fresh, full-price write. The usual culprit is a variable that sneaks into the “stable” part: a timestamp in the system prompt, a session ID, a request counter, a reordered tool list. It looks stable to you and reads as new bytes to the cache.
Verify caching is actually working. Read usage.cache_read_input_tokens on your responses. Across repeated requests that share a prefix, that number should be large and non-zero. If it’s stuck at zero, something in your prefix is changing on every call, and you’re paying full price while believing you’re cached. For the mechanics of what caches and why, see what prompt caching is and how it works.
Lever 2: Right-size the model
The single most common overspend is running a bigger model than the task needs. Claude gives you a clear price ladder, and routing by task instead of defaulting to one model is often the biggest line-item drop you’ll get.
Here’s the current per-1M-token pricing:
| Model | Model ID | Input | Output | Context window |
|---|---|---|---|---|
| Fable 5 | claude-fable-5 |
$10 | $50 | 1M |
| Opus 4.8 | claude-opus-4-8 |
$5 | $25 | 1M |
| Sonnet 5 | claude-sonnet-5 |
$3 ($2 intro) | $15 ($10 intro) | 1M |
| Haiku 4.5 | claude-haiku-4-5 |
$1 | $5 | 200K |
A few things to read off that table. Fable 5 costs 2x Opus 4.8 on both input and output, which makes it the most expensive widely-released model. Opus 4.8 carries a full 1M-token context window with no long-context premium, so you don’t pay extra for feeding it a big codebase. Sonnet 5 runs at an introductory $2/$10 through 2026-08-31, then moves to $3/$15. Haiku 4.5 is the floor at $1/$5, with a smaller 200K window.
Match the model to the job:
- Fable 5 for the hardest long-horizon reasoning where the extra capability actually changes the outcome. Defaulting to Fable when Opus would have done the job is the most common way teams double their bill for no reason.
- Opus 4.8 for most agentic and coding work. It’s the sensible default for Claude Code and tool-heavy loops.
- Sonnet 5 for high-volume production traffic where you need good quality at a lower rate.
- Haiku 4.5 for simple or speed-critical tasks: classification, extraction, routing, short replies.
One billing detail on Fable 5: if a safety classifier refuses a request, the beta fallbacks parameter can reroute that turn to Opus 4.8, and the rerouted turn bills at Opus rates. That’s usually a discount, not a surprise charge, but it’s worth knowing your Fable traffic can show Opus-priced lines.
For deeper cost breakdowns on the two expensive tiers, see Opus 4.8 pricing, Fable 5 pricing, and the head-to-head on Fable 5 vs Opus 4.8 for when the 2x is worth it. If you want to try the top tiers at low or no cost while you evaluate, we cover using Opus 4.8 for free and calling the Fable 5 API directly.
Lever 3: Batch API (50% off)
If your work doesn’t need an answer in real time, the Batch API cuts every token in half. You send jobs to /v1/messages/batches, they run asynchronously, and you get results back. Most batches finish within an hour; the hard ceiling is 24 hours. The 50% discount applies to all token usage on the batch, input and output.
The fit is narrow but valuable. Batch is for work you can wait on:
- Running evals across a test set.
- Bulk classification or extraction over a backlog.
- Backfilling summaries, tags, or embeddings-adjacent metadata for existing records.
- Any large offline job where a few minutes of latency costs you nothing.
If half your Claude spend is nightly processing that you’re currently running through the synchronous endpoint, moving it to batch is a direct 50% cut on that half with no quality change. It’s the cheapest win on this list to reason about, because the only tradeoff is latency you weren’t using anyway.
Lever 4: Tune effort, max_tokens, and count_tokens
Three settings control how much a single request can spend, and setting them deliberately keeps costs from drifting up.
Effort. The output_config.effort parameter takes low, medium, high, xhigh, or max. It governs how much the model thinks before it answers, and thinking tokens are billed. Lower effort means fewer thinking and output tokens. Plenty of tasks that get run at high out of habit produce the same answer at medium or low for less money. Test a step or two down and check whether quality holds.
max_tokens. This is a hard ceiling on output. It won’t lower the cost of a response that was going to be short, but it caps the runaway case: a model that decides to emit a 4,000-token essay when you wanted a JSON object. Set it to a sane bound for the task so a single verbose response can’t blow up a line item.
count_tokens. Estimate cost before you send. The count_tokens endpoint tells you exactly how many input tokens a request will bill, using Claude’s own tokenizer. Do not use tiktoken for this. Tiktoken is OpenAI’s tokenizer and undercounts Claude by roughly 15 to 20%, so budgeting off it means your real bill runs meaningfully higher than your estimate. If you’re running near a per-request budget, count_tokens is how you catch an oversized prompt before it costs you.
Lever 5: Trim the context you resend
Because the API is stateless, a long agent loop resends its entire history every turn, and most of that history is dead weight by turn 30: tool outputs you’ve already acted on, exploration you’ve moved past, files you read once. You keep paying full input price to resend all of it.
Two server-side features prune it for you:
- Context editing (
clear_tool_uses_20250919) drops stale tool results from the context that gets resent, so old tool calls stop billing on every subsequent turn. - Compaction (
compact_20260112) summarizes older history into a shorter form, so a long conversation stops carrying its full raw transcript forward.
Both run server-side, which means you don’t have to hand-roll a summarizer or manually slice message arrays. For long-running Claude Code sessions specifically, this is the same pressure behind hitting context limits mid-task; our guide on the Claude Code token window and resets covers how that plays out in the editor. The billing takeaway is simple: stop paying to resend context the model no longer needs.
Going further: render context as images with pxpipe
The first-party levers all shrink or re-rate the tokens you send. pxpipe attacks the same input-token cost from a different direction: it renders bulky, stable context as images so it tokenizes cheaper.
What it is. pxpipe is a local proxy (MIT-licensed, written in TypeScript) that sits between your client and the Anthropic API. You point ANTHROPIC_BASE_URL at it, and it inspects each request on its way out.
How it cuts cost. Dense text is expensive per token. pxpipe rewrites the bulky, stable parts of a request (system prompt, tool docs, older history) into compact PNG images before the request leaves your machine. Dense content runs about 3.1 characters per image-token versus roughly 1 character per text-token, so imaging that content can cut its input tokens by a large margin. The project reports a ~48k-character system-prompt-plus-tool-docs example landing at about 2.7k image tokens versus about 25k as text. Critically, it uses profitability gates: it only images content where the token math actually wins, and sparse prose passes through as text unchanged.
Install and run. Two commands:
npx pxpipe-proxy
That starts the proxy on 127.0.0.1:47821. Then point Claude Code at it:
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude
Model support. By default pxpipe images requests for claude-fable-5 and GPT 5.6. Opus 4.7/4.8 and GPT 5.5 are opt-in, because the project reports they read imaged context measurably worse. You enable them with the PXPIPE_MODELS env var (or the dashboard at the proxy URL). Everything else passes through unchanged.
Reported savings. These are the project’s own reported and benchmark numbers, not figures we’ve independently verified. pxpipe reports a production snapshot of 59% savings, a $100 bill dropping to about $41 across 13,709 requests, and a SWE-bench Lite pilot at -65% request size. Treat them as vendor benchmarks and confirm on your own traffic.
The honest tradeoffs. Imaging is not free money.
- It interacts with prompt caching. Imaging changes the request bytes, and your cached prefix is a byte match. Caching and imaging both target the same input-token cost, so they can pull against each other: the change that makes imaging win can be the change that alters your cached region. Which approach saves more depends on your specific prefix and reuse pattern. Measure both on your own workload rather than assuming they stack.
- The model reads imaged context through vision. The project itself flags that dense strings (long hex IDs, exact tokens) can be misread, and misses are silent, not errors. Verify output quality on your own tasks before trusting the savings.
- It’s a third-party proxy handling your traffic. It runs locally, which is good, but it still sits in your request path. Evaluate it against your own security posture before putting production traffic through it.
pxpipe is worth testing if your context is dominated by large, stable, dense blocks and you can validate quality. For sparse or highly cache-friendly workloads, the first-party levers may already capture most of the win.
Cut the dev and test tokens you waste while building
None of the above changes the fact that you burn real, paid tokens while you’re still building the integration. Apidog won’t lower your production Claude bill, and it doesn’t pretend to. Where it saves you money is the dev and test loop.
Every time you run your integration against the live Anthropic API during development, each iteration costs real tokens: the failed run, the retry, the CI job that fires on every push. That spend adds up while you’re iterating on prompt shape, parsing logic, and error handling, none of which needs a real model to validate.
Mock the Anthropic response in Apidog instead. Define the request and response contract for the Claude endpoint you’re calling, then point your tests and CI at the mock. Your loop runs against a deterministic fake that returns the shape you expect, and you spend zero tokens validating plumbing. You can also design and document that request/response contract in the same place, so your team agrees on the interface before anyone spends a token on it. This cuts the dev and test tokens you waste while building, not your production bill. That’s the honest scope.
Stack the levers
These aren’t either/or. The biggest cuts come from stacking:
- Cache the stable prefix. System prompt, tools, docs. Verify
cache_read_input_tokensis non-zero. - Route by task. Opus 4.8 as the default, Fable 5 only where it changes the outcome, Sonnet 5 for volume, Haiku 4.5 for simple work.
- Batch the offline work. Anything non-latency-sensitive goes to
/v1/messages/batchesfor 50% off. - Bound each request. Right-size
effort, capmax_tokens, estimate withcount_tokens. - Trim the resend. Context editing and compaction so long loops stop paying for dead history.
- Test whether imaging helps. If your context is large and dense, benchmark pxpipe against caching on your own prefix.
- Mock while building. Keep the dev and test loop off the paid meter.
Start with caching and model routing, since those two usually account for most of the drop. Measure after each change, because the only number that matters is your actual invoice.
FAQ
Do input or output tokens cost more on my Claude bill? Per token, output costs more than input across every model. But for agent and coding workloads, the input side is usually the larger bill, because the stateless API makes you resend the full conversation history every turn. That’s why the biggest levers target input tokens.
Is prompt caching or Batch API the bigger saving? It depends on your workload. Caching saves up to ~90% on the repeated prefix of interactive traffic, so it wins for chat and agent loops that reuse a system prompt. Batch cuts 50% off everything but only for work you can run asynchronously. Many teams use both: cache the interactive path, batch the offline jobs.
Should I default everything to Fable 5? No. Fable 5 costs 2x Opus 4.8 and is meant for the hardest long-horizon reasoning. For most agentic and coding work, Opus 4.8 gives you the same result at half the input and output rate. Defaulting to Fable when Opus would do is the most common overspend.
Does pxpipe stack with prompt caching? Not cleanly. Imaging changes the request bytes, and caching is a byte-level prefix match, so the two target the same input-token cost and can pull against each other. Test both on your actual prefix and measure which saves more; don’t assume they add up.
Does Apidog reduce my production Claude costs? No. Apidog mocks the Anthropic API so your tests and CI hit a fake instead of burning paid tokens while you build. That cuts your dev and test spend, not your production bill.
