How Much Does Claude Code Actually Cost—and How Do You See Your Real Usage?

1. Conclusion-first zone: the price is not the same as your cost

“Claude Code cost” has two layers. The first is the metered value of the tokens your work consumes: input plus output, with repeated input often discounted heavily by prompt caching. The second is what cash actually leaves your account. If you use a subscription, that payment is a flat monthly fee rather than a separate charge for every token. The gap between metered compute and marginal cash is the whole story.

Current API prices are $5 input and $25 output per million tokens for Claude Opus 4.8, $3 and $15 for Claude Sonnet 4.6, and $1 and $5 for Claude Haiku 4.5. Cached input reads cost about 0.1× the normal input rate. That discount matters because coding agents repeatedly carry large contexts: instructions, repository state, tool results, and conversation history.

Real usage can also be much larger than a session counter suggests. One eleven-month local history contained 16,405 user utterances. Agentmole’s pilot deep-mine of that history used about 2.2 million tokens, equivalent to roughly $11 of mostly-input Opus 4.8 compute, while adding roughly $0 in marginal cash cost because it ran on the user’s existing subscription. That was the analysis run, not the user’s day-to-day coding total.

To answer “how much does Claude Code cost me?” for yourself, measure your own transcripts. Agentmole does that with one command, locally, and uploads nothing unless you choose to publish.

2. Quantified evidence zone: pricing, formulas, caching, and a real timeline

The cleanest way to understand Claude Code pricing is to keep several related quantities separate. A token total is a measurement of model activity. A metered API estimate assigns prices to that activity. A subscription payment is the amount you actually pay for access under a flat plan. They may describe the same work, but they are not interchangeable.

That distinction explains why two honest answers to “how much does Claude Code cost?” can sound contradictory. One developer may say that a long agent run represents meaningful API compute. Another may say the same run cost nothing extra because it occurred inside an already-paid subscription allowance. Both can be true. The useful question is not which answer wins; it is which ledger you are trying to inspect.

Current Claude API pricing anchors

The current verified API rates used throughout this guide are:

Model	Input price per 1M tokens	Output price per 1M tokens	Context window
Claude Opus 4.8 (`claude-opus-4-8`)	$5.00	$25.00	1M tokens
Claude Sonnet 4.6 (`claude-sonnet-4-6`)	$3.00	$15.00	1M tokens
Claude Haiku 4.5 (`claude-haiku-4-5`)	$1.00	$5.00	200K tokens

These are per-million-token API prices, not Claude Pro or Max subscription prices. Subscription pricing can change independently, and this article does not substitute an unverified plan figure. Check the vendor’s current pricing page for the exact flat-plan amount available to you, then compare that amount with the metered estimate calculated from your own usage.

The table also shows why “I used this many tokens” is not yet a dollar answer. Input and output have different rates. The model matters. Prompt caching can move a large part of input onto a much cheaper rate. Batch processing, where applicable to an API workflow, costs 50% of the standard price. A credible estimate therefore needs more than a grand total copied from a dashboard.

The basic token-to-dollar formula

Without caching or Batch, the basic estimate is:

cost ≈ (
  input_tokens × input_price_per_million
  + output_tokens × output_price_per_million
) / 1,000,000

For a mixed-model history, calculate each model separately and add the results:

total_metered_cost ≈ opus_cost + sonnet_cost + haiku_cost

The same principle applies if your history contains work from more than one interface or agent. Do not average unlike prices unless you know the token-weighted mix. Keep the usage attached to the model that produced it, apply that model’s input and output rates, and only then sum the dollar estimates.

The formula is intentionally simple, but its inputs need care:

input_tokens means newly billed, non-cached input at the base input rate.
output_tokens means tokens generated by the model at the output rate.
Cached input reads belong on the cache-read rate, approximately 0.1× the base input price.
Cache creation belongs on the applicable write rate: 1.25× base input for the five-minute time-to-live or 2× for the one-hour time-to-live.
Batch-eligible work uses 50% of the standard price rather than the standard price.

If all you possess is a combined token total, you can calculate a rough equivalent only by stating an assumption. The pilot’s roughly $11 figure does exactly that: it treats about 2.2 million tokens as mostly-input Opus 4.8 work. It is not pretending that an unknown input-output-cache split is known.

