Cache creation cost underestimated: 1-hour cache writes priced at 5m rate (1.25x) instead of 2x

[lumian2015]

Summary

When using calculate mode, ccusage prices all cache_creation_input_tokens at a single cache_creation_input_token_cost rate from LiteLLM, which corresponds to the 5-minute cache write multiplier (1.25× base input). However, Claude Code predominantly uses 1-hour caching, which Anthropic prices at 2× base input — a 60% higher rate.

Anthropic official pricing

From Anthropic's pricing page:

Cache operation	Multiplier	Duration
5-minute cache write	1.25× base input price	Cache valid for 5 minutes
1-hour cache write	2× base input price	Cache valid for 1 hour
Cache read (hit)	0.1× base input price	Same duration as the preceding write

Full model pricing table (relevant columns):

Model	Base Input	5m Cache Writes	1h Cache Writes	Cache Hits
Claude Opus 4.6	$5/MTok	$6.25/MTok	$10/MTok	$0.50/MTok
Claude Sonnet 4.6	$3/MTok	$3.75/MTok	$6/MTok	$0.30/MTok
Claude Sonnet 4.5	$3/MTok	$3.75/MTok	$6/MTok	$0.30/MTok
Claude Haiku 4.5	$1/MTok	$1.25/MTok	$2/MTok	$0.10/MTok

Data available in JSONL

Claude Code's JSONL files already include a cache_creation breakdown inside the usage object that distinguishes the two durations:

{
  "usage": {
    "input_tokens": 3,
    "output_tokens": 10,
    "cache_creation_input_tokens": 23566,
    "cache_read_input_tokens": 19357,
    "cache_creation": {
      "ephemeral_5m_input_tokens": 0,
      "ephemeral_1h_input_tokens": 23566
    }
  }
}

In my dataset (~40k usage records), the vast majority of cache creation tokens are 1-hour:

Model	5m tokens	1h tokens	% 1h
claude-opus-4-6	9.6M	116.5M	92%
claude-sonnet-4-5-20250929	0	7.8M	100%
claude-sonnet-4-6	2.1M	0	0%
claude-haiku-4-5-20251001	15.8M	30.9M	66%

Current behavior in ccusage

In packages/internal/src/pricing.ts, calculateCostFromPricing uses a single cache_creation_input_token_cost (sourced from LiteLLM) for all cache creation tokens:

const cacheCreationCost = calculateTieredCost(
    tokens.cache_creation_input_tokens,
    pricing.cache_creation_input_token_cost,            // 1.25x rate
    pricing.cache_creation_input_token_cost_above_200k_tokens,
);

There is no reference to ephemeral_5m_input_tokens or ephemeral_1h_input_tokens anywhere in the codebase (gh search code "ephemeral" --repo ryoppippi/ccusage returns 0 results).

Impact

Cost comparison on my usage data:

Model	Cost (all at 1.25×)	Cost (5m/1h split)	Under-reported
claude-opus-4-6	$2,388	$2,826	$438 (18%)
claude-haiku-4-5-20251001	$112	$135	$23 (21%)
claude-sonnet-4-5-20250929	$46	$63	$17 (38%)
Total	$2,568	$3,047	$479 (19%)

Suggested fix

When parsing JSONL records, check if usage.cache_creation is a dict containing ephemeral_5m_input_tokens and ephemeral_1h_input_tokens. If so, apply the correct rate for each:

• ephemeral_5m_input_tokens × 1.25× base input price
• ephemeral_1h_input_tokens × 2× base input price

Fall back to the current single-rate behavior when the breakdown is not available.

This is partly an upstream issue in LiteLLM's pricing data (cache_creation_input_token_cost only has one rate), but ccusage can handle the split independently since the token breakdown is already in the JSONL data.

[felixmanojh]

I’d like to work on this.

Plan:

• parse usage.cache_creation.ephemeral_5m_input_tokens and ephemeral_1h_input_tokens when present
• price 5m and 1h cache writes separately
• fall back to current behavior when the breakdown is missing
• add regression tests for 5m-only, 1h-only, mixed, and fallback cases

If that scope looks good, I’ll send a PR.

[wartzar-bee]

This is a real gap, and you've documented it precisely. The cache_creation split in Claude Code's JSONL (ephemeral_5m_input_tokens / ephemeral_1h_input_tokens) has been there a while, but most tools that read the flat cache_creation_input_tokens field miss it.

The math matters most for heavy Opus users — the 1h write tier (2×) vs the 5m tier (1.25×) is a 60% per-token difference on creation cost, so on write-heavy sessions the undercount compounds fast.

One implementation note for the fix in #1190: when both ephemeral_1h_input_tokens and ephemeral_5m_input_tokens are absent (older records, or non-Claude-Code API calls), an explicit fallback to the flat 1.25× is the right call rather than 0 or erroring. Also worth checking whether the cache_creation_input_token_cost in the pricing source reflects the 5m rate, the 1h rate, or a blend — if it's blended, the tiered fix will diverge from the current fallback even on "compatible" records.

We ran into exactly this building tokenscope (https://github.com/wartzar-bee/tokenscope), a Claude Code–specific breakdown of spend by model + cache read/write from the same JSONL. The 5m/1h split is one of the trickier things to get right on real data, since older sessions that predate the split field still dominate most users' history.