![[Summer Vacation Free Research Relay] I Tried Measuring Token Consumption for Each Claude Code Instruction](https://devio2024-media.developers.io/image/upload/f_auto,q_auto,w_3840/v1784567573/user-gen-eyecatch/qmdvtfr8ilwg15cqafca.jpg)
[Summer Vacation Free Research Relay] I Tried Measuring Token Consumption for Each Claude Code Instruction
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 an entry for "Summer Vacation Independent Research Relay" - 1st Entry, a voluntary initiative by Classmethod members.
This blog relay is a project by members who regularly follow cloud and AI, aiming to output not just "tried it" but also "built it" and "researched/studied it".
We hope this will not only provide new insights but also contribute ideas to the growth of our company and community, so we appreciate your readership.
Let's get right into it. Today's article is: "Measuring Token Consumption per Claude Code Instruction".
We frequently receive questions from customers considering Claude Enterprise or Claude API adoption, asking "How much does it cost to work with Claude Code?"
Without knowing the cost for specific operations like "asking for an English translation" or "requesting a code review," it's hard to get budget approval, right?
So this time, I actually sent various instructions to Claude Code and measured token consumption and costs by type of operation. I hope this serves as a useful reference for adoption decisions.
Testing Environment
For this test, we used Claude Enterprise with auto mode enabled.
Measuring in a Vanilla State
Claude Code normally auto-loads ~/.claude/CLAUDE.md, rules/, and memory/ files and appends them to the system prompt. Since these make comparisons difficult, measurements were taken in a near-empty configuration state (vanilla environment).
# Temporarily back up configuration files
mv ~/.claude/CLAUDE.md ~/.claude/CLAUDE.md.bak
mv ~/.claude/rules ~/.claude/rules.bak
I deleted and disabled unused skill groups from /plugin and /skills.
You can check the amount of context loaded at that point (session startup) with /context.
❯ /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 proceeded with this state.
Thinking Budget (Effort)
At the time of writing, the thinking budget can be set to Low, Medium, High, xHigh, or Max.
Unless otherwise noted, this entry proceeds with High.
The following blog post explains Effort clearly.
Model & Pricing
The latest pricing for Anthropic models can be confirmed below.
Models and pricing used for measurements (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 (pricing until 2026/8/31) |
$2.00 | $10.00 | $2.50 | $4.00 | $0.20 |
| Claude Sonnet 5 (pricing from 2026/9/1) |
$3.00 | $15.00 | $3.75 | $6.00 | $0.30 |
Checking Token Consumption
Disabling Prompt Caching
Unless otherwise noted in this entry, prompt caching is disabled. (To prevent variations in testing time from affecting results.)
I created a folder and placed the following settings only in .claude/settings.local.json within that folder.
{
"env": {
"DISABLE_PROMPT_CACHING": "1"
}
}
Checking Token Counts 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 as possible with high reliability, so I chose to extract 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.

Manual aggregation is possible, but since the volume seemed like it would grow, I created a script this time. Feel free to reference it if you're doing similar measurements! ↓
Cost Calculation Formula
Note that with the above logs, you won't get an accurate cost unless you add up all four token types. 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
I'll present the measurement results for each model. I'll include the prompts used, but I'll omit the responses received to avoid going off on tangents...!
When Claude asked for interactive responses, I always chose Claude's recommended options.
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 using 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 wasn't as large as I expected, but Sonnet is indeed cheaper. I think Sonnet is sufficient for simple code generation.
3. Code Generation (Large)
Please write a Python class that can upload files to S3, download, list, and delete. Please 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 |
※ Run twice because multiple files were needed for a later step
4. File Read + Analysis
@s3_client.py Please identify the problems in this code and provide improvement suggestions
(Target file: the approximately 150-line Python script 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. Please provide 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 Opus appeared to do a more decisive code review, while Sonnet's messages felt more exploratory.
Out of curiosity, I also had Fable try it, but for this codebase, it didn't produce feedback significant enough to justify the 5-7x cost. (This is about 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 gave additional supplementary information below, which is why its output was longer.
"Amazon S3 が、未完了のマルチパートアップロードの自動削除に対応しました。"
As a supplement, here are some alternative translations with slightly different nuances.
- More literal: "Amazon S3 は、未完了のマルチパートアップロードの自動削除をサポートするようになりました。"
- More natural expression: "Amazon S3 で、未完了のマルチパートアップロードを自動削除できるようになりました。"
Terminology note: "incomplete multipart uploads" refers to uploads that were interrupted or failed midway through a multipart upload and were left uncompleted. Since leaving these behind incurs storage charges, the automatic deletion feature is useful for cost optimization.
✻ Cooked for 10s
I also tried Haiku 4.5 out of curiosity, but since the tokenizer specs changed before version 4.7, the token counts don't seem to be reliable as a reference. However, for English text of this length, I felt that Haiku was sufficient.
7. Summary & Translation (Long Document)
Please summarize and translate the following AWS official 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 close to the catalog spec (2.6x).
I usually ask Sonnet for research-type tasks, but Opus does seem to be at a disadvantage when comparing purely on cost-performance.
8. Image Read + Description
[Screenshot attached]
Please describe this AWS architecture diagram
I borrowed an architecture diagram from a previously written article.

(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 images are converted to tokens, so higher resolution tends to increase token consumption. From Opus 4.7 onwards, high-resolution input is supported, and a single image can use up to ~4,784 tokens (up to 2576px on the long side).
If high-resolution processing is not required, resizing images before sending them can help keep costs down.
9. CSV Analysis
[CSV file attached]
Please analyze the attached AWS usage fees (CSV, 100 rows) and summarize the trends and notable points
| input | output | cost | |
|---|---|---|---|
| Sonnet 5.0 | 337,513 | 10,157 | 0.7766 |
| Opus 4.8 | 112,826 | 4,775 | 0.6835 |
For the first time, the costs were reversed. However, my subjective impression was that Sonnet 5's answer quality was more to my liking.
Opus asked "Shall I investigate this additionally?", but Sonnet proactively investigated that part as well, which left a good impression. (This is purely a personal impression though...)
10. Slide Structure Proposal
Please create a slide structure proposal in marp for a management proposal document (10 slides) for new Claude Enterprise adoption. Target: 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 felt like they could be usable with some human fleshing-out.
11. Email Draft Creation
Please write an apology email to a business partner regarding 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 difference in either cost or response quality. Response speed was about 20 seconds for both, and it seems model selection may not be necessary for templated email drafts.
12. Web Search (Deep Research)
Please research and summarize the IT challenges facing the department store industry in 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 with Dynamic Workflow for both models.
Since each task consumes tokens, the token volume is incomparably larger than the previous tests.
(Even with credits, I honestly didn't expect it to cost this much — to my manager who might be reading this, I'm sorry...)

Analysis 1. Cost Differences by Effort Setting
Claude Code has an effort (reasoning depth) setting, and the higher it is, the more thinking tokens (Thinking) are used, and costs increase. The values are 5 levels: low / medium / high / xhigh / max.
There are multiple ways to configure it, as shown below.
# Flag at session startup
claude --effort high
# Environment variable
export CLAUDE_CODE_EFFORT_LEVEL=high
# Switch during session
/effort high
You can also persist it with the effortLevel key in settings.json (you can specify low / medium / high / xhigh)
Let's take "10. Slide Structure Proposal" as an example where thinking depth would likely have an impact, and check how much the token count differs when adjusting thinking with Sonnet.
Please create a slide structure proposal in marp for a management proposal document (10 slides) for new Claude Enterprise adoption. Target: 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, slow | 1.7012 |
| max | 3,596,002 | 14,146 | Quite good proposals, slow | 7.3335 |
Between medium and high, the difference seemed to be mainly whether tables were used or not, with little difference in content quality.
For xhigh and max, the Web Search tool was used to check the latest information even without user instructions, giving the impression of "working hard and thinking carefully." (Though it's only natural that it thinks more carefully when the thinking budget is increased...)
In this test, the full power of max was hard to demonstrate, but it seemed like the presentation was richer than xhigh.
Analysis 2. Non-Determinism of AI Responses
"Would token counts be identical if the same task were given after a session reset?" is something everyone might wonder at some point, but since responses can vary greatly depending on the ambiguity of the instruction, the answer appears to be no, they would not be identical.
(In this round, I was giving the same instructions across multiple sessions, which led to many filename conflicts and multiple do-overs...)
However, as shown in the results table for "3. Code Generation (Large)", when the answer converges to a certain degree, token consumption (cost) doesn't seem to vary greatly between sessions.
Analysis 3. Use Cases by Role & Monthly Cost Estimates
While this varies considerably by individual, I simulated actual work scenarios and calculated sample expected costs per day.
(Unit: USD)
Engineer
- Code generation & review: 20 times/day
- Document generation: 5 times/day
- Debugging assistance: 10 times/day
- Web search & research: 5 times/day
| Per instance (avg) | Per day | Per month (20 working 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 structure: 3 times/day
- Competitive & market research: 5 times/day
- Meeting minutes summarization: 5 times/day
| Per instance (avg) | Per day | Per month (20 working 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 & verification: 10 times/day
- Translation: 5 times/day
- CSV aggregation & analysis: 5 times/day
- Internal FAQ responses: 10 times/day
| Per instance (avg) | Per day | Per month (20 working days) | |
|---|---|---|---|
| Sonnet 5.0 | 0.22 | 6.63 | 132.54 |
| Opus 4.8 | 0.27 | 8.13 | 162.62 |
Summary
I felt that Sonnet wins for simple questions and translations. In many cases, the cost per request stays below a few tens of cents, and quality is unlikely to be a problem.
Also, what drives up costs is overwhelmingly output rather than input — the longer the response generated, the more costs skyrocket (output unit price is 5x that of input).
Rather than generating rich visual files from the start, there seems to be room for optimization, such as using markdown as an intermediary and only converting necessary parts to HTML.
For Claude Enterprise adoption, I felt the most cost-effective approach is to start with a PoC using Sonnet 5, measure token consumption, and only switch to Fable or Opus for areas where quality is insufficient.
For use cases where model performance really matters (code review, design, complex analysis), starting with Fable/Opus from the beginning is also fine. Though that's the tricky judgment to make.
I hope this entry helps someone.
That's a wrap on the 1st entry of the "Summer Vacation Independent Research Relay": "Measuring Token Consumption per Claude Code Instruction."
Next up is becominn's "Story of Trying AWS WAF Operations Using Claude". Stay tuned!!
This has been Arahira from the Cloud Business Division, Professional Services Department!
References
