JTSTech Services
All articles

AI · August 16, 2026 · 9 min read

The “permanent” price cut lasted twelve weeks. Your AI bill now has peak hours.

At 16:00 UTC today, DeepSeek moved both its V4 models from one flat rate to peak and off-peak billing — the same flat rate it had made permanent in May. Output tokens roughly quadrupled at peak. The headline “up to 1,100%” is not the model price at all; it is the cached-input rate, the one thing teams were told to optimise for. If any part of your operation runs on metered tokens, the number in your business case is not a fixture.

Written by Jeremy Souffir Founder, JTS Tech Services

The short version: at 16:00 UTC on 16 August 2026, DeepSeek switched its V4-Flash and V4-Pro APIs from a single flat rate to time-of-day pricing — a peak rate and an off-peak rate at half of it. Reuters reported the increases as ranging from 50% to 1,100% depending on the model, the token type and the hour. The specific damage depends entirely on which of those you use: V4-Pro output went from $0.87 per million tokens to $1.98 off-peak and $3.96 at peak, while V4-Pro cached input went from $0.003625 to $0.044 at peak. The company's stated reason is to allocate resources more reasonably. What makes this worth your attention even if you have never used DeepSeek is not the vendor and not the amount. It is that this is the same flat rate the company made permanent in May, and that inference is now being sold the way electricity is sold — which changes what a schedule costs, not just what a token costs.

What exactly changed?

Worth being precise, because the coverage rounded this to “four times more expensive” and the real shape is lumpier than that. Every figure below is from DeepSeek's own published pricing table, per million tokens.

  • Two rates replaced one. Peak hours are 01:00–04:00 and 06:00–10:00 UTC. Every other hour is off-peak, priced at half the peak rate. There is no longer a single number to put in a spreadsheet
  • V4-Pro output: was $0.87 flat. Now $1.98 off-peak, $3.96 at peak — roughly 2.3× and 4.6× the old rate
  • V4-Pro input (cache miss): was $0.435. Now $0.66 off-peak, $1.32 at peak
  • V4-Pro input (cache hit): was $0.003625. Now $0.022 off-peak, $0.044 at peak — that is the 1,100% figure, and it is about twelve times the old rate
  • V4-Flash output: was $0.28. Now $0.66 off-peak, $1.32 at peak
  • V4-Flash input (cache miss): was $0.14. Now $0.22 off-peak, $0.44 at peak
  • The timing of the reversal. DeepSeek cut V4-Pro pricing by 75% as a promotion, then announced in late May that the discount was permanent. That “permanent” rate lasted under three months
Where the money actually goes in an agentic workflow: one user request fans out into many model calls — retrieval, reasoning, checking, correcting — before a single usable answer comes back. A rate change does not hit your bill once. It hits it once per call in the chain.
Where the money actually goes in an agentic workflow: one user request fans out into many model calls — retrieval, reasoning, checking, correcting — before a single usable answer comes back. A rate change does not hit your bill once. It hits it once per call in the chain.

The detail worth sitting with

The largest increase by far lands on cached input — the rate you pay when a prompt prefix has been seen before. That is not an obscure line item. Prompt caching is the single optimisation every provider has spent two years telling engineering teams to adopt, and the teams who listened hardest are the ones with the biggest system prompts, the most retrieved context and the highest cache-hit ratios. They restructured their applications around a rate that was two-thousandths of a cent, and it is now four-hundredths. The uncomfortable general lesson: an optimisation that depends on a discount is not an optimisation, it is a bet on the discount. Caching still saves you money against a cache miss — that ratio held. But if you sized a workload on the absolute number rather than the ratio, your model is wrong today.

We don't use DeepSeek. Why does this matter to us?

Fair question, and for most Canadian and US businesses the direct exposure genuinely is zero. Three reasons it still lands.

  • The cheap tier is what makes marginal automations viable. Nobody runs their customer-facing assistant on the lowest-cost model. But the unglamorous high-volume work — classifying inbound email, tagging products, normalising supplier data, drafting first-pass descriptions, summarising tickets — is precisely the work whose business case is thin enough that the token price decides it. That is the tier that just moved
  • Every provider watches every other provider. Cheap inference has been sold below cost as a customer-acquisition strategy across the whole market since 2024. The first major provider to reprice upward in public tells you the direction of the ratchet, and time-of-day billing is a template others can now copy without being first
  • You may be exposed through a vendor. If a SaaS tool, an agency-built feature or an internal app routes through an aggregator or a model gateway, you do not necessarily know which model served which request. Your invoice says one number; the model mix behind it can change without a conversation

The two conclusions that both get this wrong

The first is to shrug because the absolute numbers are small — $3.96 per million tokens still sounds like nothing next to a salary. It is nothing, right up until an agentic workflow makes forty model calls per task and runs a hundred thousand tasks a month, at which point a 4.6× move is the difference between a project that pays for itself and one that quietly does not. The second is to over-rotate into “AI costs are unpredictable, freeze everything.” That reasoning does not survive the arithmetic either. The long-run direction of inference pricing has been sharply down — Stanford's AI Index tracked GPT-3.5-level inference falling from roughly $20 per million tokens in early 2024 to about $0.07 by the end of that year — and the businesses that waited for the price to stop moving simply got two fewer years of compounding. The useful posture is neither. It is to build so that a price change is a config change and a re-run of the numbers, not a rebuild.

What does time-of-day pricing actually change?

