A model price-change notice arrived. What should you change?

A provider’s price-change notice is a reason to check a workload, not an instruction to change its route. The useful question is: Which charges apply to our account and workload, from when, and what decision does the evidence justify?

For an Australian professional-services team, the answer may be to monitor the change, revise a budget, run a bounded test or seek approval for a routing change. If essential facts are missing, hold the decision rather than substituting a promotional price.

Start here

• Check applicability: separate the announcement from its effective terms and your account’s rate schedule.
• Isolate the price effect: apply the old and new rates to the same workload.
• Test uncertainty: vary the assumptions, record the decision and check subsequent billing.

Separate the announcement, effective terms, schedule and bill

Keep four distinct fields in your decision record:

Field	What to establish	What it does not establish
Announcement	When the provider published the notice, and what it said	That new rates already apply
Effective terms	Start date, time zone, eligibility and transition conditions	That your account qualifies or has been charged
Applicable schedule	Exact service, model, account, tier, charge categories and period	Your workload’s actual cost
Billed usage	Usage and charges recorded for your account after the effective date	Whether the resulting work was acceptable

For example, DeepSeek’s Introducing DeepSeek-V3 is a historical announcement. Its API pricing update said V2 pricing remained until 8 February and announced distinct later rates for cache-miss input, cache-hit input and output.

The page says “Feb 8” without a year. The retained notice does not establish the year of that transition. Its figures document a historical announcement; they are not current prices or proof of what a customer was subsequently billed. A promotional “best value” comparison is not evidence for a present purchasing recommendation.

DeepSeek’s Models & Pricing page, when checked on 9 October 2026, listed named models and separate cache-hit input, cache-miss input and output rates, with peak/off-peak terms and a warning that prices may change. Its model names and conditions differed from the historical notice.

Use that living page as a recheck target, not a fixed tariff for an enduring budget. Neither page establishes that the historical V3 model is available on your present route.

Identify the affected workload

Before calculating, record:

• The service, exact model identifier and route currently used.
• The account, tier, billing currency, charging units, credits and discounts.
• The effective date, time zone and any eligibility or time-window conditions.
• The relevant usage period and each applicable charge category.
• Whether you are repricing an existing arrangement or considering a different model or route.

A different route needs separate authorisation and testing. A rate notice alone supplies neither.

Keep input hits, input misses and output quantities separate. Use observed quantities where available; treat an unverified cache mix as an assumption. Do not assume repetitive-looking prompts all qualify for a cache-hit rate.

Match the worksheet to the service. The example below has three token-charge categories. If your arrangement also charges for cache writes, tools or other services, add those categories under their applicable rules without double-counting them.

For caching eligibility and charge treatment, see When does prompt caching save money? The narrower task here is to establish how a changed schedule affects a specified workload.

Compare equivalent work

First apply both schedules to the same quantities. This isolates the rate effect.

Then examine changes in usage separately. A busy post-change week may cost more than a quiet pre-change week even if every rate falls. Conversely, reduced usage can conceal a rate increase.

Record currency conversion and tax treatment explicitly. A public price in US dollars is not an Australian-dollar invoice. Retain the conversion method and date where relevant, and keep estimates distinct from reconciled charges.

A fictional before-and-after worksheet

Every rate, volume, outcome and labour assumption below is invented. The amounts are in AUD for arithmetic only—not DeepSeek prices, a quotation, an observed bill or a proposed production route. No currency conversion, GST adjustment, credits or discounts are modelled.

Assume one cohort of 900 distinct submitted tasks, each seeking one accepted output:

• There are 1,000 attempts: 900 first attempts plus 100 retries.
• Across all attempts, usage totals 1 million cache-hit input tokens, 2 million cache-miss input tokens and 0.6 million output tokens. These totals already include retries.
• All 900 tasks ultimately produce one accepted output each. None remains held, rejected, pending or withdrawn.
• There are 60 five-minute human reviews. For this simplified example, these are the only costed human activities.
• The hypothetical internal costing rate is AUD24/hour, making each five-minute review cost AUD2.

The denominator is therefore 900 accepted task outputs, not 1,000 attempts. A retry does not create an additional accepted task.

Component	Fixed quantity	Invented before rate	Before cost	Invented after rate	After cost
Cache-hit input	1.0 million tokens	AUD0.20/million	AUD0.20	AUD0.30/million	AUD0.30
Cache-miss input	2.0 million tokens	AUD0.80/million	AUD1.60	AUD1.00/million	AUD2.00
Output	0.6 million tokens	AUD1.60/million	AUD0.96	AUD1.40/million	AUD0.84
Token charges	Same quantities		AUD2.76		AUD3.14
Human review	60 × 5 minutes	AUD24/hour	AUD120.00	AUD24/hour	AUD120.00
Included cost	900 accepted task outputs		AUD122.76		AUD123.14

The token calculations are:

• Before: 1 × 0.20 + 2 × 0.80 + 0.6 × 1.60 = AUD2.76
• After: 1 × 0.30 + 2 × 1.00 + 0.6 × 1.40 = AUD3.14
• Review: 60 × (5 ÷ 60) × 24 = AUD120

On these fixed assumptions, the rate change adds AUD0.38 to the period. Token charges rise by approximately 13.8%, while included cost rises by approximately 0.31% because review dominates this example.

