Skip to content

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Latest commit

 

History

2 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 

Repository files navigation

How to Access DeepSeek V4 Without a Chinese Phone Number

TL;DR: DeepSeek's own API console (platform.deepseek.com) currently requires phone-number verification to register, defaulting to a +86 (China) country code — confirmed by loading the live sign-up page directly. Because DeepSeek V4 is released under an MIT license as open weights, that registration wall only applies to DeepSeek's own platform, not to the model itself — any gateway or infrastructure provider that serves the open weights independently, or self-hosting it yourself, sidesteps it entirely. This piece covers what the sign-up wall actually looks like, three real ways around it, and a verified, current price comparison across DeepSeek's own listed rate and two gateways that re-serve the model (CometAPI, OpenRouter) — including where the numbers turn out less flattering for a unified API than a marketing page might suggest.

Key Takeaways

  • DeepSeek's own platform sign-up page currently shows "your region only supports phone-number registration," with the phone field defaulting to +86 — verified by loading the page directly rather than relying on secondhand reports, which vary in how current they are.
  • DeepSeek V4 being MIT-licensed and open-weight (not proprietary and API-only) is the reason a phone-free path exists at all — this wouldn't be possible for a closed model where the original provider is the only place to get inference.
  • Price is not a uniform advantage for either gateway checked here — one gateway is cheaper on the Pro tier, the other is cheaper on the Flash tier, against DeepSeek's own currently listed rate.
  • A "20% cheaper than official" claim is worth checking against the provider's current pricing page rather than assumed — the real gap, checked directly, turned out smaller than that for one of the models compared here.

What the Sign-Up Wall Actually Looks Like

Rather than relying on secondhand blog posts (which range from "DeepSeek dropped the phone requirement" reports from early 2025 to "still requires +86" reports from mid-2026 — a sign the policy itself may have changed more than once), the direct way to check is to load DeepSeek's own sign-up page.

Doing so shows this text above the registration form:

"Your region only supports phone-number registration; one DeepSeek account gives you access to all of DeepSeek's services."

The phone field defaults to the +86 country code. No email, Google, or GitHub sign-up option is presented on this form.

Two things worth being precise about here. First, the message itself says "your region," which implies the requirement may not be universal for every visitor — it's presented as region-dependent rather than a blanket global rule, though phone-only was what this specific check returned.

Second, this applies to DeepSeek's own hosted API console specifically — it says nothing about whether the model itself can be run or served elsewhere, which is the more useful question for a developer who just wants to call DeepSeek V4 from an app.

Why a Workaround Exists at All: DeepSeek V4 Is Open Weight

This is the detail that makes DeepSeek V4 different from a closed, single-source model.

DeepSeek released V4 under an MIT license, with weights published on Hugging Face. That means DeepSeek's own platform is one place to run the model — not the only place.

Any company with the infrastructure to serve a large open-weight model can do so independently of DeepSeek's account system entirely, with no interaction with DeepSeek's registration flow at any point.

This is a structurally different situation from, say, wanting to call GPT or Gemini through a workaround — those are closed models with exactly one provider, so a gateway calling them still ultimately depends on that provider's own account and terms.

For an open-weight model, a gateway or a self-hosted deployment isn't circumventing DeepSeek's sign-up process — it's simply not using DeepSeek's platform at all.

Three Real Paths, and What Each Actually Requires

1. A Unified API Gateway

Services like CometAPI and OpenRouter list DeepSeek V4 (both the Pro and Flash variants) in their model catalogs, reachable through a single API key and a standard OpenAI-compatible request format.

Registration on both is email, Google, or GitHub — checked directly against CometAPI's own quick-start documentation, which states account creation is "continue with Google, continue with GitHub, or enter your email or username," with no phone number in the flow.

This is the lowest-setup-effort path if an existing multi-model integration already exists, since no new authentication pattern needs to be built for DeepSeek specifically.

2. Self-Hosting the Open Weights

Since the model is MIT-licensed, running it directly via an inference server like vLLM is a legitimate option with no DeepSeek account of any kind involved.

The realistic constraint is hardware: DeepSeek V4 is a large model, and serving it at usable latency requires substantial GPU capacity — this is a meaningfully different cost and ops commitment than an API call, and is the right call mainly for teams that already run their own inference infrastructure or have a hard requirement to keep the model entirely in-house.