This is the part with a genuinely practical answer, and it is the part almost nobody has done the timezone arithmetic on. Peak is 01:00–04:00 and 06:00–10:00 UTC. Translate that to Eastern time and it lands between roughly 9pm and 6am — which produces a result that is funny for about four seconds.

  • Your working day is off-peak. For a North American business, essentially every interactive request — the assistant answering a customer at 2pm, the tool a staff member is using at their desk — now falls in the cheaper window. That is a real and unearned break
  • Your overnight batch jobs are not. The nightly re-index, the 3am catalog enrichment run, the pre-dawn report generation — the work you deliberately moved to the small hours to be a good citizen — is exactly the work now sitting in the expensive window
  • Scheduling is now a cost lever, and it is the cheapest one you have. Moving a nightly job by a few hours costs you a cron edit and buys a 50% reduction on that workload. There is no engineering work in the world with a better ratio than that
  • Retries and backoff need a second look. A job that fails at 00:50 UTC and retries with exponential backoff can walk itself straight into the peak window and bill double for the privilege
  • “Realtime or batch?” is now a costed decision. Plenty of work that runs synchronously does so out of habit rather than requirement. If a result is genuinely needed within seconds, pay for it. If it is being looked at tomorrow morning, it can wait for the cheap window
The same workload, two schedules. Interactive traffic follows the working day and now sits in the cheaper band; the batch jobs deliberately pushed into the small hours land in the expensive one. Nothing about the work changed — only the clock it runs against.
The same workload, two schedules. Interactive traffic follows the working day and now sits in the cheaper band; the batch jobs deliberately pushed into the small hours land in the expensive one. Nothing about the work changed — only the clock it runs against.

What should we actually check this week?

For most businesses this is an afternoon, not a project. The goal is a written answer somebody owns, not a general intention to keep an eye on it.

  • Find out what you actually spend, by workload. Not one line on a credit card statement — a number per automation. Most businesses running AI in production cannot answer “which of these costs the most” without going and looking, and that is the question every other decision here depends on
  • Write down the price assumption in each business case. If an automation was justified on “it costs about X per run,” find where X is recorded and put a date next to it. An assumption with no date attached is one nobody will ever think to re-check
  • Check what your scheduled jobs run against. List every cron, queue drain and nightly batch that calls a model, and note the hour. If your provider has introduced time-of-day rates, that list is your cheapest available saving
  • Confirm which model each workload actually uses. Including inside vendor tools and agency-built features. “Whatever the default is” is a real answer many teams would give, and defaults get changed by other people
  • Check you could switch. Not that you should — that you could. If moving a workload to another provider means rewriting application logic rather than changing a configuration value and re-running your evals, you do not have a supplier, you have a dependency
  • Set a floor and a ceiling alert on spend. A ceiling catches the runaway loop. A floor catches the automation that quietly stopped running three weeks ago and that nobody noticed because the only signal was a smaller bill
  • Re-run the ROI on anything marginal. Both directions. Some things that were viable are not any more; some things you shelved when they were expensive have since become obvious. We made the second half of that argument two weeks ago, when the cheap tier fell 80% — the maths cuts both ways, and the point was never the direction. It was that nobody goes back and checks

Why do AI budgets keep coming in over?

Because the per-token price and the total bill have been moving in opposite directions for two years, and most forecasting only tracks the first one. McKinsey's QuantumBlack team surveyed enterprise AI cost owners in May 2026 — a small sample of 75 respondents across five industries, so treat it as directional rather than definitive — and found that 93% had exceeded their AI budgets as agentic systems scaled, with about one in five having actively restricted AI use because of running costs. The most useful finding in it is not the overrun rate, though. It is where the money goes.

  • Roughly 60% of agentic AI spend is refinement, not the first answer. The checking, correcting and re-running an agent does before it produces something usable costs more than the initial call. If your forecast counted one model call per task, it was wrong by more than a factor of two before any price changed
  • Reasoning tokens are invisible in the estimate and visible on the invoice. Models that think before answering bill for the thinking, and the volume of it varies with how hard the question turned out to be — which is not something you can know in advance
  • Volume grows faster than price falls. This is the whole story in one line. Cheaper tokens make more use cases viable, more viable use cases mean more calls, and the bill goes up while the unit price goes down. That is a success condition, not a failure — but only if somebody is measuring the value alongside the spend

The genuinely encouraging part

Everything this asks of you is cheap, and most of it pays off regardless of what any provider does next. Knowing your cost per workload, keeping the model choice in configuration rather than in code, running evals you trust enough to switch on, and scheduling deliberately — that is a few days of work that makes the next price move, in either direction, a fifteen-minute decision instead of a quarter-long argument. And the businesses that have this in place are the ones that can move fast when the price falls, which it will again. Portability is not a defensive measure. It is what lets you take the next discount the week it appears rather than the year after.

Where we fit

The reason AI costs surprise people is almost never carelessness. It is that no single person owns the join between what the automation does, what it costs, and what it is worth. Your developers own whether it works. Finance owns the invoice, months later and with no breakdown. Nobody owns the sentence “this workflow costs us $340 a month and saves us eleven hours.” That is the sentence we exist to produce. An AI Ops Automation Sprint puts one named workflow into production in about three weeks with the cost model built in from the start — the model choice held in configuration so it can be swapped without a rewrite, evals that tell you whether a cheaper model would actually do the job, logging that shows spend per run rather than per month, and a number at the end that says whether it paid for itself. Retaining us for that means when a provider reprices overnight — as one did today — you already know which workloads are affected, what they are worth, and whether moving them is a config change or a conversation. Most businesses find that out the hard way, one invoice later.

Sources

Keep reading

AI Ops Automation Sprint

Could you say, today, what each of your automations costs and what it saves?

One named workflow live in about three weeks — the model choice held in config so it can be swapped without a rewrite, evals that prove a cheaper model still does the job, spend logged per run instead of per month, and a number at the end that says whether it paid for itself.