Your Cache Hit Rate Resets to Zero the Morning You Switch Models — Prompt Cache Rewarm Design for the Opus 4.8 to Sonnet 5 Cutover

Cutting over by task family — the cohort design

There is exactly one principle: never split a group of runs that shares a prefix across two models. The unit of migration is the task family, not the request.

The configuration needs nothing more than this:

// cutover.ts — resolve the model per task family
type ModelId = "claude-opus-4-8" | "claude-sonnet-5";
 
interface TaskFamily {
  id: string;              // e.g. "nightly-digest", "log-triage"
  prefixTokens: number;    // approximate shared prefix size
  runsPerDay: number;
  avgIntervalMin: number;  // used for TTL reasoning
  model: ModelId;          // current home model
  cutoverAt?: string;      // ISO date; newModel applies from here on
  newModel?: ModelId;
}
 
export function resolveModel(f: TaskFamily, now = new Date()): ModelId {
  if (f.cutoverAt && f.newModel && now >= new Date(f.cutoverAt)) {
    return f.newModel;
  }
  return f.model;
}
 
// Guard: mechanically reject configs that could split a family
export function assertNoSplit(families: TaskFamily[]): void {
  for (const f of families) {
    if (f.cutoverAt && !f.newModel) {
      throw new Error(`${f.id}: cutoverAt is set but newModel is missing`);
    }
  }
}

Callers simply pass model: resolveModel(family). The point is that each family carries its own cutover date, which turns migration order into a design variable.

For ordering, I prefer these criteria:

1. Migrate low-reuse families first. A family that runs a handful of times per day gets little from the cache anyway, so the cold-write loss is negligible. It makes an ideal observation deck for output quality.
2. Families whose run interval already exceeds the TTL go early. If every run is cold anyway, migration loses nothing.
3. High-reuse backbone families go last, once several days of observations have accumulated and you can move them with confidence.

One more trick that pays off on cutover morning: a prewarm request. Just before the batch window, send a single minimal request to the new model to write the prefix, so the first real run does not eat the cold-write latency.

// prewarm.ts — run once before the first batch on cutover day
import Anthropic from "@anthropic-ai/sdk";
 
const client = new Anthropic();
 
export async function prewarmPrefix(model: ModelId, systemPrompt: string) {
  await client.messages.create({
    model,
    max_tokens: 1,
    system: [
      { type: "text", text: systemPrompt, cache_control: { type: "ephemeral" } },
    ],
    messages: [{ role: "user", content: "ok" }],
  });
}

Note that families below the minimum cacheable prefix length (1,024 tokens on the Sonnet and Opus lines) sit outside this whole discussion. Exclude them from the family list before you plan the order.

Measuring hit rate per family from the usage block

Migration decisions should rest on the usage block of real responses, not on intuition. Three fields matter:

// cache-metrics.ts — hit rate aggregated by family and model
interface RunUsage {
  familyId: string;
  model: string;
  inputTokens: number;               // usage.input_tokens
  cacheRead: number;                 // usage.cache_read_input_tokens
  cacheWrite: number;                // usage.cache_creation_input_tokens
}
 
export function hitRate(runs: RunUsage[]): Map<string, number> {
  const acc = new Map<string, { read: number; total: number }>();
  for (const r of runs) {
    const key = `${r.familyId}/${r.model}`;
    const cur = acc.get(key) ?? { read: 0, total: 0 };
    cur.read += r.cacheRead;
    cur.total += r.cacheRead + r.cacheWrite;
    acc.set(key, cur);
  }
  return new Map(
    [...acc].map(([k, v]) => [k, v.total === 0 ? 0 : v.read / v.total])
  );
}

In my own operation this aggregation lands in a daily log, and I watch for duplicated family-model rows. If the same familyId shows rows for two models on the same day, a split has crept in — usually a request built somewhere that bypasses resolveModel with a hard-coded model string. This table catches it. I wait until the hit rate returns to its pre-migration level (around 90% in my measurements) for two or three days before moving the next cohort.

