Anthropic's October 7 price cut halves one line of the Sonnet 5.5 bill

The saving scales with one counter. A dev.to post on the change puts the direct difference at $0.10 per million cache-read tokens, assuming the same volume and billing terms ^[3]. Its formula for an existing workload takes recorded cache-read tokens, divides by one million, and multiplies by the gap between the old and new rates ^[4]. Each dollar saved takes 10 million cache-read tokens ^[17]. A route has to serve a billion cache-read tokens a month before the cut is worth $100 a month on it ^[18].

Measured against the whole invoice, the saving gets smaller. Output generation, uncached input, cache creation, retries and other models are separate lines ^[14]. The post quotes Anthropic's release notes as saying cache writes and all other prices are unchanged ^[2]. A total bill therefore falls by half of whatever fraction of it was cache-read spend before the October 7 cut ^[16]. The full 50 percent would need a bill made only of reads. That is an odd workload, given that the first request to a prefix has to write the cache before anything can read it ^[6]. The post does not quote the write or uncached-input rates.

Writes are where the cut can mislead. A prompt that changes on every call can create cache writes without earning enough later reads to offset them, and writes are still billed at the old rate ^[6]. The post's advice is to put stable content ahead of request-specific data and confirm that the exact route reuses that prefix ^[10]. The routes that gain already hit a large repeated prefix, such as a stable system instruction, shared reference material or tool definitions ^[9]. A larger read saving can also sit beside higher write or uncached-input spend on the same route ^[12].

Measuring it is cheap because the API already splits the counters. The response usage object reports cache_read_input_tokens separately from cache_creation_input_tokens and ordinary input_tokens ^[7]. That is good API design. The number that decides the saving comes back with every response, and no prompt text has to be stored to use it. The post recommends persisting those counters with model ID, route, timestamp, request outcome and an internal request class, while keeping customer prompts and secrets out of the log ^[11].

Before-and-after comparisons usually go wrong at the grouping step. Pool Sonnet 5.5 with other models, or pool unrelated request types, and a shift in workload looks like a price effect ^[8]. The post's checklist for each comparison window covers completed calls, the four token counters, errors and retries. It also reports per-call averages beside totals when traffic volume differs ^[13].

I think the post has the order right. Compute the read delta from logged counters and treat it as an estimate of one component at published rates. Keep the raw counts, so the figure can be recomputed if a rate or a negotiated billing term changes ^[15].