Price-change notice: 14 days, 30 days, or nothing at all
Fourteen days, thirty days, thirty days, and none at all. In one week this August, one provider cancelled an increase it had already announced and another rebuilt its whole price sheet on three days' notice — and both acted entirely within their own terms. Here are the four clauses side by side, where each one is buried, and what the floor means for how often you should re-check a price.

Four providers, four different answers, and none of them are on the pricing page you bookmarked. OpenAI: 14 days. Anthropic: 30 days, or whenever you receive notice, whichever comes first. Google: 30 days — except for new paid services, which can start charging immediately. DeepSeek: nothing committed, and it says so plainly, recommending you check the page yourself.
That spread is not a story about generosity. It is a number you can put into an operations schedule, and this month gave us both ends of it in the same week.
The four clauses, side by side
Every row below was read from the provider’s own legal page. The wording is quoted, not paraphrased.
| Provider | Committed notice | Where the clause lives |
|---|---|---|
| OpenAI | 14 days | Services Agreement §6.6, titled Corrections |
| Anthropic | 30 days or on receipt of notice, whichever is earlier | Commercial Terms §H.1, Payment of Fees |
| 30 days, unless otherwise specified | Gemini API Additional Terms, Payment Terms | |
| DeepSeek | None committed | Pricing page |
The exact language matters more than the number in at least three of these.
OpenAI — “Price changes on the Pricing Page will be effective fourteen days after they are posted. OpenAI has the right to correct pricing errors or mistakes even after issuing an invoice or receiving payment.” Both sentences sit in the same clause, and that clause is headed Corrections. Fourteen days is the shortest committed window of the four, and the second sentence means an invoice you have already paid is not necessarily final.
Note what this clause is not. Elsewhere in the same agreement, §16.13(a) promises thirty days before an update that materially affects your rights takes effect — but that governs changes to the agreement. Price changes run on §6.6’s fourteen days. Reading the thirty across is an easy and expensive mistake.
Anthropic — “Anthropic may update the published rates, to be effective the earlier of 30 days after the updates are posted by Anthropic or Customer otherwise receives Notice.” The earlier of is doing real work here, and it cuts against the customer: if notice reaches you on day three, the change is live on day three. Thirty days is a ceiling on the wait, not a floor on your planning horizon.
Google — “Google may make changes to this pricing from time to time, effective 30 days after they are posted unless otherwise specified (or in the case of new Paid Services, where pricing takes effect immediately unless otherwise specified).” Two escape hatches in one sentence. Thirty days is the default, and a default is a different object from a commitment.
DeepSeek — “Product prices may vary and DeepSeek reserves the right to adjust them. We recommend topping up based on your actual usage and regularly checking this page for the most recent pricing information.” No period, and an explicit transfer of the monitoring duty to you. It is the most honest of the four, in the narrow sense that it describes what it will actually do.
There is a second finding in that table that has nothing to do with the numbers: finding the clause is harder than reading it. OpenAI’s is under Corrections, not Fees. Google’s is in Additional Terms rather than the main terms of service. If you have ever tried to answer “what notice are we owed?” for a procurement review, you already know that the twenty minutes go into locating the paragraph, not interpreting it.
Two directions in the same week
Clauses are theoretical until somebody uses one. This month, two providers moved in opposite directions, eight days apart.
Anthropic cancelled an increase it had already announced. Claude Sonnet 5 launched at $2/$10 per million input/output tokens, described as introductory pricing through August 31, with $3/$15 scheduled for September 1. The pricing page now reads:
The $2/$10 per million input/output token pricing for Claude Sonnet 5, announced at launch as introductory pricing through August 31, 2026, is now the standard price. The previously scheduled increase to $3/$15 per million input/output tokens on September 1, 2026 will not occur.
An announced increase, withdrawn, with the introductory rate becoming standard. Far more than thirty days of effective notice — in the customer’s favour, since the notice was of a change that then didn’t happen.
DeepSeek rebuilt its price sheet on three days’ notice. The official changelog entry is dated August 13 and states that the new prices “will take effect at 16:00 (UTC Time) on August 16, 2026.” Three days from announcement to a structural change: peak/off-peak pricing, with off-peak at half of peak, and peak hours running 01:00–04:00 and 06:00–10:00 UTC on weekdays.
Three days is fully compliant with DeepSeek’s own terms. That is the entire point. There is no violation here and no bad actor — the company published no notice period, gave three days anyway, and did exactly what its published terms permit. The floor was available, and it got used.
What makes the pair instructive is that neither behaviour was predictable from the provider’s reputation, and both were predictable from the clause. One provider’s contract floor was low and the floor is where the price change landed. Another’s was thirty days and the change went the other way entirely.
What the floor actually buys you
Translate the clause into the only operational question it answers: how long can a cached copy of this provider’s price sheet be wrong before you find out?
| Provider | Contract floor | Longest safe gap between checks | The catch |
|---|---|---|---|
| OpenAI | 14 days | Weekly | Under-billed forecasts; §6.6 also permits post-invoice correction |
| Anthropic | 30 days, or on notice | Weekly, plus a notice inbox somebody reads | Notice can arrive well before day 30 and start the clock |
| 30 days by default | Bi-weekly, plus a check when adopting a new paid service | A newly adopted paid service can price immediately | |
| DeepSeek | None | Daily, or automated | Sole safeguard is your own polling |
Two of those rows are not about frequency at all. Anthropic’s says a notification channel matters more than a calendar — the thirty days can be cut short by a message nobody read. Google’s says the risk concentrates at adoption time, because the immediate-effect carve- out applies to new paid services rather than to price movements on existing ones.
And DeepSeek’s row is the one worth sitting with. Where there is no committed period, your review cadence is the notice period. There is nothing else.
A concrete illustration of what a stale sheet does. DeepSeek V4 Flash now prices every line twice:
| deepseek-v4-flash, per 1M tokens | Off-peak | Peak |
|---|---|---|
| Cache-hit input | $0.007 | $0.014 |
| Cache-miss input | $0.22 | $0.44 |
| Output | $0.66 | $1.32 |
Peak runs 01:00–04:00 and 06:00–10:00 UTC on weekdays — that is 02:00–05:00 and 07:00–11:00 in London, 21:00–00:00 and 02:00–06:00 US Eastern (previous day), and 09:00–12:00 and 14:00–18:00 in Beijing and Singapore. Where your team sits decides whether this change is a rounding error or a doubling: for an Asian working day it covers essentially the whole of it.
Any cost model built before August 16 has a single number where there are now two. The model is not slightly off — it is missing a dimension.
Compute the delta yourself
Reported percentage increases for this change have circulated widely. We are not quoting them, for a plain reason: they cannot be reproduced from the current price sheet. You cannot tell which two prices are being compared or what the baseline was, which makes the number unusable for a budget.
What you can do instead: take your own mix of the three lines above, multiply by the current prices, then weight by the share of your calls that actually land in the peak window. That is your increase, and it will not match anyone else’s — under peak/off-peak pricing, the delta depends on when you send requests, so two teams with identical volume can land in very different places.
If you do not know your peak share, that is itself the finding. Bucketing a week of request timestamps by UTC hour is a short query, and it is the input every subsequent decision here needs.
Review cadence belongs in a scheduler, not in a habit
If the notice period is a per-provider constant, then a single global refresh interval for every price sheet you hold is wrong by construction — too eager for one provider, too slow for another, and silently too slow for whichever provider commits to nothing.
This is the sort of thing that should be configuration rather than discipline. PiRouter’s pricing layer is designed to hold per-provider price snapshots with their own review cadence, so a provider with no committed notice period is polled on a schedule that reflects that, rather than inheriting whatever interval suited a provider with a thirty-day floor. This is a design direction, not a shipped guarantee — the routing docs show what is live today.
You do not need any of that to act on the table above, though. A calendar reminder and a diff against the provider’s published page will catch the same class of surprise.
The one-paragraph version
Four providers publish four different commitments, and they do not line up with reputation, size, or price. The clause is rarely where you would look for it: under Corrections in one case, in a secondary terms document in another. This month proved the floor is not decorative, when one provider restructured its entire price sheet three days after announcing it and stayed comfortably within its terms.
If these four are your whole list, copy the third column of the table above into your cost model and you are done. If you use anyone else, go find their number once — and budget twenty minutes for locating the paragraph rather than reading it.