DEV Community

Cover image for DeepSeek Is Running Inside Your Favorite AI Tool – And Nobody Told You
Harsh
Harsh

Posted on

DeepSeek Is Running Inside Your Favorite AI Tool – And Nobody Told You

DevTools exposing hidden model providers

I was debugging a slow response in HuggingChat last Tuesday.

Standard stuff Open DevTools, check the Network tab, filter by Fetch/XHR, look at the API responses.

And then I saw this right there in the chat UI:

agentic with Kimi-K2.6 via 🤗 together
Enter fullscreen mode Exit fullscreen mode

HuggingChat showing Kimi-K2.6 model with DevTools open agentic with Kimi-K2.6 via together visible in the chat
HuggingChat showing exactly which model it's using - Kimi-K2.6 via Together AI No hiding This is what transparency looks like.

I stared at the screen for a second Kimi-K2.6 That's a model from Moonshot AI a Chinese AI company Not something HuggingChat built from scratch Just a third-party API call, right there in plain sight.

But here's the thing HuggingChat was being honest They show you the model name They show you the inference provider Right in the UI.

Then I checked some of the other tools I use every day.

That's when things got uncomfortable.


What the API Traffic Actually Shows

DeepSeek, Kimi, Qwen Chinese open-source models are everywhere right now In my case, HuggingChat revealed it was using Kimi-K2.6 Other tools hide DeepSeek or similar models in their API calls while their marketing pages talk about something very different.

I found multiple tools with proprietary claims that were actually calling DeepSeek, Qwen, and Kimi APIs The pattern was consistent: marketing said one thing, network traffic said another.

One tool's website says "frontier intelligence built from scratch" The API response says kimi-k2p5-rl-0317.

Another claims "self-developed AI, fully in-house" Network traffic shows deepseek-coder-v2.

A third markets itself as "next-generation proprietary model" DevTools reveals qwen-2.5-72b.

They had us in the first half.


Why This Actually Matters

Before you say "who cares what model is under the hood, if it works it works" let me push back.

It matters for your decision-making You're choosing between tools partly based on the claim that one has a better, proprietary model If they're both calling the same third-party API, that's not a differentiator. You're paying a premium for a wrapper.

It matters for your data If a tool says your data never leaves our servers but the API traffic shows calls to api.together.ai or api.moonshot.cn those are different servers In different countries. Possibly under different data protection laws This matters for enterprise use especially.

It matters for trust. A tool that misrepresents what model it's using makes you wonder what else in the product description is marketing fiction Pricing Data handling Capabilities All of it.

It matters for debugging When something gives weird or unexpected output, knowing the actual model helps enormously Why is this responding strangely to Chinese language inputs? is a lot easier to debug if you know it's routing to a Chinese model behind the scenes.


HuggingChat Is Actually the Good Example Here

I want to be clear about something: the screenshot that started all this HuggingChat showing Kimi-K2.6 via together is HuggingChat doing the right thing.

They show you the model They show you the inference provider They put it right in the chat UI No DevTools required No API snooping.

That's not hard to implement It's a design choice.

Showing the model says: we trust you to know what you're using

Not showing the model says: we'd rather you didn't think about this

HuggingChat should be the baseline The uncomfortable reality is that most tools don't meet it.


How to Check Your Own Tools (5 Minutes)

You don't need anything special. Just a browser and 5 minutes

Step 1: Open your AI tool of choice in Chrome or Edge

Step 2: Press F12 to open DevTools → go to the Network tab

Step 3: Filter by Fetch/XHR

Step 4: Ask something simple — "Explain Python in one line"

Step 5: Click the API request that fires. Look at the Response tab

Look for:

  • A model field in the JSON response
  • Third-party domains in the request URL: together.ai, openai.com, anthropic.com, moonshot.cn, deepseek.com
  • Model IDs in the payload — they look like kimi-k2p5-rl-0317 or deepseek-coder-v2 or qwen-2.5-72b-instruct

That's it. Five minutes. You'll know exactly what you're actually talking to.


The Broader Pattern

AI tools are in an awkward middle phase right now The underlying models are mostly commodities everyone is calling the same APIs from OpenAI Anthropic Together AI Moonshot Mistral DeepSeek The real differentiation is supposed to be in the product layer: the UX the context handling the integrations the workflow.

But some companies are still trying to compete on the model itself And when they can't build one, some just... say they did Put "proprietary" in the marketing Hope no one opens DevTools.

Most people don't check. You're busy. The tool works. Move on.

But it works and it's honest with you about what it is are two different things And the second one matters more than the industry currently acknowledges.

The tools that are transparent about their models tend to be transparent about other things too pricing, limitations, data handling Honesty compounds. So does opacity.


One Question Before You Go

Open DevTools right now on the AI tool you use most.

Check the Network tab Find the model name in the API response.

Is it what you expected?

I'll share exactly what I found in my daily tools in the comments —including the ones that surprised me.

Your turn. 👇

Top comments (35)

Collapse
 
itskondrat profile image
Mykola Kondratiuk

