pricing: Claude's 1-hour cache writes are priced at 1.25x, but billed at 2x

Aperta
  • Qualcosa non va?
#191 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@anascherif ci sta già lavorando.

Dal 9/11/2026.

  • #192 di @anascherif — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
python
Ambito
data

Direzione di ricerca

Read pricing.py and the Claude session reader that extracts usage.cache_creation; the issue names both as the change points. Check how effective_tokens applies weight tables and inspect the existing tests for session parsing and pricing. Done when 1-hour cache-write tokens are capped by cache_creation_input_tokens, priced at 2x when the weight is available, and existing rows and weight tables retain current behavior.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

pricing.py prices every Claude cache-write token at 1.25x input (cache_write=1.25). Anthropic bills a cache write by its lifetime: 1.25x for the 5-minute cache and 2x for the 1-hour cache (prompt caching pricing).

Claude Code records the split per message in usage.cache_creation (ephemeral_5m_input_tokens, ephemeral_1h_input_tokens), but claude_session_usage only reads the total cache_creation_input_tokens, so the 1-hour share is lost before pricing.

Effect. On my machine (Claude Code on a subscription), across my 35 most recent session transcripts (4,841 assistant messages), essentially all cache-write tokens are in ephemeral_1h_input_tokens. Pricing them at 2x instead of 1.25x raises those sessions' effective tokens by about 8%, so te status and the session ledger understate them by that much.

Proposed fix. Have the Claude session reader sum the 1-hour share as cache_creation_1h_input_tokens, and have effective_tokens price that share at a cache_write_1h weight (2.0 on the Claude curve). Rows without the field and weight tables without the entry stay priced exactly as today. I have this implemented with tests and will open a PR.

One detail from real transcripts: some messages carry a non-zero ephemeral_1h_input_tokens while every top-level count is 0, so the 1-hour share should be capped at the message's cache_creation_input_tokens.

Lingua principale
Python
Stelle
5.6k
Fork
344
Merge medio
14h 41m
PR unite (30g)
54

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/TokenEconomizer

Tutte le issue di microsoft/TokenEconomizer

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.