3. A Temporary or Virtual +86 Number

Third-party SMS-receiving services sell short-lived Chinese numbers specifically for OTP verification on sign-ups like this one.

This is the path most worth being cautious about: it's a workaround for a verification step the platform put there deliberately, account recovery becomes harder if the number is later recycled by the service, and some of these services report increasingly strict identity checks at higher spending tiers.

Worth knowing this option exists, not necessarily worth recommending it over the other two.

What It Actually Costs: DeepSeek's Own Rate vs. Two Gateways

Checked directly against DeepSeek's official API pricing documentation and each gateway's own model pages, current as of this writing:

DeepSeek official rate CometAPI OpenRouter
V4 Pro — input $0.435 / 1M $0.416 / 1M $0.435 / 1M
V4 Pro — output $0.87 / 1M $0.832 / 1M $0.87 / 1M
V4 Flash — input $0.14 / 1M $0.12 / 1M $0.09 / 1M
V4 Flash — output $0.28 / 1M $0.24 / 1M $0.18 / 1M
Registration Phone number, region-gated Email / Google / GitHub Email / Google / GitHub

A few things worth being direct about in reading this.

On the Pro tier, OpenRouter charges exactly DeepSeek's own listed rate — consistent with its known no-markup-on-per-token pricing — while CometAPI is a few percent cheaper on both input and output.

On the Flash tier, the pattern flips: OpenRouter is the cheaper of the two gateways on both input and output, not CometAPI.

Neither gateway is uniformly the cheaper option across both model tiers, which is worth knowing before assuming price as the deciding factor between them — the actual differentiator here is the registration flow, not cost.

Separately, one pricing page for a unified API (checked while researching this piece) advertised its DeepSeek V4 rate as "20% cheaper than DeepSeek's official pricing."

Checked against DeepSeek's current, live pricing page directly, the real gap for V4 Pro is closer to 4–5%, and for V4 Flash closer to 14% — still a real discount, but smaller than the advertised figure, apparently because the comparison was made against an older reference price rather than DeepSeek's current one.

Worth checking any "X% cheaper than official" claim against the provider's current pricing page directly rather than taking the percentage at face value.

One more detail from DeepSeek's own pricing documentation worth flagging: DeepSeek publishes a steep cache-hit discount on input tokens for both tiers (a small fraction of the cache-miss rate).

Neither gateway's own model page states whether that specific discount is passed through to gateway customers as of this writing — worth confirming directly if cached-prefix cost matters to a specific workload.

FAQ

Does DeepSeek's API require a Chinese phone number?

Loading DeepSeek's own sign-up page directly shows a phone-number-only registration form defaulting to +86, with text stating the requirement applies based on region. No email or OAuth option is presented on that form as of this writing.

Can I use DeepSeek V4 without going through DeepSeek's own platform at all?

Yes — because DeepSeek V4 is released under an MIT license as open weights, it can be run by any infrastructure provider or self-hosted directly, independent of DeepSeek's own account system.

Unified API gateways that list DeepSeek V4 in their catalog are one way to do this without building the infrastructure yourself.

Is a unified API gateway actually cheaper than DeepSeek's own pricing?

It depends on the specific model tier and gateway — checked directly, one gateway was a few percent cheaper on the Pro tier and the other was cheaper on the Flash tier, against DeepSeek's current official rate.

Price wasn't a uniform advantage for either gateway across both tiers.

Is it safe to buy a temporary Chinese phone number just to register?

It works as a technical workaround, but it comes with real downsides — account recovery risk if the number gets recycled, and reportedly stricter identity checks at higher usage — worth weighing against the no-phone-required registration that gateways and self-hosting both offer instead.

Conclusion

The Chinese phone number requirement is real, current, and specific to DeepSeek's own hosted platform — not a property of DeepSeek V4 the model itself, which ships open-weight and MIT-licensed.

That distinction is what makes a phone-free path possible at all: a unified API gateway or a self-hosted deployment isn't bypassing DeepSeek's registration process, it's simply not using DeepSeek's platform.

Between the two gateway options checked here, neither is uniformly cheaper — the deciding factor for most developers will be the registration flow itself (email/OAuth vs. a region-gated phone requirement) rather than a meaningful price gap either way.

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors