[Summer Vacation Free Research Relay] I Measured Token Consumption for Each Claude Code Instruction

[Summer Vacation Free Research Relay] I Measured Token Consumption for Each Claude Code Instruction

I wanted to get a feel for how much cost each process incurs, in order to find clues for reducing tokens.
2026.07.21

This page has been translated by machine translation. View original

Hello, I'm Arahira (@eiraces) from the Cloud Business Division, Professional Services Department.

This article is Entry #1 of the 'Summer Vacation Independent Research Relay' by Classmethod volunteers.
This blog relay series is an initiative by members who regularly follow cloud and AI, aiming to output not just "tried it" but also "built it" and "researched/investigated it."

We hope this will not only provide new insights but also contribute ideas to our company and community development, so we appreciate your company.
Let's get right into it. This article is: 'Measuring Token Consumption Per Instruction in Claude Code'.

We often receive questions from customers considering Claude Enterprise or Claude API adoption: "How much will it cost if we use Claude Code?"
Without knowing the cost for each specific operation — like "What if I ask it to translate English?" or "What if I have it review code?" — it's hard to get budget approval, right?

So this time, we actually submitted various instructions to Claude Code and measured token consumption and costs by type of operation. We hope this serves as a useful reference for your adoption decisions.

Test Environment

This time, verification was performed in a Claude Enterprise environment with auto mode enabled.

Measuring in Vanilla State

Claude Code normally auto-loads ~/.claude/CLAUDE.md, rules/, and memory/ files, adding them to the system prompt. Since these make comparisons difficult, measurements were taken in a state with almost no configuration files (vanilla environment).

# Temporarily back up configuration files
mv ~/.claude/CLAUDE.md ~/.claude/CLAUDE.md.bak
mv ~/.claude/rules ~/.claude/rules.bak

From /plugin and /skills, I deleted and disabled skill groups that hadn't been used recently.
With /context, you can check the amount of context loaded at that point (session startup).

❯ /context
  ⎿  Context Usage
     ⛁ ⛁ ⛁ ⛁ ⛀ ⛀ ⛀ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   Opus 4.8
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   claude-opus-4-8
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   24.8k/1m tokens (2%)
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   Estimated usage by category
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ System prompt: 4.1k tokens (0.4%)
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ System tools: 18.4k tokens (1.8%)
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ Skills: 2.3k tokens (0.2%)
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ Messages: 36 tokens (0.0%)
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛶ Free space: 975.2k (97.5%)

     MCP tools · /mcp (loaded on-demand)
     └ 65 tools · 0 tokens

     Skills · /skills
     └ 19 skills · 2.3k tokens

Before cleanup it was around 100.0k, but I was able to reduce it to 24.8k. Further reduction seemed difficult, so we proceed from this state.

Thinking Budget (Effort)

At the time of writing, the thinking budget can be selected from Low, Medium, High, xHigh, and Max.

In this entry, unless otherwise noted, we'll proceed with High.
The following blog is easy to understand regarding Effort.

https://dev.classmethod.jp/articles/claude-opus-4-8-effort-and-context-usage/

Models and Pricing

The latest pricing for Anthropic models can be found here.

https://platform.claude.com/docs/ja/about-claude/pricing

Models used for measurement and pricing (as of July 20, 2026)

Model input ($/MTok) output ($/MTok) 5min cache creation ($/MTok) 1hour cache creation ($/MTok) cache read ($/MTok)
Claude Fable 5 $10.00 $50.00 $12.50 $20.00 $1.00
Claude Opus 4.8 $5.00 $25.00 $6.25 $10.00 $0.50
Claude Sonnet 5 $2.00 $10.00 $2.50 $4.00 $0.20

Checking Token Consumption

Disabling Prompt Caching

In this entry, unless otherwise noted, prompt caching is disabled. (To prevent variation in verification time from affecting results.)
I created a folder and added the following settings to .claude/settings.local.json only within that folder.

{
  "env": {
    "DISABLE_PROMPT_CACHING": "1"
  }
}

https://platform.claude.com/docs/ja/about-claude/pricing#prompt-caching

Checking Token Count from JSONL Logs

There are several ways to check token counts, and OpenTelemetry or the /usage command are commonly used.
This time, I wanted to check as quickly and reliably as possible, so I decided to retrieve token counts from session logs.

Claude Code session logs are saved in JSONL format at ~/.claude/projects/<project>/<sessionID>.jsonl. Each message contains a usage field, from which token counts can be extracted.

ScreenShot 2026-07-20 at 13.24.22

Manual counting is possible, but since the volume was likely to increase, I created a script this time. For anyone doing similar measurements, feel free to reference it! ↓

https://github.com/hepts/arap-claude-token-usage-script

Cost Calculation Formula

Note that to get an accurate cost from the above logs, all four token types must be summed. In particular, be careful not to forget cache creation (cache_creation_input_tokens).

Calculation example

def cost_usd(usage, price):
    return (
        usage.get("input_tokens", 0)               * price["input"]
        + usage.get("output_tokens", 0)            * price["output"]
        + usage.get("cache_creation_input_tokens", 0) * price["cache_write"]
        + usage.get("cache_read_input_tokens", 0)  * price["cache_read"]
    ) / 1_000_000

# Opus 4.8
OPUS_48 = {"input": 5.0, "output": 25.0, "cache_write": 6.25, "cache_read": 0.5}

Measurement Results

The measurement results for each model are listed below. The prompts used are included, but the responses received are omitted to avoid going off on tangents...!
When Claude asked for interactive responses, I always chose the Claude-recommended option.

1. Simple Question

Please explain the difference between Python list comprehensions and map
input output Cost
Sonnet 5.0 43,144 1,145 0.0977
Opus 4.8 30,466 974 0.1767

There is no internet access, and each model responds based on its own knowledge.

2. Code Generation (Small)

Please write a Python function that reads a CSV file and returns the average value of a specific column
input output Cost
Sonnet 5.0 43,139 978 0.0961
Opus 4.8 30,613 917 0.1760

The cost difference is smaller than expected, but Sonnet is certainly cheaper. I think Sonnet is sufficient for simple code generation.

3. Code Generation (Large)

Please write a Python class that supports file upload, download, listing, and deletion to S3. Include error handling and logging as well
input output Cost
Sonnet 5.0 132,059 2,501 0.2891
Opus 4.8 63,482 2,848 0.3886
Opus 4.8 (※) 63,603 2,827 0.3887

※ Executed twice because multiple files were needed in a later step

4. File Reading + Analysis

@s3_client.py Please identify the problems with this code and suggest improvements

(Target file: Python script of approximately 150 lines created in step 3)

input output Cost
Sonnet 5.0 45,671 4,207 0.1334
Opus 4.8 33,135 1,958 0.2146

5. GitHub Access + Code Review

Please review the code in the following repository. We'd appreciate feedback from the perspectives of bugs, security, and readability
https://github.com/hepts/arap-claude-token-usage-script
input output Cost
Sonnet 5.0 607,153 13,012 1.3444
Opus 4.8 268,963 10,404 1.6049
Fable 5.0 885,797 12,675 9.4917

The cost difference between Sonnet and Opus turned out to be quite small (1.19x). Looking at the results, the number of system messages was higher for Sonnet (11) compared to Opus (7), and while Opus performed a fairly decisive code review, Sonnet's messages felt more exploratory.

Also, I had Fable try it out of curiosity, but for this codebase, the issues identified didn't seem worth spending 5-7x the cost. (This is a matter of using the right tool for the right job — it doesn't mean Fable is bad.)

6. Translation (Short Text)

Please translate the following English text into Japanese:
"Amazon S3 now supports automatic deletion of incomplete multipart uploads."
input output Cost
Sonnet 5.0 43,146 34 0.0866
Opus 4.8 30,621 279 0.1601
Haiku 4.5 31,878 439 0.0341

Sonnet provided only the translated text, while Opus included supplementary information as shown below, resulting in more output.

"Amazon S3 が、未完了のマルチパートアップロードの自動削除に対応しました。"

補足として、少しニュアンスを変えた訳も挙げておきます。

- 直訳寄り:「Amazon S3 は、未完了のマルチパートアップロードの自動削除をサポートするようになりました。」
- 自然な表現:「Amazon S3 で、未完了のマルチパートアップロードを自動削除できるようになりました。」

