Claude Opus 5.5 has become cheaper.
But if you’re really using:
Claude Code
for work,
just knowing:
“Input costs $4 per million tokens”
isn’t very helpful.
Because the total cost of a coding task
is not determined only by:
token unit price.
It also depends on:
how many rounds Claude runs?
how much old context is read from the cache?
how much Thinking/output is generated?
are tasks restarted due to errors?
So today we won’t teach you
how to calculate lots of tokens.
Just one action:
After completing a real task, enter /usage.
Then only check three things:
Cache.
Output.
Turns.
Step 1: Check /usage Only When the Task Is Actually Done
For example, you just had Claude Code:
fix a bug.
modify three files.
run tests.
confirm functionality works.
At this point, don’t just see:
“Done”
and close the terminal.
Instead, enter:
/usage
Claude’s official documentation also mentions:
/cost
can show usage info for similar sessions.
You’ll see:
Input.
Output.
Prompt cache.
and estimated cost.
If you’re on a subscription plan,
the dollar amounts mainly reflect list prices as references,
not necessarily your actual bill.
So don’t obsess over:
“Did this cost $0.83 or $0.91?”
The important thing is:
which metric seems abnormal.
First Check: Look at Cache
Each round of work in Claude Code,
doesn’t only read:
“the latest single input you entered.”
It also needs to carry over:
conversation history.
project instructions.
tool definitions.
files viewed.
previous tool results.
to continue working.
This previously viewed content,
if reused from:
prompt cache,
is much cheaper than reprocessing as fresh input.
For Opus 5.5,
cache reads currently cost only:
5% of fresh input price.
So in long sessions,
cache share is very important.
Low Cache in Long Sessions? Find Out Why First
Claude recommends,
if a long session’s cache share is low,
check whether:
the session was idle for too long?
a model was switched?
effort/thinking settings were changed?
a new MCP server was connected midway?
Because these situations may cause:
previous cache to be discarded and rebuilt.
The first simple question is:
“I’ve been working on the same task, why isn’t old context heavily reused?”
But High Cache Doesn’t Guarantee the Task Is Cheap
This is important.
Suppose you have a high cache hit,
but Claude:
ran 40 turns back and forth,
and each turn brings in a large cached context.
One turn is cheap.
But 40 turns add up
and that’s still a cost.
So cache is just:
The first check.
Next, you must look at:
Output
and
Turns.
Second Check: Is Output Proportional to Task Size?
Opus 5.5’s output costs,
per million tokens,
$20.
While cache reads,
per million tokens,
$0.20.
That is,
an output token costs about
100 times
more than a cache read token.
Claude’s
Thinking
is also counted in output tokens.
So if you only requested:
“Rename this variable in five files.”
but the model generates:
a lot of reasoning.
many explanations.
constantly searching for information.
replanning repeatedly.
Then it’s worth checking whether:
effort is set too high.
Small Edits But Lots of Output? Don’t Blame Model Pricing First
For example, if the task is simply:
renaming an old API field name
to a new name.
The pattern is clear.
There’s no architectural decision-making.
No complex debugging.
For such mechanical tasks,
Claude recommends considering:
lower effort.
Because what’s needed isn’t for the model to think for ten minutes,
but to
apply known rules to finish the edits.
If such small tasks generate lots of output,
first ask:
“Am I making it think too much?”
But Don’t Lower Effort Just to Cut Output in Complex Tasks
On the other hand,
if a bug involves
API,
frontend,
database,
and tests,
and you harshly lower effort,
Claude might fix only the backend on the first try,
then discover frontend issues on the second,
and find test issues on the third.
What you hoped to save on thinking
could end up being entirely lost to
retries.
Anthropic specifically warns:
The cost of one retry may be
higher than some saved thinking effort upfront.
So don’t mechanically reduce effort just because output is high.
First check the third metric:
Turns.
Third Check: Why Is Total Input Much Larger Than Conversation Size?
This is one of the most commonly misunderstood points about Claude Code.
Suppose you see the current conversation is about:
120,000 tokens.
You might think:
“Then the session only processed 120,000 tokens max.”
Not true.
Because each turn
re-carries the previous context.
Anthropic gives an example:
The session ultimately has:
120,000 tokens,
but ran:
40 turns,
and total input sums to:
2.8 million tokens.
So in /usage,
if total input is much larger than your current conversation size,
it usually means:
the task ran for many rounds.
Many Turns? Look Back to See Where It’s Stuck
Don’t immediately think:
“The model is too expensive.”
Check the session transcripts first.
Common scenarios include:
reading a file,
↓
make changes,
↓
run tests,
↓
tests fail,
↓
read another file,
↓
make changes,
↓
run tests again,
↓
then discover a third caller.
This is a
loop.
And each loop
re-incorporates prior context.
Anthropic has a memorable phrase:
The cheapest turn is the turn that never needs to happen.
How to Reduce Unnecessary Turns?
One practical method isn’t to:
switch to a cheaper model.
But rather to:
enable Claude to validate itself.
For instance, tell it upfront:
after edits, run:
tests,
build,
lint,
API validations.
If the first round fails,
the model can:
see the failure immediately,
fix it right away,
instead of:
it saying “done,”
you manually test,
find errors,
restart a session,
and input the full context again.
The real savings may not be:
single tokens,
but the
entire second round of work.
So Today’s Simple “Three-Metric Check”
No Excel required.
No dashboard necessary.
After each completed real task,
enter:
/usage
and ask three questions.
Cache
In long sessions, is old context heavily reused?
If low,
look for long idles,
model or effort switches,
or other cache-rebuilding causes.
Output
Is the reasoning and text generated proportional to task difficulty?
If it’s a mechanical task but output is very high,
try lowering effort next time.
Turns
Is total input much higher than conversation size?
If so,
look for where in the session the model is repeatedly reading,
modifying,
and verifying.
A Simple Example
Today’s task:
“Rename the API customer_name to client_name.”
Finally,
all tests pass.
Then look at /usage.
Scenario A
High cache.
Low output.
Finished in 5 turns.
That’s normal.
No need to complicate workflow for
“saving $0.10.”
Scenario B
High cache,
but 25 turns.
The problem is probably not cache,
but Claude discovering dependencies in batches.
Next time, ask it
to find all call sites first,
then modify all at once.
Scenario C
Only a few files,
not many turns,
but output is very high.
Then check if
effort is beyond what the task needs.
Scenario D
Long session,
low cache share.
Then check:
whether there was a long pause,
model switch,
effort change,
or other settings causing prompt reset.
Don’t Immediately Switch to a Smaller Model When Costs Are High
This is also today’s key point.
If the problem is actually:
too many turns,
switching to a cheaper model might still result in many turns,
or even more if it lacks capability.
If the problem is:
cache not effective,
changing models won’t fix
workflow interruptions.
If the problem is:
too much output,
just adjusting effort might suffice.
So:
find the cost source first,
then decide whether to change models.
This Is Different from the August “20-Task Model Testing”
If you’re deciding whether to switch from expensive models to cheaper ones in bulk,
we previously taught you to use the same set of 20 representative cases to compare
cost,
accuracy,
and modification time.
That’s
model selection.
Today’s tip addresses something else:
you’re already using Claude Code,
and one real session looks unusually costly.
You must first answer:
“Where exactly is the cost burning?”
So it’s not about
model A/B testing first,
but about diagnosing your workflow.
When Is /usage Most Valuable? When Checking the Same Type of Work Repeatedly
For example, if you weekly:
fix bugs,
add small features,
update APIs,
review PRs,
don’t compare
a 5-minute rename
with
a 3-hour migration.
The most valuable approach is:
after completing the same type of task,
quickly check:
cache,
output,
turns.
Gradually, you’ll understand
what’s normal for these tasks,
and when suddenly costs spike,
you’ll know it’s worth investigating.
AI Cost Isn’t About Minimizing Numbers
The real goal isn’t to
minimize the numbers shown in /usage.
But rather to:
complete work correctly with reasonable cost.
A $1 session
that’s fully done,
with all tests passed,
requiring only 5 minutes of review,
may be more cost-effective than
a $0.50 session
that was done incorrectly once,
rerun,
and required 30 minutes of manual fixing.
So in the end,
it’s about
final usable output,
not
who uses the fewest tokens.
Today, Just Remember This Action
After Claude Code truly completes a task,
enter:
/usage
Then check:
Cache: Did old context get effectively reused?
Output: Was too much spent on thinking or generation?
Turns: Is the workflow stuck in loops?
First find out:
where your money is going.
Next time you’ll know whether to:
lower effort,
add tests,
reduce repeated turns,
maintain cache,
or really switch models.
The easiest mistake in AI cost optimization
is to:
change models just by seeing token price without analyzing workflow.
If you want to know which step in your workflow is best for AI assistance, comment “Workflow.”
Today, improve a little with AI.
Learn one AI tip a day.
Save a little time every day.
Improve your skills day by day.
SasaDaily, growing with you.
Recommended Reading
AI Q&A｜09/02/2026: Does High Claude Prompt Cache Hit Mean This AI Task Is Definitely Cheaper?
