Cache-read pricing dropped sharply enough to invalidate cost models that treat cached and uncached input alike. Anthropic reports that cache reads now cost 75% less, or $0.25 per million tokens. [1] Base pricing remains $10 per million input tokens and $50 per million output tokens. [1] That means a cache-heavy workload deserves a fresh estimate before the next architecture decision.
Recalculate Reused Context
A cache read happens when the model reuses stored input rather than processing the same context from scratch. Separately track uncached input, cached input, output, retries, and tool-loop length when you model the API bill. For workloads where a large context repeats across many invocations, the cached-input share can dominate the total. [1]
Consider a legacy code assistant that loads the same repository map and policy documents at the start of every task. When that context is uncached, it bills at the full input rate on every invocation. When cached, it bills at the reduced cache-read rate. For a high-volume assistant, the difference accumulates across every accepted task, retry, and tool-loop iteration. The vendor estimates that this lowers typical workload cost by around 25% and highly agentic workload cost by up to around 45%. [1] Both figures are Anthropic-reported and have not been independently validated. The access pattern still explains why the effect should vary: workloads that reuse large contexts benefit more because the lower price applies whenever stored context is reused instead of processed again.
Preserve a Real Workload Baseline
The right response is not to trust the vendor estimate at face value. Preserve your existing cost baseline: the actual billing data from representative tasks completed before the pricing change. Then replay those tasks under current rates, tracking total cost per accepted task rather than raw token counts.
Include retries and review cycles in that total. A result only counts when it passes the acceptance check your team already uses. If replayed tasks show materially lower cost at equivalent acceptance rates, the case for changing the architecture becomes defensible. If not, the vendor estimate may describe a task profile different from yours.
Reopen the Retention Review
A separate question opened at the same time: whether regulated workflows previously blocked by a retention policy now have a viable routing path.
The earlier policy required 30 days of retention for covered frontier-model traffic. [2] For teams in healthcare, finance, or another domain with strict data residency or confidentiality rules, that requirement could make frontier-model routing legally or contractually unavailable, regardless of model capability or cost. Anthropic has now described a proposed answer called Enterprise Frontier Safeguards, or EFS. Both sources cited here are Anthropic publications; the pricing estimates and EFS architecture have not been independently validated here.
EFS combines zero data retention—meaning the vendor does not retain prompts or responses after processing—with misuse monitoring that stores usage data in customer-controlled cloud infrastructure. When enabled, customer-managed encryption keys, access policies, and audit logging govern that storage. Automated analysis examines a rolling window across sessions and accounts, then sends flags to the customer's team. Anthropic human review is not required. Anthropic says it developed the system with more than 100 customers. [2] The cloud provider bills separately for storage, reads, writes, and egress. Anthropic says EFS does not change model behavior, API pricing, or rate limits.
This architecture changes the routing question but does not answer it for your environment. Before EFS, you may have concluded that no compliant path existed. Now you need to determine whether the proposed controls satisfy your obligations and whether you can access them before your production deadline.
EFS is scheduled to roll out in phases beginning later this fall; broad availability is a stated goal, not the current status. Eligible customers can use the new Fable model with zero data retention while EFS is pending. [2] [1] Before routing regulated work through this path, confirm your organization's eligibility and the delivery date that applies to your platform.
Then get written answers to the operational questions. Who owns the encryption keys, and where are they stored? Where do the usage logs land, and who can access them? Who owns alert triage when automated analysis raises a flag? What review process follows an escalation? What do cloud storage and egress add to total request cost? How is deletion handled? What happens during an incident? Which fallback route remains available if access changes? Those answers turn a vendor architecture into a control record your compliance and legal teams can review.
Keep the Gates Separate
The cost experiment and retention review belong in separate decision gates. Lower cache-read costs have no bearing on whether a workflow is permissible under your data-handling obligations. A favorable cost result cannot relax a retention constraint. Keep the two decisions separate in your documentation and approval chain.
Create a cost-and-compliance gate document before changing the architecture. The cost side should record the old billing baseline, replayed task cost at current pricing, acceptance rate, and a go-or-stop threshold. The compliance side should record eligibility confirmation, written answers to the operational questions, and sign-off from the owner of your data-handling obligations. Change the routing only after the relevant side of that document is complete; change both cost and routing only after both sides pass.