Included cost per accepted task output moves from AUD0.1364 to approximately AUD0.1368—an increase of approximately AUD0.00042.

This does not establish that price changes are generally immaterial. It shows why the charging mix and cost boundary matter: the fictional output rate falls while both input rates rise.

The included cost covers only the listed token charges and costed reviews. It excludes other workflow services, setup, integration, subscriptions, maintenance, governance and overhead. Costed staff time is not necessarily an additional cash payment.

Test what might not stay fixed

Keep sensitivity cases separate so that a change in usage is not mistaken for a change in price.

Case 1: fewer input tokens receive the hit rate

Hold total input at 3 million tokens and output at 0.6 million. Shift 0.5 million input tokens from hits to misses:

Schedule	Calculation	Token cost
Before	0.5 × 0.20 + 2.5 × 0.80 + 0.6 × 1.60	AUD3.06
After	0.5 × 0.30 + 2.5 × 1.00 + 0.6 × 1.40	AUD3.49

The rate effect on this changed mix is AUD0.43, rather than the base case’s AUD0.38.

Under the new schedule alone, the poorer cache mix adds AUD0.35: AUD3.49 minus AUD3.14. Comparing AUD3.49 directly with the original AUD2.76 would combine the cache-mix change and the rate change.

All other base-case assumptions remain fixed in this sensitivity.

Case 2: more retries, more review and fewer accepted tasks

This is a separate, deliberately invented downside—not a forecast or a consequence established by the notice.

Keep the same 900 submitted tasks, but assume:

• Attempts rise from 1,000 to 1,200: 900 first attempts plus 300 retries.
• Aggregate token quantities rise by 20%, with the base-case hit/miss/output proportions unchanged. This assumes the additional attempts have the same average token mix; it does not reuse Case 1’s poorer cache mix.
• Five-minute reviews rise from 60 to 100, at the same AUD24/hour costing rate.
• 850 tasks are accepted and 50 are held or rejected at the cut-off. None is pending or withdrawn. Costs incurred on unsuccessful tasks remain included.

The calculation becomes:

Component	Calculation	Cost
Token charges at new rates	AUD3.14 × 1.20	AUD3.768
Human review	100 × AUD2	AUD200.00
Included cost	AUD3.768 + AUD200	AUD203.768
Cost per accepted task output	AUD203.768 ÷ 850	Approximately AUD0.240

Acceptance falls from 900/900 tasks (100%) to 850/900 tasks (approximately 94.4%). Dividing 850 by 1,200 attempts would measure something different.

To isolate the rate effect within this downside, apply the old rates to its same larger token quantities: AUD2.76 × 1.20 = AUD3.312. The new rates add AUD0.456 in token charges. The much larger difference from the base case also reflects extra work, extra review and fewer accepted outputs; it cannot all be attributed to pricing.

For a real decision, vary uncertain assumptions individually before combining them. Use observed ranges for cache mix, output length, retries, review time and acceptance. Keep the quality threshold unchanged.

For the full workflow-cost method, see What does an accepted AI result cost? This worksheet isolates a pricing decision; it does not replace that broader accounting method.

Choose a bounded response

Keep a short decision record with the notice and check dates, affected configuration, applicable terms, workload quantities, calculations, uncertainty, evidence gaps, owner, required approval and next review date. Use controlled account references rather than copying credentials or client content.

Response	When it fits	What to record
Watch	Applicability is established and the expected effect is within an agreed tolerance, or confirmed terms take effect later	Next check date or billing event
Budget	Applicable rates and representative usage support an estimate without requiring a route change	Revised range, assumptions and spending authority
Run a bounded test	Uncertain caching, retries, acceptance or review effort could change the decision	Approved workload, duration, cost limit, evaluation criteria and stop condition
Seek an authorised route change	A tested alternative meets quality and operational requirements	Evidence, policy owner and approval required before any change
Hold	Applicable terms, reliable usage, permitted model or authority cannot be established	The specific gap and evidence needed to resolve it

For candidate authorisation and routing policy, return to the parent routing guide. A marketing name or announcement is not routing approval.

Live-route failure and organisation-wide return on investment are separate decisions. Neither is resolved by this price comparison.

Check the first relevant bill

After the effective date, compare the applicable schedule and usage records with the first relevant bill. Check charge categories, rates, quantities, time windows, credits, conversion and tax treatment. Explain discrepancies before describing an estimate as a realised saving.

The useful chain is:

Notice → applicable terms → equivalent workload → uncertainty test → authorised decision → billing check

A defensible response may be to leave the route unchanged. What matters is that the decision follows evidence rather than the headline price.

Source and scope note

DeepSeek’s historical V3 announcement and living Models & Pricing page were checked against this guide on 9 October 2026.

The historical announcement is evidence of an announced change, not current comparative advice or proof of subsequent billing. The living pricing page and effective terms require a fresh check for the exact model, account, route, tier and period before a real pricing or routing decision.

No live account bill, Australian-dollar exchange rate, production route, provider support, cache hit or accepted-result workload was inspected for this guide. No Sanctum Router capability, catalogue identifier or live dispatch was tested. All worksheet rates, volumes, labour assumptions and outcomes are fictional.

Use the related guides below to record your assumptions, then verify the current terms for your exact model, account and route before making a pricing decision.