A migration cost simulator — working backward from August 31st

Sonnet 5's introductory pricing runs through 2026-08-31, after which the rate returns to $3 / $15. Since both the cache write multiplier (1.25x) and the read multiplier (0.1x) apply to the base input rate, the migration validation itself is roughly 33% cheaper if done in August. One less reason to postpone, the way I see it.

Comparing strategies by hand gets tedious, so a small simulator does the job:

// simulate.ts — rough 30-day cost per migration strategy
interface Pricing { inPerMTok: number; outPerMTok: number }
const SONNET5_INTRO: Pricing = { inPerMTok: 2, outPerMTok: 10 };
const OPUS48: Pricing = { inPerMTok: 5, outPerMTok: 25 };
 
interface Family { prefix: number; fresh: number; out: number; runs: number; warmRatio: number }
 
function dailyCost(f: Family, p: Pricing, coldWritesPerDay: number): number {
  const warmRuns = f.runs * f.warmRatio;
  const read = (warmRuns * f.prefix / 1e6) * p.inPerMTok * 0.1;
  const write = (coldWritesPerDay * f.prefix / 1e6) * p.inPerMTok * 1.25;
  const fresh = (f.runs * f.fresh / 1e6) * p.inPerMTok;
  const out = (f.runs * f.out / 1e6) * p.outPerMTok;
  return read + write + fresh + out;
}
 
// Example: 8k prefix, 2k fresh input, 1.5k output, 40 runs/day, 90% steady-state hit rate
const fam: Family = { prefix: 8000, fresh: 2000, out: 1500, runs: 40, warmRatio: 0.9 };
 
console.log("Stay on Opus 4.8   :", dailyCost(fam, OPUS48, 4).toFixed(3));
console.log("Sonnet 5, cohort   :", dailyCost(fam, SONNET5_INTRO, 4).toFixed(3));
// Percentage split: warmRatio drops on both models, cold writes rise on both
console.log(
  "50/50 request split:",
  (
    dailyCost({ ...fam, runs: 20, warmRatio: 0.3 }, OPUS48, 14) +
    dailyCost({ ...fam, runs: 20, warmRatio: 0.3 }, SONNET5_INTRO, 14)
  ).toFixed(3)
);

Running this against my own families, staying on Opus 4.8 came out around $1.90 per day, a cohort cutover to Sonnet 5 around $0.76, and the 50/50 request split stalled at about $1.44. The split is "using the cheaper model for half the traffic yet saving only 24% versus staying put" — while diluting quality observation across both sides. Once the numbers are in front of you, there is little reason left to choose it.

Operational lessons the multiplier table does not tell you

A few details that only surfaced after actually switching.

Consider the 1-hour TTL for cutover week only. The 1h TTL write costs 2x the base rate versus 1.25x for the 5-minute TTL, so it looks worse on paper. But for families running at 5-to-60-minute intervals, the 5-minute TTL means a cold write every single run (1.25x each time), while the 1-hour TTL means one 2x write followed by 0.1x reads. If a family runs at least twice per hour, the 1h TTL wins. It is especially useful for families you have deliberately slowed down during the observation period.

Rollback is cheap — do not let it distort your judgment. Minutes after cutover, the old model's cache has already expired, so the feeling that "rolling back wastes the warm cache" is an illusion. The cost of rolling back is one cold write per family. The rollback trigger should be output-quality regression (against your golden dataset, for instance), never cost.

Never ride the platform default — always pin the model explicitly. Since June 30th the platform default has been moving to Sonnet 5. Any request path that omits the model will split your families independently of your plan. Even at indie scale, I recommend concentrating model IDs in one config file (the TaskFamily definition above) and banning model string literals from request-building code.

As a next step, aggregate cache_read_input_tokens and cache_creation_input_tokens per family from your own logs, and pick one family whose run interval already exceeds the TTL as your first cohort. Starting where there is no cache left to lose turns the observation period into pure upside.

I hope this helps you plan your own cutover. Thank you for reading.