That practice is worth copying. An estimate with a visible assumption is useful. A more precise-looking number built on an invisible assumption is not.

A cache-aware formula

Prompt caching changes the input side of the calculation. A practical expanded formula is:

cost ≈ (
  uncached_input_tokens × input_price
  + cache_read_input_tokens × input_price × 0.1
  + five_minute_cache_write_tokens × input_price × 1.25
  + one_hour_cache_write_tokens × input_price × 2
  + output_tokens × output_price
) / 1,000,000

If the entire request is submitted through an eligible Batch API path, apply the verified 50% Batch rate to the relevant standard-price result:

batch_cost ≈ standard_cost × 0.5

This expanded version shows why a raw “input tokens” number can be misleading. Repeated context may dominate token volume while contributing only about one-tenth of the base input price on cache reads. Conversely, a workflow that keeps invalidating its cache may repeatedly pay uncached input or cache-write premiums even though the visible task feels repetitive.

The fields to inspect are usage.cache_read_input_tokens and cache_creation_input_tokens. The first tells you how much input was served from cache. The second identifies input used to establish cache entries. Together with uncached input and output, those fields let you replace a vague guess with a cost model that reflects what the API actually did.

Why prompt caching is central to agentic coding economics

A coding agent rarely receives only the developer’s latest sentence. It may also receive system instructions, project instructions, earlier conversation, selected files, tool definitions, tool outputs, repository summaries, and the state needed to continue a multi-step task. Much of that material can recur across requests.

This makes token volume and token price diverge. A large repeated context can produce an intimidating token count while costing far less than the same amount of fresh input, because a cache read is billed at approximately 0.1× the normal input rate. In plain terms, repeated cached context can receive up to roughly 90% savings compared with paying the base input price again.

But the discount is not automatic in the abstract. The request sequence must actually reuse cacheable prefixes, and your usage record must show cache reads. If prompts, system instructions, tool ordering, or other prefix content change unnecessarily, the cache may be less effective. That is why a cache-hit measurement belongs beside total tokens in any serious Claude Code cost report.

A high token count with a high cache-read share can be economical. A lower token count with poor cache reuse can cost more than expected. Looking at total tokens without cache behavior is like looking at the size of a grocery basket without checking which items were discounted.

Cache-write premiums and the break-even point

Caching has an upfront cost. A five-minute cache write is billed at 1.25× the normal input price. A one-hour cache write is billed at 2×. You pay that premium to make later reads much cheaper.

The verified break-even points are straightforward:

For the five-minute cache, the break-even arrives at the second request.
For the one-hour cache, the break-even arrives at the third request.

The arithmetic explains why. Let B be the base price of a particular block of input.

For the five-minute cache, writing once and reading once costs:

1.25B + 0.1B = 1.35B

Sending the same block twice without caching costs:

B + B = 2B

So reuse on the second request already makes the five-minute cache less expensive than paying the base price twice.

For the one-hour cache, writing once and reading once costs:

2B + 0.1B = 2.1B

That is slightly more than two uncached requests:

B + B = 2B

Add another cache read, however, and the cached sequence becomes:

2B + 0.1B + 0.1B = 2.2B

Three uncached requests cost:

B + B + B = 3B

That is the three-request break-even. The larger one-hour write premium needs more reuse before it wins, but the longer time-to-live can support workflows whose repeated requests are spread farther apart.

This is also why “turn caching on” is incomplete advice. You need to know which context is stable, how soon it is reused, and whether the resulting usage fields show enough cache reads to justify the write. The cost model is observable; it does not need to be a matter of intuition.

The subscription-versus-API comparison

A subscription and the API solve different billing problems.

The API exposes token-metered economics. More billable input, output, or cache creation produces more spend; cache reads and Batch can reduce that spend. This can be attractive when usage is light, sporadic, programmatically controlled, or easy to attribute to a project. It also makes the relationship between activity and bill explicit.

A subscription turns variable per-token spending into a fixed monthly amount under the plan’s current terms and limits. Once the plan is already paid for, an additional qualifying run may create approximately zero marginal cash charge even though it consumes model compute with a real API-equivalent value.

Neither model is universally cheaper. A light user may pay more for a flat plan than their metered API usage would have cost. A heavy user may receive far more metered-equivalent compute than the flat plan fee. The dividing line is personal because it depends on your actual model mix, input-output split, cache behavior, Batch eligibility, and usage volume.

The comparison therefore has to use the same period and the same scope:

estimated_API_cost_for_period
  = token-metered estimate for that period

subscription_cost_for_period
  = the current flat plan fee you actually pay for that period

Then compare the two:

if estimated_API_cost_for_period < subscription_cost_for_period:
    API is cheaper for the measured usage, before other plan considerations

if estimated_API_cost_for_period > subscription_cost_for_period:
    subscription is cheaper for the measured usage, subject to plan terms and limits

The formulas do not tell you which access method fits your workflow, but they remove the biggest source of confusion: guessing your usage. Use the exact subscription price shown on the vendor’s current pricing page, not a stale number from an article, social post, or cached answer.

Worked example: the Agentmole pilot deep-mine

The pilot provides a useful real-world contrast because its compute volume and payment context are both known.

Agentmole scanned an eleven-month local history and then ran a deep analysis over it. The deep-mine used about 2.2 million tokens with ten parallel sub-agents. Treating that usage as mostly-input Claude Opus 4.8 compute gives:

metered_equivalent ≈ 2.2M × $5 per 1M input tokens
metered_equivalent ≈ $11

That is the raw, mostly-input API-equivalent anchor. It is approximate because the summary does not claim a fully itemized input-output-cache split. If a substantial part had been output, the exact API bill would differ because Opus 4.8 output is $25 per million tokens. If a substantial part had been cache reads, the relevant input portion would be billed at about 0.1× the base input rate. The honest conclusion is therefore “about $11 of mostly-input Opus 4.8 compute,” not a fabricated cent-level invoice.

The actual marginal cash paid for that analysis run was approximately $0. It ran on the user’s existing subscription, so there was no separate token invoice added for the deep-mine. The fixed subscription payment already existed.

Both figures matter:

View of the pilot analysis	Approximate amount	What it means
Mostly-input Opus 4.8 metered equivalent	~$11	The API-price value of about 2.2M mostly-input tokens
Marginal cash under the existing subscription	~$0	Additional cash charged specifically for that analysis run

This does not mean the user’s entire eleven months of Claude Code work cost $11. The 2.2 million tokens describe the Agentmole analysis run over the history, not all tokens consumed while producing the underlying day-to-day coding conversations. Those are different workloads:

Day-to-day coding usage created the transcript corpus.
The Agentmole deep-mine read and analyzed that corpus.
The ~$11 estimate applies to the deep-mine’s mostly-input Opus 4.8 equivalent.
The ~$0 figure applies to the deep-mine’s marginal cash charge under the already-paid subscription.

Keeping those scopes separate prevents a seductive but false conclusion. A report about your history is not itself the full cost of the work recorded in that history. Its job is to help recover and summarize the evidence needed to understand your real usage.

Why your own history is more useful than a generic “average cost”

Generic averages hide the factors that dominate agentic coding bills. One developer may use a large context repeatedly with excellent prompt caching. Another may start fresh sessions, change prefixes frequently, or generate much more output. One may choose Opus 4.8; another may do most work with Sonnet 4.6 or Haiku 4.5. One may use a flat subscription daily; another may call the API occasionally.

Those differences affect both the metered estimate and the subscription-versus-API decision. Even if an average were available, it would not answer the personal question embedded in “how much does Claude Code actually cost me?”

Your local transcripts are better evidence because they describe your projects, your session cadence, your model usage, your active days, and the balance between what you write and what the agent returns. Agentmole’s purpose is to turn that local history into a readable report rather than force you to infer a budget from somebody else’s workflow.

The report’s leverage ratio is especially useful as context. It is defined as agent output relative to your input:

leverage_ratio = agent_output / user_input

This is not a dollar formula. It does not by itself tell you whether output was valuable, whether code was correct, or whether a subscription was worth buying. It tells you how much agent response volume your own prompting elicited. Read alongside token totals, cache-hit rate, and active days, it helps explain what kind of collaboration produced the usage.

For example, two histories can contain the same user-input volume while producing very different agent-output volume. Their output costs and collaboration patterns will differ. Two histories can also show similar total token volume but different cache-read shares, producing different metered costs. A wrapped-style summary is useful only if it preserves those distinctions rather than collapsing everything into a single vanity number.

How Agentmole turns local transcripts into a usage report

The flow is deliberately local until you choose otherwise:

Paste one command
    ↓
Your own coding agent reads local transcript files such as
~/.claude/projects/*.jsonl and the corresponding histories of supported agents
    ↓
It computes token totals, leverage ratio, cache-hit rate, active days,
collaboration patterns, quotes, and distilled skills
    ↓
The wrapped-style report opens in your browser
    ↓
You may optionally publish it with one click

The first step is not an upload form. Agentmole is free and open source: you give one command to your own AI coding agent—Claude Code, Codex, Cursor, or OpenClaw—and the analysis runs on your machine using your own subscription. The skill that directs the analysis is human-readable Markdown, so you can inspect what it asks the agent to do.

The second step is transcript discovery. For Claude Code, that includes local JSONL histories under paths such as ~/.claude/projects/*.jsonl. Similar supported-agent histories can be mined from their local locations. The exact value of this approach is that the evidence already exists where the work occurred: on the developer’s machine.

The third step is computation and interpretation. Token totals answer the volume question. The leverage ratio compares agent output with user input. Cache-hit rate exposes whether repeated context was served cheaply. Active days show how usage is distributed across the history. Quotes, corrections, process instructions, and taste declarations help explain what the numbers meant in practice.

The report then opens locally in the browser. Nothing has to leave the machine for the analysis to be useful. Publishing is optional and explicit; Agentmole’s servers store a page only after the user clicks publish.

That boundary matters for both privacy and auditability. Coding transcripts can contain repository details, debugging context, architectural decisions, and candid instructions. A tool asking you to understand usage should not require blind trust in a hidden upload pipeline. With Agentmole, the analysis instructions are readable, execution happens inside your own agent, and publication is a separate action you control.

For a concise version of the process, see the Claude Code cost and usage guide. The Agentmole landing page explains the broader wrapped report and supported agents.

Evidence sidebar: what the pilot actually processed

Raw local transcripts scanned: 31 GB plus 1.9 GB

Scan time: under three minutes

History covered: eleven months

Distinct user utterances extracted: 16,405

Taste declarations found: 235

Corrections found: 701

Process instructions found: 832

Deep-mine execution: ten parallel sub-agents

Deep-mine token use: about 2.2 million tokens

Mostly-input Opus 4.8 metered equivalent: about $11

Marginal cash for that analysis under the existing subscription: about $0

These figures are evidence from one pilot, not a promise that every history has the same size, speed, signal density, or analysis cost. Weekly incremental re-scans are far smaller than the full eleven-month deep-mine, but their exact size depends on the user’s new history. The pilot is valuable because it proves that the relevant record can be substantial and locally analyzable, not because it establishes a universal average.

What a useful personal cost report should contain

A credible personal Claude Code usage report should let you answer more than “how many tokens?” At minimum, you want enough separation to reconstruct the billing logic and enough behavioral context to interpret it.

For cost mechanics, retain or derive:

Input tokens by model.
Output tokens by model.
Cache-read input tokens.
Cache-creation input tokens.
The applicable cache time-to-live when known.
Whether any eligible API work used Batch.
The period covered by the history.

For workflow interpretation, pair those with:

Active days.
User turns or utterances.
Agent output relative to user input.
Corrections and process instructions.
Stable preferences or taste declarations.

The first group helps estimate metered dollars. The second helps decide whether the spend produced useful leverage or merely more text. A cheap workflow that repeatedly ignores instructions is not automatically good value. An expensive-looking history with high cache reuse and strong output leverage may be rational. Cost data becomes decision data only when it is tied back to how you work.

Reading token totals without fooling yourself

Several sanity checks make a personal estimate more reliable.

First, keep the period consistent. Do not compare an API estimate from an eleven-month transcript corpus with a single monthly subscription payment. Either convert both sides to the same period or compare month by month using your own numbers.

Second, separate the analysis workload from the coding workload. Agentmole’s deep-mine has its own token usage. The conversations it analyzes have their own token usage. Label both clearly if you want to include both in a broader productivity budget.

Third, preserve the model split. Applying the Opus 4.8 rate to Sonnet 4.6 or Haiku 4.5 tokens will overstate the input and output price for those models. Applying a cheaper model’s rate to Opus 4.8 usage will understate it.

Fourth, preserve the input-output split. Output carries the higher rate in all three verified models: $25 versus $5 for Opus 4.8, $15 versus $3 for Sonnet 4.6, and $5 versus $1 for Haiku 4.5. A combined total cannot reveal the exact dollar amount unless you know how that total divides.

Fifth, account for prompt caching. Treating cache_read_input_tokens as full-price uncached input can dramatically overstate API-equivalent cost. Ignoring repeated cache creation can understate it. Use the cache-aware formula rather than assuming all input has one rate.

Finally, do not confuse cost with value. Tokens measure model activity, not correctness, maintainability, or time saved. Agentmole’s collaboration patterns, quotes, corrections, and distilled skills are useful precisely because they keep the quantitative record connected to the human-agent relationship that generated it.

3. Execution checklist zone: what to do right now

You do not need a hypothetical industry average to get a better answer. You need to preserve the record, extract your own usage, apply the verified pricing mechanics, and compare like with like.

1. Stop the silent deletion of your cost record

Claude Code purges transcripts after 30 days by default. That means the history you would use to measure token usage, active days, recurring instructions, and long-term collaboration patterns is being deleted unless you change the retention setting.

Set a long cleanupPeriodDays value appropriate for your retention needs. In the verified pilot, the owner used:

cleanupPeriodDays=99999

The point is not that every developer must choose that exact value. The point is to stop assuming old sessions will remain available indefinitely. Choose a retention period deliberately, taking into account your local privacy, storage, compliance, and project requirements.

Do this before trying to reconstruct a long-term usage picture. Once old transcript files have been purged, a local analysis tool cannot mine evidence that no longer exists. The default 30-day window is enough to create a misleadingly small sample for someone who thinks they are looking at their full history.

Retention is also part of auditability. A monthly invoice or flat plan charge can tell you what you paid, but it cannot tell you what projects, instructions, corrections, or collaboration habits produced that spend. The transcript is the richer record. Preserve it if you want future cost analysis to be explainable.

2. Run Agentmole against your own local history

Use the one-command flow from Agentmole and give it to your own supported coding agent. The agent reads local transcripts, including Claude Code histories such as ~/.claude/projects/*.jsonl, and produces a browser report on your machine.

Look for these outputs:

Total token usage with as much model and input-output separation as your history provides.
Leverage ratio: agent output relative to your input.
Cache-hit rate or the underlying cache-read fields.
Active days across the measured period.
Corrections, process instructions, taste declarations, and representative quotes.

Do not publish merely to perform the analysis. Nothing needs to be uploaded for the local report to work. If you later want a shareable page, publishing is a separate, explicit one-click action.

Before accepting the result, inspect the skill’s Markdown instructions. The skill is designed to be human-readable and auditable. Confirm that the transcript paths and requested analysis match what you intend to expose to your own agent. Local execution reduces the trust boundary, but informed review is still good practice.

Also label the date range covered by the report. If default cleanup has already removed older sessions, state that the result covers the surviving history rather than your complete Claude Code lifetime. A precise partial record is better than a full-history claim unsupported by the files.

3. Convert your measured usage into a metered estimate

Take your real input, output, and cache numbers and apply the current rates from the pricing table. For each model:

model_cost ≈ (
  uncached_input_tokens × model_input_price
  + cache_read_input_tokens × model_input_price × 0.1
  + five_minute_cache_write_tokens × model_input_price × 1.25
  + one_hour_cache_write_tokens × model_input_price × 2
  + output_tokens × model_output_price
) / 1,000,000

Then add the model totals. If a known part of an API workflow used Batch, apply the 50% Batch rate to that eligible part rather than indiscriminately halving unrelated subscription or non-Batch usage.

If your transcript data cannot distinguish the cache-write time-to-live, do not invent it. Calculate a range using the verified write multipliers, or leave that component labeled as unknown. If you only know total tokens, state the assumed split before calculating an equivalent. The pilot’s “2.2 million mostly-input Opus 4.8 tokens ≈ $11” is a model for transparent approximation.

Keep the resulting label exact: this is an estimated metered API cost for the measured activity. It is not necessarily your cash payment. If the work ran on a subscription, it may have created no separate per-token charge.

4. Compare the estimate with your actual flat plan fee

Find the exact current price of your subscription on the vendor’s pricing page. Do not rely on a plan price quoted here, because this guide intentionally does not assert unverified Claude Pro or Max dollar amounts.

Compare the flat fee with the API estimate over the same period:

your_measured_API_equivalent_for_period
vs.
your_actual_subscription_fee_for_period

If the metered estimate is lower, the API may be cheaper for that measured usage. If the metered estimate is higher, the subscription may be cheaper for that measured usage. Keep “may” in the conclusion because plan limits, access terms, convenience, model availability, and the operational difference between interactive subscription use and API integration can matter even when the token arithmetic points one way.

Repeat the comparison as your usage changes. A developer’s workload is not stationary: active days, project size, model choice, and agent autonomy can all shift. Agentmole’s local history gives you a way to revisit the decision with evidence rather than treating subscription versus API as a permanent identity choice.

5. Raise cache reuse, then verify that it actually improved

Prompt caching is the largest explicit pricing lever in repeated agent context: cache reads are approximately 0.1× normal input price. Improve the chance of reuse by keeping stable system instructions stable and using deterministic tool ordering where your workflow allows it.

The important word is “verify.” After changing the workflow, inspect usage.cache_read_input_tokens and cache_creation_input_tokens. A cache optimization is real only if the usage record shows more input served from cache relative to the relevant repeated context, without an unjustified increase in cache creation.

Remember the write economics. The five-minute cache write costs 1.25× and breaks even on the second request. The one-hour cache write costs 2× and breaks even on the third request. Stable context that is never reused does not earn back the write premium; stable context reused across agent steps can.

Do not optimize for cache-hit rate in isolation. The goal is lower cost for useful work, not a decorative percentage. If making prompts artificially rigid harms task quality or causes more corrective turns, the overall workflow may get worse. Read cache behavior alongside token totals, corrections, process instructions, and actual outcomes.

4. Common misconceptions zone: where Claude Code cost explanations go wrong

Cost discussions become confusing when they collapse different ledgers, ignore caching, or substitute estimates from the wrong tokenization system. The following myths are common because each contains a fragment of truth. Correcting them requires keeping the scope explicit.

Myth: “Claude Code cost equals the subscription price.”

The subscription price is what you pay for the plan. It is not a complete measurement of the compute used by your work.

If your subscription is already paid, an additional qualifying coding or analysis run can have approximately zero marginal cash cost. The same run can still represent a measurable token volume and an API-equivalent dollar value. Agentmole’s pilot deep-mine illustrates the difference: about 2.2 million mostly-input Opus 4.8 tokens correspond to roughly $11 at the verified input rate, while the marginal cash charge under the existing subscription was about $0.

The reverse distinction matters too. Paying a fixed plan fee does not prove you extracted more metered value than you paid for. A light user’s API-equivalent usage may be below the subscription fee. A heavy user’s API-equivalent usage may be far above it. You cannot know which case describes you without measuring your tokens and comparing the same time period.

This is why an honest answer to “how much does Claude Code cost?” begins with a follow-up concept, even when it does not ask a follow-up question: do you mean the posted access price, the API-equivalent value of the work, or the marginal cash cost of another run? All are legitimate, but they answer different decisions.

For a subscription-versus-API decision, calculate the metered estimate from your own history and compare it with the current flat plan fee shown by the vendor. Do not import another developer’s usage pattern. Do not use an old subscription price. Do not compare a long corpus with a short billing period.

Myth: “Output tokens are the main cost.”

Output tokens have the higher per-token rate in every model in the verified table. Opus 4.8 output is $25 per million versus $5 for input; Sonnet 4.6 is $15 versus $3; Haiku 4.5 is $5 versus $1. That price ratio makes the myth sound plausible.

But a higher unit price does not guarantee that output dominates the bill. Agentic coding can carry very large input contexts across repeated requests. System instructions, project guidance, conversation history, file contents, tool schemas, and tool results may collectively produce far more input volume than the visible answer produces output.

Prompt caching is therefore often the decisive lever. Cached input reads cost approximately 0.1× the base input rate. A workflow with large repeated context and strong cache reuse can process a huge input volume economically. A similar workflow with a low cache-hit rate can silently pay much more because it keeps sending fresh or newly written context.

The correct question is not “Is input or output always more expensive?” It is:

uncached input cost
+ cache-read cost
+ cache-write cost
+ output cost
= total metered cost

Measure every component. Your output may dominate, but the price table alone cannot prove it. Your token mix and cache behavior decide.

This also explains why shortening answers is not always the first or largest optimization. If the workflow repeatedly invalidates a massive input prefix, fixing cache reuse may have more impact. Conversely, if the history shows modest input and extensive generated output, output control may matter more. The usage fields should choose the optimization target.

Myth: “An analysis tool must upload my code or history to a server.”

Some services do require server-side ingestion, but that is not a technical requirement for transcript analysis. Agentmole runs inside your own supported coding agent on your own machine. The agent reads local histories, performs the analysis using your own subscription, and opens the resulting report locally in your browser.

The analysis skill is human-readable Markdown. That makes its instructions inspectable rather than hiding the process behind a binary or an unexplained remote job. You can audit what the skill asks the agent to read and produce before running it.

Nothing is uploaded merely because you generated the report. Agentmole’s servers store a page only after you explicitly click publish. That separation gives local analysis and public sharing different trust boundaries.

This does not mean “local” should become a magic word that ends scrutiny. You should still inspect the instructions, understand which transcript paths are in scope, and review the generated report before publishing. The point is narrower and verifiable: local processing is possible, and Agentmole does not require an upload before analysis.

For coding histories, that matters. Transcripts can contain quotes, corrections, process instructions, repository context, and personal preferences. The pilot found 235 taste declarations, 701 corrections, and 832 process instructions in 16,405 user utterances. Those signals make the report useful, but they are also exactly why the user should control whether a result remains local or becomes shareable.

Myth: “I can estimate Claude tokens with a GPT tokenizer such as tiktoken.”

tiktoken is the wrong tokenizer for Claude. Using it can undercount Claude tokens, which makes the resulting cost estimate look more precise than it is while biasing it downward.

This is a category error, not merely a small implementation detail. Token boundaries are model-family-specific. A tokenizer designed for a different model family does not become correct because both systems process text or because its output is easy to obtain.

For retrospective Claude Code analysis, prefer the real usage information preserved in the history. Where usage fields expose input, output, cache reads, and cache creation, use those fields. They connect directly to the billing categories in the formula and avoid pretending that a GPT token count is a Claude token count.

If a historical record lacks a needed split, state the limitation. A transparent range or assumption is more defensible than running the text through the wrong tokenizer and presenting the result as measured truth. Agentmole’s value here is not that it guesses better; it mines the local record generated by the actual agent workflow.

Myth: “My old Claude Code sessions are saved.”

By default, Claude Code purges transcripts after 30 days. Unless you change the retention setting, the record you expect to analyze later is evaporating now.

That deletion affects more than nostalgia. It removes the evidence needed to inspect long-term token usage, active days, model behavior, cache patterns, recurring corrections, and durable preferences. It can also bias a subscription-versus-API comparison toward recent activity, because the surviving sample no longer represents the period you believe you are measuring.

Set a deliberate cleanupPeriodDays value before the default window erases more history. The verified pilot owner used cleanupPeriodDays=99999, which allowed an eleven-month corpus to survive for analysis. Choose your own value based on retention and privacy needs; the critical step is making the decision explicitly.

After changing retention, verify what history already remains. A new setting prevents future deletion according to that retention choice; it does not recreate purged transcripts. When you run Agentmole, label the report’s covered dates and avoid describing a partial surviving corpus as your lifetime usage.

The lesson is simple: cost observability depends on data retention. If the local source record disappears, neither a formula nor an analysis tool can reconstruct every missing token, correction, or instruction after the fact.