用語の補足: "incomplete multipart uploads" は、マルチパートアップロードの途中で中断・失敗し、完了(complete)されずに残っているアップロードのことを指します。これらは放置するとストレージ料金が発生するため、自動削除機能はコスト最適化に役立ちます。

✻ Cooked for 10s

I also tried Haiku 4.5, but since tokenizer specifications changed from version 4.7 onwards, the token counts aren't a useful reference. However, I felt that Haiku is sufficient for English text of this length.

7. Summary & Translation (Long Document)

Please summarize and translate the following official AWS documentation (English, approximately 4,000 words) into Japanese
https://docs.aws.amazon.com/aws-backup/latest/devguide/lag-vault-primary-backup.html
input output Cost
Sonnet 5.0 143,583 3,860 0.3258
Opus 4.8 105,220 13,066 0.8528

The cost difference came out to about the same as the catalog specs (2.6x).
I usually ask Sonnet for research-type tasks, and Opus may indeed be at a disadvantage when compared purely on cost-performance.

8. Image Input + Description

[Screenshot attached]
Please describe this AWS architecture diagram

I borrowed a configuration diagram from a previously written article.

https://dev.classmethod.jp/articles/dynamodb-cross-account-backup-to-lag-vault/

image

(Image size: approximately 70kB, 2000x1114px)

input output Cost
Sonnet 5.0 46,049 1,317 0.1053
Opus 4.8 33,525 1,199 0.1976

Note that since images are converted to tokens, higher resolution tends to increase token consumption. Starting from Opus 4.7, high-resolution input is supported and can use up to ~4,784 tokens per image (up to 2576px on the long side).

If you don't need to process high-definition images, resizing before sending can help reduce costs.

9. CSV Analysis

[CSV file attached]
Please analyze the attached AWS usage costs (CSV, 100 rows) and summarize trends and points of concern
input output Cost
Sonnet 5.0 337,513 10,157 0.7766
Opus 4.8 112,826 4,775 0.6835

The costs finally reversed. However, my subjective impression was that Sonnet 5's answer quality was more to my liking.
While Opus asked "Would you like me to investigate more on this as well?", Sonnet proactively researched that part as well, which left a good impression. (This is purely a personal impression...)

10. Slide Structure Proposal

Please create a slide structure proposal in marp for a management proposal document (10 slides) for introducing Claude Enterprise. Target audience: IT department of a manufacturing company
input output Cost
Sonnet 5.0 90,049 3,971 0.2198
Opus 4.8 64,754 4,271 0.4305

Sonnet's slides were quite sparse with thin content, while Opus's slides had material that could be usable once fleshed out by a human.

11. Email Draft Creation

Please write an apology email to a business partner for a system outage. Outage duration: 2 hours, Impact: inability to download some files
input output Cost
Sonnet 5.0 87,814 1,214 0.1878
Opus 4.8 30,621 882 0.1752

There was no significant difference in either cost or response quality. Response time was around 20 seconds for both, suggesting that model selection may not be necessary for templated email drafts.

12. Web Search (Deep Research)

Please research and compile the IT challenges in the department store industry for the second half of 2026
File name: 20260721-retail-1.md
input output Cost
Sonnet 5.0 15,808,371 26,504 $31.88
Opus 4.8 8,970,723 13,760 $45.20

