# Claude Sonnet 5's Introductory Pricing Expires August 31. Your Cost Model Doesn't Know That Yet.

> Source: <https://dev.to/assili_salim_e3c07f9954de/claude-sonnet-5s-introductory-pricing-expires-august-31-your-cost-model-doesnt-know-that-yet-4e1j>
> Published: 2026-08-20 04:35:31+00:00

11 days from now, Sonnet 5 goes from $2/$10 to $3/$15 per million tokens. A 50% increase across the board.

If you built session budgets, cost estimates, or routing logic around the introductory rate — and you probably did, because it was the correct price when you set it — your cost model breaks on September 1. Not because of a bug. Because the price you hardcoded was always temporary.

Most stale pricing is drift: you hardcode a rate, the provider quietly reprices, your guard spends months being wrong without anyone noticing.

Introductory pricing is different. The price doesn't drift — it snaps. On a specific date. If your registry doesn't update before that date, it wakes up on September 1 with numbers that were accurate yesterday and wrong today.

Same bug. Different failure mode. Harder to catch because you *know* you set it correctly.

**Hardcoded model prices** — anywhere in your codebase that reads `sonnetInputPerM: 2.00`

. That number is wrong in 11 days.

**Session budgets calibrated to intro rates** — a $0.10 session budget built around $10/M output covers 10,000 output tokens. At $15/M, that same budget covers 6,667. Sessions that were comfortably within limit start breaching it.

**Capacity planning** — if your team estimated next quarter's AI spend using Sonnet 5 at $2/M, that number is 50% low for anything running after August 31.

**Routing decisions** — if your model router chose Sonnet 5 over an alternative because it was cheaper at $2/M, that calculation needs to run again at $3/M. The answer might be different.

``` js
// Before August 31
const MODEL_PRICES: Record<string, { inputPerM: number; outputPerM: number; expiresAt?: Date }> = {
  'claude-sonnet-5': {
    inputPerM: 2.00,
    outputPerM: 10.00,
    expiresAt: new Date('2026-08-31'), // introductory rate
  },
  'claude-opus-4-8': {
    inputPerM: 15.00,
    outputPerM: 75.00,
  },
};

// After August 31 — update this entry
'claude-sonnet-5': {
  inputPerM: 3.00,   // was 2.00 — introductory rate expired Aug 31
  outputPerM: 15.00, // was 10.00
},
```

The `expiresAt`

field is worth adding even if your framework doesn't consume it automatically. A comment that says "introductory rate" without a date gets ignored in sprint reviews. A field with a concrete date gets noticed.

```
function validatePricingRegistry(
  prices: Record<string, { inputPerM: number; outputPerM: number; expiresAt?: Date }>,
  asOf: Date = new Date()
): { expired: string[]; expiringSoon: string[] } {
  const sevenDaysFromNow = new Date(asOf.getTime() + 7 * 24 * 60 * 60 * 1000);

  const expired: string[] = [];
  const expiringSoon: string[] = [];

  for (const [model, pricing] of Object.entries(prices)) {
    if (!pricing.expiresAt) continue;

    if (pricing.expiresAt <= asOf) {
      expired.push(model);
    } else if (pricing.expiresAt <= sevenDaysFromNow) {
      expiringSoon.push(model);
    }
  }

  return { expired, expiringSoon };
}

// Run today:
const { expired, expiringSoon } = validatePricingRegistry(MODEL_PRICES);
// expiringSoon: ['claude-sonnet-5'] — expires in 11 days
```

Surface the result somewhere visible — a startup log, a Slack alert, a CI check. The goal is to make the expiration a planned update, not a billing surprise.

DeepSeek has announced a price increase with no specific date yet. If you're routing to V4-Flash or V4-Pro, flag it now:

```
'deepseek-v4-flash': {
  inputPerM: 0.27,
  outputPerM: 1.10,
  expiresAt: undefined, // increase announced, date TBD — watch DeepSeek pricing page
},
```

Not because you know when. Because flagging it as pending means you won't miss it when it lands.

August 2026 alone: Luna dropped 80% on July 30, Sonnet 5's introductory rate expires August 31, DeepSeek's increase is pending. Three of the most commonly deployed models in production — all with pricing changes in a single month.

This is the environment your cost model lives in. Model prices are not stable configuration. They're versioned inputs that need validation with the same discipline as anything else that drives business-critical calculations.

`@salimassili/ai-costguard`

keeps this in a centralized registry with unknown-model blocking — so when Sonnet 5's rate changes and your registry hasn't caught up yet, the first call surfaces the mismatch immediately instead of billing silently at the wrong rate for a month.

The introductory rate was always temporary. August 31 just makes the deadline concrete.