I’d push back a bit on ‘nobody told you’. most tools do surface model info somewhere, just not prominently. the actual transparency gap is data residency and inference logging - that part genuinely isn’t disclosed.

Collapse
 
harsh2644 profile image
Harsh

Fair pushback and honestly, you're right.

Let me clarify: by 'nobody told you I meant nobody puts it in the marketing or the UI front and center You can find it if you dig through docs or API responses. But that's kind of the problem it should be obvious, not hidden.

That said, your point about data residency and inference logging is exactly right and honestly an even bigger issue than model names Where does my code actually go? Who logs my prompts? Those answers are almost never disclosed.

Appreciate you adding this genuinely makes the discussion better. 🙌

Collapse
 
itskondrat profile image
Mykola Kondratiuk

That gap between technically available and front and center is a product design choice that reveals priorities. You are right that inference logging is the sharper version of this - where data lives and what gets retained matter more than whether the product page names the underlying model.

Thread Thread
 
harsh2644 profile image
Harsh

A product design choice that reveals priorities that's going to stick with me You're right on all counts And I'm genuinely glad you pushed back earlier it made the discussion better

Thanks for this. 🙌

Thread Thread
 
itskondrat profile image
Mykola Kondratiuk

that framing helped me think it through too — sometimes the cleaner articulation only emerges after the pushback. good thread.

Collapse
 
k501is profile image
Iinkognit0 • Edited

Hello and thanks for your Post, "DeepSeek Is Running .... " - Everywhere, or let me state it Clearly : Chinese AI is Everywhere, and they do Scan, Scrape, Observe, Understand, Connect, Everything Online Very fast. As i started the Development of K501 and made some Public Post for example, I got Email, LinkedIn post where Generated, Chain of News and other Chinese Websites , Reposted and Referenced K501 within Days, BUT NO OTHER EXTERNAL REFERENCE OR RESONANCE was generated, just Chinese. Just about 2 weeks ago , i made a Google Search on K501 and a Chinese Website Generated a Post on the FLY, in an instance, with Time Stamp. ONE Second after my Google Search here is the Link : Chinese Instant POST of the Google search at : inf.news, well i do not know what to make or think out of this Experience, but i can State: Do not underestimate the Chinese AI Program ! .... So thanks for ya Post.... again @harsh2644

Collapse
 
harsh2644 profile image
Harsh

Thank you for sharing your K501 experience that's genuinely concerning The speed at which Chinese platforms indexed and referenced your work while others didn't is something.

I want to be careful here though The issue I'm highlighting in the article isn't 'Chinese AI bad it's about transparency Whether it's Chinese American or European models, developers deserve to know what's running behind the tools they pay for.

That said, your point about not underestimating Chinese AI is absolutely fair. They're moving fast and building great open-source tech (DeepSeek, Kimi, Qwen) The lack of Western equivalents in some areas is a real signal.

Thanks again for reading and sharing your story! 🙌

Collapse
 
k501is profile image
Iinkognit0

Thank you for your fast reply, and thanks for section "I want to be careful here though The issue I'm highlighting in the article isn't 'Chinese AI bad it's about transparency Whether it's Chinese American or European models, developers deserve to know what's running behind the tools they pay for." Transparency is so important, especially in these Times. So i agree , and i idid not wanted to judge anything, not Good or Bad, Not Big or Small. Itś just an Obseravation....

Thread Thread
 
harsh2644 profile image
Harsh

Really appreciate you saying that. 🙌 And totally understood your observation is valid and you shared it respectfully.

Collapse
 
embernoglow profile image
EmberNoGlow

It's +40 for you. How do you cope with the heat? It's +25 for me. Great article, btw. 🌞

Collapse
 
harsh2644 profile image
Harsh

Haha, +40 is brutal 🥵 Lots of cold water and AC But debugging API traffic keeps my mind off the heat 😅 Glad you liked the article🙌

Collapse
 
adamday75 profile image
adamday75

This was great and very insightful . Now I need to go check !

Collapse
 
harsh2644 profile image
Harsh

