Introductory Pricing Has an End Date — Effective-Dated Cost Forecasts for the Sonnet 5 Price Step

Give every price a validity window

The core fix is simple: store prices not as a map of model → rate but as rows of model × period → rate. Accounting systems have called this effective dating for decades; we just borrow it.

// After: each price row carries its validity window
type PriceWindow = {
  model: string;
  inPerMTok: number;
  outPerMTok: number;
  validFrom: string;         // ISO date, inclusive
  validUntil: string | null; // ISO date, exclusive; null = open-ended
};
 
const PRICE_BOOK: PriceWindow[] = [
  { model: "claude-sonnet-5", inPerMTok: 2, outPerMTok: 10,
    validFrom: "2026-06-30", validUntil: "2026-08-31" }, // rounded one day toward the expensive side
  { model: "claude-sonnet-5", inPerMTok: 3, outPerMTok: 15,
    validFrom: "2026-08-31", validUntil: null },          // standard price
  { model: "claude-opus-4-8", inPerMTok: 5, outPerMTok: 25,
    validFrom: "2026-06-30", validUntil: null },
];
 
function resolvePrice(model: string, onDate: string): PriceWindow {
  const hits = PRICE_BOOK.filter(
    (w) =>
      w.model === model &&
      w.validFrom <= onDate &&
      (w.validUntil === null || onDate < w.validUntil)
  );
  if (hits.length === 0) {
    // fail closed: never let an unpriced date pass through as $0
    throw new Error(`no price window: ${model} on ${onDate}`);
  }
  if (hits.length > 1) {
    throw new Error(`overlapping price windows: ${model} on ${onDate}`);
  }
  return hits[0];
}
 
function estimateCostOn(
  model: string, onDate: string, inTok: number, outTok: number
): number {
  const p = resolvePrice(model, onDate);
  return (inTok / 1e6) * p.inPerMTok + (outTok / 1e6) * p.outPerMTok;
}

Three deliberate choices here:

1. Dates are ISO strings compared lexicographically. Going through Date objects invites timezone interpretation, and day-granularity decisions do not need clock time.
2. Zero matching rows is an exception. Silently pricing an unknown date at $0 hides the hole until the invoice arrives. This is the same reasoning I used in a fail-closed unit-price registry that survives new model launches — that article rejected unknown models; this one rejects unknown dates of known models.
3. Overlapping rows are also an exception. If a data-entry mistake makes two windows overlap, the resolved price becomes an accident of filter order. Non-deterministic price resolution is undebuggable.

Draw the price step into the monthly forecast

Once price is a function of date, forecasting reduces to "look up the right rate for each day and accumulate."

// Build monthly cost from daily token consumption
function forecastMonthly(
  model: string,
  dailyInTok: number,
  dailyOutTok: number,
  fromDate: string,   // e.g. "2026-07-01"
  days: number
): Map<string, number> {
  const byMonth = new Map<string, number>();
  const cur = new Date(fromDate + "T00:00:00Z");
  for (let i = 0; i < days; i++) {
    const iso = cur.toISOString().slice(0, 10);
    const cost = estimateCostOn(model, iso, dailyInTok, dailyOutTok);
    const month = iso.slice(0, 7);
    byMonth.set(month, (byMonth.get(month) ?? 0) + cost);
    cur.setUTCDate(cur.getUTCDate() + 1);
  }
  return byMonth;
}
 
const f = forecastMonthly("claude-sonnet-5", 6_000_000, 900_000, "2026-07-01", 92);
// 2026-07 → $651.0  (31 days × $21)
// 2026-08 → $661.5  (30 days introductory + Aug 31 at standard: 30×$21 + 1×$31.5)
// 2026-09 → $945.0  (30 days × $31.5)

Look at the August line: the edge of the step is already visible, because of the conservative rounding. That is the practical difference from a static map — the step appears in the forecast itself, so when someone asks about the September number you can answer, immediately, that it is not a price increase but the end of a discount. The accumulation style is the same one I described in forecasting monthly token costs from usage data; only the price lookup became date-dependent.

If you use discounted line items such as cache reads or the Batches API, give each line item its own PriceWindow rows. There is no guarantee an introductory multiplier applies uniformly across line items, and the lazy shortcut of "multiply the model by 1.5" will drift again depending on your mix.

Catch expiring windows in CI, not on the morning of September 1

Effective dating has one operational weakness: forgetting the successor row. If a window closes and no row follows it, every forecast past that date throws. Throwing is exactly what fail-closed promised — but discovering it on September 1 is too late, so we test coverage ahead of time.

// Guarantee the price book covers the whole forecast horizon
function assertCoverage(model: string, fromDate: string, horizonDays: number): void {
  const cur = new Date(fromDate + "T00:00:00Z");
  for (let i = 0; i < horizonDays; i++) {
    const iso = cur.toISOString().slice(0, 10);
    resolvePrice(model, iso); // throws on any gap or overlap
    cur.setUTCDate(cur.getUTCDate() + 1);
  }
}
 
// Test: every model must be priced for the next 180 days
test("price book covers 180-day horizon", () => {
  const today = new Date().toISOString().slice(0, 10);
  for (const model of new Set(PRICE_BOOK.map((w) => w.model))) {
    assertCoverage(model, today, 180);
  }
});

The 180 days are not magic: 90 for a quarterly forecast plus 90 of slack. With this test in place, the working habit becomes "the day you read a dated pricing announcement, you add the closing row and the successor row as a pair" — because adding only one of them fails CI the same day. Price increases and discounts are the same kind of change to this table.

Do not let an introductory price make permanent decisions

The mechanics end here; what remains is judgment. During the introductory window, Sonnet 5 looks 60% cheaper than Opus 4.8 on both input and output. From September the gap narrows to 40%. $2 versus $5 feels very different from $3 versus $5.

Where this bites is retry-adjusted break-evens. When you move a stage down from Opus to Sonnet and absorb the quality gap with retries, Sonnet's effective cost is (1 + retry rate) times its list price. At the introductory rate — 40% of Opus — Sonnet wins as long as the retry rate stays under 150%, i.e. up to 2.5 executions on average. At the standard rate — 60% of Opus — the break-even drops to 67%. A "Sonnet is good enough" call made in July can stop being true in September.

So I split decisions by their lifetime:

1. Permanent decisions use the standard price. Default model choice, routing thresholds, per-stage model assignment — all computed at $3 / $15. The introductory price is a tailwind that makes those decisions temporarily more profitable, never their justification.
2. Movable bulk work gets pulled into August. Re-classifying old logs, regenerating embeddings, batch-summarizing archives — anything "whenever" runs while the rate is two-thirds. I have about 200M input tokens of reprocessing scheduled for August; that alone is the difference between $400 and $600.
3. Re-verify migration economics at the September rate. I covered the mechanics of the cutover itself in re-warming prompt caches when you switch models; if the payback math behind your migration used the introductory price, redo it at $3 / $15 before September does it for you.
4. Reconcile the first September invoice against the forecast. The only real test of your effective-dated rows is the bill. If they disagree, either your rounding direction or your line-item split is wrong.

Wrap-up — what to do before the end of August

The work is small. Add a validity column to your price table, insert the two rows for the 8/31 boundary today, and put the coverage check in CI. Then recompute permanent design decisions at $3 / $15, and pull whatever heavy one-off processing you can into the discount window. That removes the future where your forecast is silently a third too low on the morning of September 1.

Discounts come with end dates. Giving your data structures a place to store those end dates is what makes a discount safe to use at full speed. If you are juggling your own dated announcements, I hope this design saves you a September surprise.