DEV Community

MT_Notes
MT_Notes

Posted on

The August 31 Cliff: One of Those Three Deadlines No Longer Exists

The lead: a price increase that keeps getting reposted, months after it was cancelled

Six days to August 31. The date keeps coming up in developer channels because three things land on the same Monday: Moonshot's full platform sunset of kimi-k2.5 and the moonshot-v1 series, the retirement of GPT-5.4 and GPT-5.4 mini from ChatGPT-signed-in Codex, and the expiry of Claude Sonnet 5's introductory pricing, taking it to $3/$15.
The first two are real. The third was struck by Anthropic itself back on August 10. The pricing docs now say it plainly: the $2/$10 input/output rate "is now the standard price," and the increase to $3/$15 previously scheduled for September 1 "will not occur." The Sonnet 5 launch post carries a matching edit note from the same day.
Yet as of August 24, a fair number of industry dailies, migration checklists and "model retirement calendars" still list that price increase, unchanged, under August 31. That is the more interesting story. Once your architecture depends on four or five upstreams at once, model ID lifecycle becomes a real engineering surface — and the information on that surface is drifting systematically in secondhand sources.

1. Three deadlines, two of which actually break requests

Facts first, because "will error" and "you should migrate" are entirely different claims:

That second row is the one people misread. OpenAI's help center scopes it narrowly: the retirement applies to Codex sessions signed in with a ChatGPT account, and what needs updating is workspace defaults, saved model settings, managed configurations, custom agents and scheduled tasks. Codex authenticated with your own API key, and direct OpenAI API calls, are explicitly out of scope. So the same gpt-5.4 string may keep working fine in your CI script on September 1 while failing outright in a colleague's Codex scheduled task.
The Moonshot row is a plain wall. New accounts have been unable to select either family since K3 shipped on July 16; August 31 is the final close for existing users. Worth noting: K2.5's open weights on Hugging Face are unaffected — what is being retired is the hosted API, not the model. Teams that self-host can ignore the date entirely.

2. The quieter axis: the tokenizer, not the rate card

The Sonnet 5 increase was cancelled. Something else was not, and it appears on no pricing table.
Anthropic's docs carry a note that Claude 4.7 and later models use a newer tokenizer that "produces approximately 30% more tokens for the same text." The Sonnet 5 launch post narrows it: roughly 1.0x to 1.35x depending on content type. Simon Willison filled in that range by measurement — the same Universal Declaration of Human Rights went from 2,356 tokens to 3,341 in English (1.42x), 1.33x in Spanish, 1.28x for a 4,279-line Python file, and essentially unchanged in Simplified Chinese (1.01x).
Which means your cost model has two axes and most people watch only one. Per-token rates held steady, but the token count for identical text moved, so the invoice moves. Run it the other way: if your workload is mostly Chinese, that multiplier is close to 1, and the "+30%" you copied off someone's blog simply does not apply to you. The same multiplier also quietly shrinks the context window — a 1M-token window now holds less actual text.
The conclusion is simple and unglamorous: do not cite token counts someone else measured. Send your own real payload to both the old and new model, compare the returned input_tokens, and that delta is your budget correction factor.

3. The real cost of migration is model choice, not code

Kimi's API stays OpenAI-compatible, so at the code level migration is a one-string change. That is exactly the trap. The path of least effort is a global find-and-replace of kimi-k2.5 with kimi-k3 — and K3 is the $3/$15 flagship, roughly three times the tier k2.5 lived in. Route your entire legacy volume there and you are paying triple for calls that never needed frontier capability, for zero quality gain.
The right move is to split by workload: routine coding and chat go to kimi-k2.7-code, which is not on the retirement list at all; only calls that genuinely need frontier reasoning, native vision or the full ~1M context go to kimi-k3 — with prompt caching turned on there, since K3 cache-hit input runs $0.30 per million tokens against $3.00 uncached, one tenth.
Put differently, a "one string" migration actually requires you to answer three questions: where are all my call sites, what is the load shape at each one, and what is the marginal cost of each candidate ID. Most teams discover, six days out, that they cannot answer any of the three.

4. Landing it: collapse model IDs into one layer instead of scattering them through code

Every pain point above points at the same structural issue. Model IDs, upstream base URLs, auth schemes and billing units — if those four things live directly in your application code, then every upstream retirement is a repo-wide grep plus a regression pass.
This is what a model routing layer is for. Take wrouter.ai: once multiple upstreams sit behind a single OpenAI-compatible endpoint, you get three concrete things.
Stability. Your application knows one base_url. When an upstream changes endpoints, revises auth, or sunsets an ID, that is absorbed inside the routing layer rather than propagating into business code.
A complete model catalogue. Anthropic, OpenAI, Moonshot, Google and DeepSeek sit side by side on the same endpoint, so switching is one model field. That matters most during a deadline migration: you can fire the old and new IDs at real payloads, compare token counts and output quality, then decide — instead of changing blind and shipping.
Unified billing. No reconciling four rate cards in four different units, and no stitching a migration's cost delta together across four consoles.
Concretely, against that "don't cite someone else's token counts" conclusion:

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_WROUTER_KEY",
    base_url="https://wrouter.ai/v1",
)

payload = open("your_real_prompt.txt").read()

# One real payload, sent to the retiring ID and each migration candidate
for model in ["kimi-k2.5", "kimi-k2.7-code", "kimi-k3"]:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": payload}],
    )
    print(model, r.usage.prompt_tokens, r.usage.completion_tokens)
Enter fullscreen mode Exit fullscreen mode

Run it and you get three rows of numbers. Those three rows are your budget correction factor for this migration — considerably more applicable to you than any blog's "+30%". The same pattern crosses vendors: put claude-sonnet-4-6 and claude-sonnet-5 in the same loop and you have measured the tokenizer multiplier for your own content shape.

Closing

The real lesson of August 31 is not "remember three dates." It is that a model ID is an external dependency that expires, and that secondhand information about it is not trustworthy. A price increase the vendor cancelled two weeks earlier is still circulating as a to-do item, which tells you the information half-life in this space is shorter than most teams' migration cycles.
Three things you can do. Put each upstream's first-party deprecation page into your monitoring. Log which model ID every request actually used, so the next retirement is a diff you schedule rather than a fire you fight. And lift model IDs out of application code into a layer you control. The first two are discipline; the third is architecture.
If you are migrating for next Monday's two real deadlines, start by putting the old and new IDs behind the same endpoint and running that snippet against your own payload. Once you have the numbers, the decision makes itself.

Sources

Top comments (0)