How to read news about an AI vendor you depend on

The story always arrives fully formed. A screenshot of a leaked transcript. A founder said to have admitted, privately, that his lab is behind and short of chips. Three reposts later the hedge has fallen off and the claim has become a number, and the number has become a reason to change something. You have a workload pointed at that lab’s model, so you open your config and start wondering.

This guide is about that decision rather than that story. It sorts the claims you meet about an AI vendor into the ones you can check before lunch and the ones nobody outside the company can check at all, and it names the three things that actually justify moving a workload. It is written for a solo operator or small team with a handful of API calls or a few subscriptions, not for someone running enterprise vendor risk. If you have a procurement process, a security questionnaire and a contractual SLA, you already have a heavier instrument than this and you should use it.

A claim about a lab’s insides is not a fact you can act on

Claims about an AI vendor come in two kinds, and the difference is not how interesting they are. It is whether you can verify them yourself.

The first kind is about the company: how many chips it has, how far behind it is, whether the funding round closed, what the founder said in a room you were not in. You cannot check any of it. Neither can the person who posted it, usually. In July 2026 DeepSeek verbally told prospective investors that agreements would not be signed as expected and that it was suspending a second funding round which had been seeking at least 10 billion yuan, after posts attributed to founder Liang Wenfeng went viral. Chinese media reported that in those posts Liang discussed a reliance on Nvidia chips and China’s persistent lag in AI sophistication relative to the US [8]. The reporting was explicit about its own limits: Bloomberg “hasn’t verified the authenticity of those posts, which concerned a transcript of a meeting Liang held with unidentified parties” [8]. That clause is the most important thing in the story and it is the first thing that gets dropped in the retelling.

The second kind is about the product, and all of it is checkable in a browser. As of today DeepSeek’s API exposes deepseek-v4-flash, deepseek-v4-pro and deepseek-v4-flash-vision-exp, all at 1M context with a maximum output of 384K tokens [1]. The DeepSeek-V4-Pro weights are on Hugging Face under the MIT licence, a mixture-of-experts model with 1.6 trillion total parameters and 49 billion activated [7]. Those facts took four minutes to confirm and they are the facts your setup actually rests on. A lab can be exactly as chip-starved as a leak says and still serve you a model that works today at a price you can read.

The discipline is to notice which kind of claim you are reacting to. If the claim is about the company’s insides, the honest position is that you do not know, and neither does the timeline, and no amount of reposting converts a rumour into a rate limit.

What the vendor puts in writing is the part you can hold it to

The most useful page on any AI vendor’s site is not the launch blog. It is the deprecation policy, because that is where the company states, in advance and in public, how much warning you get before something you depend on stops working.

Anthropic publishes a lifecycle with four states, Active, Legacy, Deprecated and Retired, and says it “notifies customers with active deployments for models with upcoming retirements, providing at least 60 days’ notice before model retirement for publicly released models” [2]. The same page lists what happened in practice: claude-opus-4-1-20250805 was deprecated on 5 June 2026 and retired on 5 August 2026, which is the policy being kept to the day [2].

OpenAI publishes longer minimums and splits them by model class: at least 6 months for generally available models, at least 3 months for specialised variants such as Codex and deep research models, and for anything with preview in the name, “much shorter notice, such as 2 weeks” [3]. It also prints the warning most people need and few read: “We don’t recommend using preview models for business-critical production workloads unless you can migrate on short notice” [3]. Google’s Gemini changelog does the same job in a different shape, as a dated log. Image generation models announced as deprecated on 15 June 2026 were shut down on 17 August 2026, roughly 2 months; gemini-3.1-flash-lite-preview, announced in the entry filed on 7 May 2026, was deprecated on 11 May and shut down on 25 May 2026, 2 weeks after the deprecation date [4].

Now set that against DeepSeek’s pricing page, which says: “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” [1]. That is not an accusation. It is a published difference in what has been committed to, and it tells you more about your real exposure than any leaked transcript can. One vendor has promised you 60 days. Another has promised you a page to check.

Compute pressure shows up in the price list and the rate limits

If a lab is genuinely short of capacity, you do not learn it from a screenshot. You learn it from the operational surfaces the company has to change to cope, and those are public.

DeepSeek’s pricing is the clearest example available. It charges different rates by time of day: peak hours are 01:00 to 04:00 and 06:00 to 10:00 UTC, Monday to Friday, and off-peak rates are half of peak [1]. For deepseek-v4-flash, 1M input tokens on a cache miss cost $0.44 at peak and $0.22 off-peak, with output at $1.32 and $0.66; deepseek-v4-pro runs $1.32 and $0.66 for input on a miss, and $3.96 and $1.98 for output [1]. The same page publishes concurrency limits of 2,500 for the flash models and 500 for pro [1]. A vendor that prices by the clock and caps your concurrency is managing scarce capacity in public, and it is doing so whether or not anybody leaks anything.

That is where to point your attention. A price rise, a tightened rate limit, a model quietly moved to legacy, a context window trimmed, a feature marked experimental: those are the things that change your costs and your code. They are announced on pages that exist for the purpose, and you can subscribe to most of them. Rumours about chip allocations are not a leading indicator of any of it, because a lab under pressure and a lab under no pressure both publish the same kind of page right up until the day the number changes.

Three signals justify moving a workload, and a story is not one of them

Move work off a model when one of three things happens, and not otherwise.

The first is a published price change you cannot absorb. Read it off the vendor’s own pricing page, put your actual monthly token volumes through it, and compare the total against the alternative at its published rates. Most price shocks turn out to be a rounding error on a small operation, and the ones that do not are obvious within a minute.

The second is a deprecation notice with a date attached. This is the only signal that comes with a deadline someone else set, so it is the only one where doing nothing has a guaranteed failure date. The vendors above all publish these in one place [2][3][4]. Put the shutdown date in your calendar the day the email arrives, not the week before.

The third is degradation you have measured yourself. Not “it feels worse lately,” which is unreliable in both directions. Count errors, latency and refusals in your own logs over a fixed window, and compare that window against the same window a month earlier. Then open the vendor’s status page before you conclude the model has changed, because an incident that hits everyone is not a reason to migrate, and a slowdown that hits only you is usually your own retry logic, your own prompt or your own concurrency ceiling. Your numbers decide; the status page only tells you whose problem it is.

Required disclosure is a floor, and it is not about your uptime

There is a legal layer under all of this now, and it is worth knowing exactly how far it reaches, because it is often invoked as though it settles more than it does.

The EU AI Act’s rules on general-purpose AI models became effective in August 2025, putting in place obligations on transparency and copyright for providers of those models, with an added duty to assess and mitigate risks for models that may pose systemic risks [5]. The Commission published a template for a public summary of the training content of such models, and from 2 August 2026 “the AI Office and authorities of the Member States are responsible for implementing, supervising and enforcing the AI Act” [5].

That is real, and it is narrow. It obliges a provider to publish a summary of training content and to document the model. It does not oblige anyone to tell you how many chips they have, how the funding round is going, or when the next model ships. Nothing in the disclosure regime would have confirmed or refuted the DeepSeek transcript, and nothing in it protects your Tuesday morning if an endpoint goes away. Regulatory transparency and operational reliability are different things that happen to share a word.

A fallback you have not run is a plan, not a fallback

Everything above collapses into one practical position: build the thing that makes vendor news boring, then stop reading vendor news closely.

Keep 20 real tasks from your actual work, with the inputs and the outputs you were happy with. That is your evaluation set. When you want to know whether a second model can carry your workload, run those 20 through it and read them, which takes an afternoon and settles the question that a benchmark table cannot. Do this before you need it, because the day you need it you will be choosing under pressure.

Switching is usually less work than it sounds, because the interfaces have converged. DeepSeek’s own documentation puts it plainly: “The DeepSeek API uses an API format compatible with OpenAI/Anthropic. By modifying the configuration, you can use the OpenAI/Anthropic SDK or softwares compatible with the OpenAI/Anthropic API to access the DeepSeek API” [6]. The OpenAI-format base URL is https://api.deepseek.com and the Anthropic-format one is https://api.deepseek.com/anthropic [6], which means the code change is often a base URL, a key and a model string. Keep those three in environment variables rather than inline, keep a working key with a second provider, and the migration becomes a config edit instead of a project.

For the strongest version of this, the weights themselves are an option for some models. DeepSeek-V4-Pro is published under the MIT licence, in a mixed precision where the mixture-of-experts parameters are stored in FP4 and most other parameters in FP8 [7]. That is genuine insurance against a vendor disappearing, and it is also 1.6 trillion parameters [7], which is not running on the machine under your desk. Treat open weights as proof the model cannot be recalled from the world, not as a plan you personally execute.

What still goes wrong

The honest limit of this method is that it is backward-looking. Published prices, notice periods and incident histories describe what a vendor has done and what it has committed to, not what it will do under conditions it has not met yet. A notice period is a policy, not a bond. OpenAI’s own page says that “If safety or compliance concerns require us to retire a model sooner, we will provide as much notice as reasonably possible” [3], and Anthropic’s 60 days is a commitment the company makes to itself [2]. Both have been kept so far. Neither is enforceable by you.

The second limit is that the unverifiable claim is sometimes true. A leak about compute scarcity might be accurate and might precede exactly the price rise or capacity squeeze you would have wanted six months of warning about. Refusing to act on rumour means occasionally acting late. The trade is deliberate: acting on every rumour means constant churn, re-testing and cost, most of it spent on stories that turn out to be wrong or irrelevant, and churn has a price you pay every time while the rumour only pays off occasionally.

The third is that fallbacks decay. The second provider you tested in March has shipped four model versions since, retired one of them, and changed its default behaviour on refusals. A fallback tested once is a fallback tested never. Re-run the 20 tasks quarterly, or at least whenever a deprecation email arrives, and accept that this is a small recurring cost of not being surprised. None of this applies if your dependency is a consumer subscription rather than an API, where the vendor can change the product under you with no notice policy at all and your only real lever is being able to leave.