Count CometAPI Claude cache writes and reads before applying a price-cut claim

General
1

A cache-read price cut does not reduce every request by the same percentage. Its effect depends on how much work actually reuses cached input—and what the selected route charges for creating that cache.

Anthropic’s Fable 5.1 announcement says cache reads became 75% cheaper. It reports around 25% lower overall cost for typical workloads relative to Fable 5, with savings potentially reaching around 45% for complex coding and highly agentic tasks. Its comparison used default effort and four weeks of August 2026 usage. Those workload results are not a CometAPI price quote.

For a CometAPI Claude cache experiment, use the documented Anthropic Messages route and verify the selected model’s support before applying cache_control to content blocks. The Messages reference reports cache_creation_input_tokens for cache writes and cache_read_input_tokens for reads. They answer different questions: how much context was written, and how much was subsequently reused?

The same reference’s endpoint comparison marks this prompt-caching control as unavailable on /v1/chat/completions. Do not carry a Messages cache_control assumption into a compatibility-route fallback. That table is not proof that no provider performs any automatic caching; it defines the documented control surface being tested.

Separate rate changes from reuse changes

A proposed measurement plan can preserve both:

  1. Pin the model, native route, cache settings, prompt family, and observation date. Check account access and current cache requirements before testing.
  2. Record the raw input, output, cache-creation, and cache-read counters for every attempted request. Missing counters remain unknown, not assumed zero or a demonstrated cache miss.
  3. Separate first writes from repeated-prefix requests. Count failures and re-creations as well as successful reads; a workload with frequent prefix changes may have a different mix.
  4. Map the observed usage to verified, non-overlapping billing quantities and the current CometAPI tariff. Do not invent a cache rate or add counters whose inclusion relationship is unresolved.

To examine a rate change alone, hold the observed token mix fixed and price it under each verified tariff. To examine a workload change, keep the tariff fixed and compare the observed write/read mix. Treat either as an estimate until reconciled with a controlled billing sample.

This is an evaluation proposal, not a tested cache integration or promised saving. The documented fields provide observations to collect; they do not establish Fable availability on an account, transfer Anthropic’s discount, or settle retention terms. Verify those separately before changing a production budget.

2

A useful addition for streaming and voice-agent workloads is to treat prefix stability as a latency variable, not only a cost variable. A long system prompt or tool schema may be identical in principle, but turn-by-turn transcripts, timestamps, interruption markers, and growing conversation state can change the serialized prefix often enough to create new cache writes instead of reads. That makes an aggregate “cache hit rate” misleading: two workloads can have the same read-token total while one pays more writes and experiences more first-request latency.

I’d therefore log each request’s cache-write and cache-read tokens alongside time-to-first-token, interruption/retry status, and the exact prefix version (a local hash is sufficient). Compare stable-prefix turns with turns after a barge-in or tool-result update, and keep failed/recreated prefixes visible. This would show whether a proposed cache saving survives the realtime workload’s churn; it is a measurement design, not evidence that CometAPI currently delivers a particular latency or price outcome.