Thank you! 🙌 Let me know what you find when you check Would love to hear which tool surprised you (or didn't).

Collapse
 
motedb profile image
mote

The DeepSeek transparency issue is real. I ran into something similar when trying to audit which model was actually running behind an "AI assistant" for my drone's navigation stack — the abstraction layer made it impossible to verify latency guarantees.

Local models solve this, but they come with their own headaches: memory bandwidth constraints on edge hardware, quantization tradeoffs, and the fun of debugging a model that works perfectly on your dev machine but dies on the target device.

For my use case (robot navigation with real-time constraints), I've started treating model selection like embedded systems: the "best" model is the one that meets your constraints with headroom to spare. Sometimes that's a smaller model that actually runs at the speed you need.

What's your latency budget for the "favorite AI tool" use case?

Collapse
 
tahosin profile image
S M Tahosin

Spotting the underlying model in the DevTools XHR requests is top-tier debugging. It really shows how heavily these platforms are relying on API routing layers rather than their own native models to handle agentic tasks cost-effectively. It makes you wonder how many other "premium" wrappers are just routing to open-weight models behind the scenes!

Collapse
 
harsh2644 profile image
Harsh

Top-tier debugging thank you How many other premium wrappers are just routing to open-weight models behind the scenes? that's the question the article was circling. If one platform is doing it others probably are too. Not because they're malicious. Because it's cheaper Because it's easier Because most users won't check.

API routing layers instead of their own native models This is the invisible architecture. The user thinks they're talking to a premium model. They're actually talking to a router that decides which model to use. And that decision isn't always transparent.

Thank you for adding this it's the logical next question. 🙌

Collapse
 
mininglamp profile image
Mininglamp

The transparency angle is spot on. If tools secretly route to different backends, users lose the ability to reason about consistency. This gets more critical in multi-agent setups — when Agent A calls Agent B and both hit different undisclosed model backends, debugging failures becomes nearly impossible. Open-source model supply chains aren't just nice-to-have, they're infrastructure requirements.

Collapse
 
harsh2644 profile image
Harsh

This is such an important point thank you for making it.
I focused on the single-tool case (you vs the AI tool) But you're absolutely right: multi-agent systems make this 10x worse. If Agent A is routing to DeepSeek and Agent B to Kimi without disclosure debugging failures becomes guess which model caused this.

And yes open model supply chains aren't optional anymore They're infrastructure. Really appreciate you adding this layer to the discussion. 🙌

Collapse
 
klem42 profile image
Kirill

AI companies keep flexing frontier intelligence while users are like: "Cool, but can your app survive screen lock without muting audio?"

I think the industry is slowly discovering that models are becoming infrastructure. The real differentiation is moving upward: workflow design, UX, orchestration, memory, context management, reliability. Most users won't notice a five percent reasoning improvement.

Collapse
 
harsh2644 profile image
Harsh

This is such a smart take and the screen lock without muting audio line made me laugh because it's painfully true.

You've nailed it models are becoming like electricity or cloud compute Important, but nobody pays a premium just because you're using premium electrons The value is in what you build with it And you're absolutely right about the 5% reasoning improvement. Most users would trade a 5% accuracy bump for works reliably every time' without hesitation.

This is exactly the conversation I was hoping to start Thanks for this. 🙌

Collapse
 
motedb profile image
mote

The supply chain opacity is the real issue here. Most devs don't realize they're running DeepSeek weights even when the product branding suggests otherwise. It's not just a disclosure problem — it's an architectural one. When your latency profile suddenly changes, or behavior shifts after a provider update, you have no visibility into what changed underneath.

From a systems perspective, it's similar to undeclared transitive dependencies. You think you depend on Package A, but you're actually running Package C's behavior. The debugging surface expands invisibly.

I'd be curious whether any teams are building model-fingerprinting into their AI pipelines — something that can assert which weights are actually serving a request at inference time. Has anyone seen production-grade approaches to this?

Collapse
 
harsh2644 profile image
Harsh

This is such a sharp take and the undeclared transitive dependencies analogy is perfect. Every developer has been there You think you're using Package A, but Package A pulled in Package C and now you're debugging something you never explicitly imported AI tools are doing exactly the same thing. You think you're using Tool's proprietary model but it's actually DeepSeek or Kimi under the hood The debugging surface expands invisibly and latency/behavior changes become impossible to trace.

As for your question about model-fingerprinting in production: I haven't seen widespread adoption yet, but there's some interesting work happening in the open-source monitoring space (Langfuse, Helicone, etc.) They can capture model IDs from API responses The harder part is fingerprinting weights themselves knowing which version of DeepSeek you're hitting.

Would love to hear if you've come across any production-grade approaches yourself This feels like an emerging space that needs more attention.

Thanks for this genuinely one of the most insightful comments on this thread. 🙌

Collapse
 
sunychoudhary profile image
Suny Choudhary

This is the part people underestimate with AI tooling.

Most users think they are choosing one product, but behind the scenes the tool may route prompts through different models, providers, fallback systems, or cheaper inference paths. That is not automatically bad, but it changes the trust model.

If sensitive code, customer data, internal docs, or credentials are going into the tool, companies need to know where that data is actually processed and which model/provider handled it.

The issue is not “DeepSeek bad” or “model routing bad.” The issue is invisible routing without visibility, policy, or audit trails.

This is one of the areas we’re thinking about with LangProtect too: companies need a way to see what data is going into AI tools and enforce rules before sensitive information crosses the wrong boundary.

Collapse
 
harsh2644 profile image
Harsh

This is such a balanced and important framing thank you.

It changes the trust model, not automatically bad that's exactly the nuance most discussions miss. Routing and fallbacks aren't evil. Invisible routing without policy or audit trails is the problem.

Your point about enterprises needing to know where data actually goes is spot on. A startup might accept we use GPT-4 A bank or healthcare company needs to know: which model version? Which inference provider? Which geographic region? What's logged?

I didn't know about LangProtect just looked it up This is genuinely interesting. The enforce rules before sensitive data crosses wrong boundary angle is exactly what's missing in most AI governance discussions.

Would love to chat sometime about what you're building. Could be material for a follow-up piece on AI data governance (with credit, of course). No pressure just putting it out there.

Thanks for adding this. 🙌