Deep Research ran using Dynamic Workflow for both models.
Since each task consumes tokens, the token volume is incomparable to the previous verifications.
(Even with credits available, I honestly didn't expect it to cost this much — my apologies to any manager reading this...)

ScreenShot 2026-07-21 at 01.15.16


Analysis 1. Cost Differences by Effort Setting

Claude Code has an effort (depth of reasoning) setting, where higher values increase thinking tokens and costs accordingly. The values are in 5 levels: low / medium / high / xhigh / max.

There are multiple ways to configure it:

# Flag at session startup
claude --effort high

# Environment variable
export CLAUDE_CODE_EFFORT_LEVEL=high

# Switch during session
/effort high

It can also be persisted with the effortLevel key in settings.json (you can specify low / medium / high / xhigh)

Using "10. Slide Structure Proposal" — which seems likely to be affected by depth of thinking — as an example, let's check how much the token count varies when adjusting thinking in Sonnet.

Please create a slide structure proposal in marp for a management proposal document (10 slides) for introducing Claude Enterprise. Target audience: IT department of a manufacturing company
effort input output Perceived Quality Cost
low 212,441 3,686 Very sparse, fast 0.4617
medium 153,585 2,880 Sparse, somewhat fast 0.3360
high 90,049 3,971 Sparse 0.2198
xhigh 790,243 12,075 Quite good proposals, somewhat slow 1.7012
max 3,596,002 14,146 Quite good proposals, slow 7.3335

The difference between medium and high appeared to be mainly whether tables were used or not, with the content quality not looking much different.
xhigh and max used the Web Search tool to check for the latest information even without user instruction, giving the impression of "thinking and acting carefully." (Of course, it thinks more carefully because the thinking budget is increased...)

In this verification, the power of max was difficult to discern, but it seemed to have richer expressions than xhigh.


Analysis 2. Non-Determinism in AI Responses

"Will the token count be identical if the same task is run after resetting the session?" is something anyone might wonder at least once, but since the response can vary greatly depending on the ambiguity of the instruction, the answer appears to be: no, it will not be identical.
(Since I was giving the same instructions across multiple sessions this time, I had to redo things multiple times when file names kept colliding...)

However, as shown in the results table for "3. Code Generation (Large)," when the answer converges to some degree, I believe the token consumption (cost) doesn't change significantly between sessions.


Analysis 3. Monthly Cost Estimates by Role and Use Case

While this will vary considerably depending on the individual, I simulated actual work scenarios and calculated estimated daily costs as samples.
(Unit: US dollars)

Engineer

  • Code generation & review: 20 times/day
  • Document generation: 5 times/day
  • Debugging support: 10 times/day
  • Web search & research: 5 times/day
Per session (avg) Per day Per month (20 business days)
Sonnet 5.0 0.16 6.36 127.14
Opus 4.8 0.31 12.47 249.37

Sales

  • Email drafts & translation: 30 times/day
  • Proposals & slide structures: 3 times/day
  • Competitor & market research: 5 times/day
  • Meeting minutes summary: 5 times/day
Per session (avg) Per day Per month (20 business days)
Sonnet 5.0 0.19 8.03 160.67
Opus 4.8 0.35 14.85 296.98

Back Office (Accounting, HR, Legal, etc.)

  • Document checking & review: 10 times/day
  • Translation: 5 times/day
  • CSV aggregation & analysis: 5 times/day
  • Internal FAQ responses: 10 times/day
Per session (avg) Per day Per month (20 business days)
Sonnet 5.0 0.22 6.63 132.54
Opus 4.8 0.27 8.13 162.62

Summary

I felt that Sonnet has the edge for simple questions and translations. In many cases, costs stayed below a few tens of cents per session, and quality issues were rare.
Also, what drives up costs is overwhelmingly output rather than input — the longer the response generated, the higher the cost climbs (output unit price is 5x that of input).
Rather than generating richly formatted files from the start, there seem to be optimization opportunities such as using markdown as an intermediary and converting only what's needed to HTML.

For Claude Enterprise adoption, I felt that the most cost-effective approach is to first do a PoC with Sonnet 5, measure token counts, and only switch to Fable or Opus for areas where quality is insufficient.
For use cases where model performance matters (code review, design, complex analysis), starting with Fable/Opus from the beginning is also fine. The tricky part is making that judgment call.

I hope this entry is helpful to someone.
That concludes Entry #1 of the 'Summer Vacation Independent Research Relay': 'Measuring Token Consumption Per Instruction in Claude Code.'

Next time, Becomin will be presenting "A Story About Trying Out AWS WAF Operations Using Claude." Stay tuned!!
This has been Arahira from the Cloud Business Division, Professional Services Department!

References

https://code.claude.com/docs/en/costs

https://code.claude.com/docs/en/model-config


Claudeならクラスメソッドにお任せください

クラスメソッドは、Anthropic社とリセラー契約を締結しています。各種製品ガイドから、業種別の活用法、フェーズごとのお悩み解決などサービス支援ページにまとめております。まずはご覧いただき、お気軽にご相談ください。

サービス詳細を見る

Share this article

AI白書