DeepSeek AI Model Provider

DeepSeek publishes open-weight reasoning and chat models that land close to the US frontier labs on most practical benchmarks while costing a fraction as much per token. For a chatbot answering thousands of questions a month, that difference is not a rounding error - it is often what decides whether AI answers ship at all.

The obstacle, until now, has been plumbing. Most guides for building a DeepSeek chatbot hand you a Python script, a Flask server and an afternoon of work, or walk you through wiring the API into a React app you then have to host, monitor and secure. That is fine if you are a developer building a side project. It is the wrong shape entirely if what you need is a working chat widget on a business website by Friday.

Conferbot treats DeepSeek as a provider you select, not an integration you build. Paste your own API key, choose DeepSeek from the provider list, and every AI node in your flow - answers, knowledge base retrieval, the AI agent - runs on DeepSeek. The visual builder, widget, inbox, analytics and human handover stay exactly the same.

Selecting DeepSeek changes which model generates text. It does not drop you into a reduced version of the product, which is the usual trade-off when a platform bolts on a second provider. All of this runs on DeepSeek once selected:

• Free-text answers - the visitor asks in their own words and the model answers from your content rather than from a scripted branch.
• Knowledge base retrieval - upload documents or point at your site; retrieval is handled for you.
• The AI agent - multi-step conversations that decide what to ask next instead of following a fixed script.
• Intent classification - routing to the right branch, team or queue based on what the visitor actually wants.
• Summarisation on handover - when a conversation reaches a human, the model writes the summary the agent reads first.

What does not change is everything outside the model: the drag-and-drop flow, deployment channels, unified inbox, ticketing, analytics and template library. That separation is the point - the model is a setting, not an architecture.

DeepSeek exposes an OpenAI-compatible chat completions endpoint at https://api.deepseek.com. That compatibility is why support is a configuration entry rather than a bespoke integration: request and response shapes are the ones the OpenAI SDK already speaks, so the same client works with a different base URL and key.

Getting a key

Keys are issued from the DeepSeek platform console. Create an account, add credit, generate a key. Conferbot never proxies through a shared key - the key you paste is the key your conversations bill against, so your usage, rate limits and data-retention terms are between you and DeepSeek.

How the key is stored

Provider keys are encrypted at rest and scoped to a single workspace. They are never exposed to the browser, never logged in plaintext, and never shared between workspaces or providers.

Rate limits and failure behaviour

DeepSeek enforces its own rate limits on your account. When a request is throttled or the endpoint is unreachable, the flow need not dead-end on the visitor: configure a second provider and the conversation continues. This is the practical argument for setting up two providers even if you only intend to use one.

Reasoning models and latency

DeepSeek's reasoning models think before answering, producing better results on multi-step problems and measurably slower first tokens. For a support bot answering factual questions the chat model is usually the right default. Reserve the reasoning model for flows that genuinely work something out - eligibility checks, troubleshooting trees, quote calculations.

End to end this takes a few minutes, and none of it involves a terminal.

1. Get a DeepSeek API key

Sign in to the DeepSeek platform, add credit, generate a key. Copy it - the console will not show it again.

2. Start from a template or a blank flow

Open the visual builder and either start from a ready-made flow or drag out your own. The flow is provider-agnostic, so this step is identical whichever model you end up running.

3. Select DeepSeek as the provider

In the chatbot's AI settings, choose DeepSeek, paste the key, pick a model. If the bot already ran on another provider, this is the only change - flow, content and widget are untouched.

4. Test against real questions

Use the preview to run the questions your visitors actually ask, not the ones you wish they asked. Model choice changes tone and length noticeably; this is where you tune the system prompt.

5. Publish and embed

Publish, then paste the one-line embed snippet before the closing body tag of your site. The same bot can also go out to your other channels without rebuilding it.

Nearly every guide to building a DeepSeek chatbot is a developer tutorial: Flask and Python, a React front end, or Streamlit. Those are legitimate, and if you are building a product on top of DeepSeek they are the right call. They deserve an honest comparison, because the API call is the easy part and everything around it is not.

What the tutorials give you

A working chat loop against the DeepSeek API, usually in under a hundred lines. Total control over prompts, context and rendering. No per-seat cost. Run it locally with Ollama and you get complete data isolation.

What they leave you to build

• The widget - embedding, responsive layout, mobile behaviour, accessibility, and not breaking your site's CSS.
• Conversation state - who said what, across sessions and devices.
• Human handover - an inbox for your team with the transcript attached. This is where most self-built bots stall.
• Retrieval - chunking, embedding and searching your own content so answers stay grounded.
• Key security - keeping the API key off the client, which a surprising number of tutorials get wrong.
• Analytics - which questions get asked, where people drop off, what the bot failed to answer.
• Abuse controls - rate limiting, so a scraper does not spend your token budget overnight.

The honest split: build it yourself when the chatbot is the product, or when you need model behaviour a platform will not expose. Use a platform when the chatbot is a channel into a business that already exists, and the value sits in the handover, the inbox and the analytics rather than the chat loop.

Conferbot supports all of these, so this is not a permanent decision. Run different providers on different bots and change your mind later without rebuilding a flow.

Cost

DeepSeek is the cheapest of the four per token by a wide margin, which matters most on high-volume support bots answering the same question thousands of times a month. On a low-volume lead bot, model cost is dwarfed by everything else and should not drive the decision.

Reasoning

DeepSeek's reasoning models are genuinely strong on multi-step problems. If your flow does eligibility logic, troubleshooting or anything resembling arithmetic, test them against the alternatives on your own questions rather than on a benchmark table.

Tone and instruction-following

This is where models differ most in practice and where benchmarks help least. Claude tends toward careful, longer answers; GPT toward concise, confident ones; DeepSeek sits closer to GPT but is more literal about system prompts. Run the same twenty questions through each and read the outputs - a twenty-minute exercise that beats any comparison table, including this one.

Data residency and open weights

DeepSeek publishes open weights, so if you eventually need inference on your own hardware there is a path that does not involve rewriting your bot: point Conferbot at a self-hosted Ollama endpoint instead. Note the flip side - the hosted DeepSeek API is in China, which some data policies exclude outright.

Availability

No provider is up all the time. Configuring a second is the cheapest insurance available, and costs nothing until used.

DeepSeek publishes two families that matter for chatbots, and picking the wrong one is the most common setup mistake. The difference is not quality - it is whether the model thinks before it answers.

DeepSeek Chat - the default

A conventional instruction-tuned model. It answers immediately, which keeps first-token latency low and makes the widget feel responsive. For a support bot answering factual questions from a knowledge base, this is almost always the right choice, and it is what you should start with.

DeepSeek Reasoner - for flows that actually reason

Produces an internal reasoning pass before the visible answer. That improves multi-step problems measurably and costs you seconds of latency the visitor will feel as a pause. Worth it for eligibility checks, troubleshooting trees and quote calculations. Wasted on "what are your opening hours".

How to decide in practice

Ask whether a competent human would need scratch paper. If yes, use the reasoner. If the answer is a lookup, use chat. You can also mix: run the chat model for the main flow and switch to the reasoner on the one branch that needs it.

Context windows and cost

Longer context costs more per conversation because the whole knowledge base excerpt is billed on every turn. Grounding answers in a well-chunked knowledge base is cheaper and more accurate than pasting entire documents into the system prompt.

Open weights

Both families have open-weight releases, which is the escape hatch that matters later: if the hosted API stops suiting you, the same model can run on your own hardware through a self-hosted endpoint without redesigning the bot.

If you already have a bot running on GPT, moving it is a settings change rather than a rebuild. What takes the time is validating the change, not making it.

1. Add DeepSeek as a second provider first

Do not replace the working provider. Configure DeepSeek alongside it so you can compare and roll back instantly.

2. Clone the chatbot

Duplicate the bot, point the copy at DeepSeek, and leave the live one untouched. Your flow, knowledge base and content come with the copy.

3. Re-test the system prompt

This is the step teams skip and regret. DeepSeek follows instructions more literally than GPT, so a prompt tuned to nudge GPT often over-steers DeepSeek. Prompts written for GPT's conversational default frequently need explicit length and tone limits here.

4. Run your twenty real questions

Use actual transcripts from your analytics, not invented examples. Read both sets of answers side by side. Differences in length and tone surface immediately.

5. Cut over, keep the fallback

Point the live bot at DeepSeek and leave the previous provider configured as the fallback. You now have a cheaper primary and a proven secondary.

What does not need to change

The embed snippet, the widget styling, existing transcripts, your handover setup, integrations and every deployment channel. None of it is provider-aware.

Model choice changes tone more than it changes accuracy, and most disappointing results are prompt problems rather than model problems.

Be specific about length

DeepSeek will happily write four paragraphs where a chat widget needs two sentences. State the limit explicitly - "answer in under 60 words unless asked for detail" - because mobile visitors lose the input box behind long replies.

Define the refusal behaviour

Say what to do when the knowledge base does not cover the question. Without that instruction the model will attempt an answer. With it, you get a clean handoff to a human instead of an invented policy.

Give it the business context once

Who you are, what you sell, who is asking. Repeating this in every node wastes tokens; putting it in the system prompt once does not.

Avoid negative-only instructions

"Do not be robotic" gives the model nothing to aim at. "Write like a knowledgeable colleague, one idea per sentence" does.

Test the failure path deliberately

Ask the bot something it cannot know and watch what happens. That frame is the one visitors remember, and it is the fastest way to find a prompt that is too permissive.

Iterate against transcripts

Read what people actually asked in the inbox each week and fix the prompt against real failures rather than imagined ones.

The API call works on day one. These are the things that surface in week three.

Rate limiting under real traffic

DeepSeek enforces limits per account. A campaign that triples traffic can hit them, and without a fallback provider every AI node fails at once. Configure the second provider before the campaign, not during it.

Insufficient balance

Pre-paid credit runs out silently. The symptom is a bot that answered fine yesterday returning errors today. Set a billing alert in the DeepSeek console.

Invalid or rotated keys

Rotating a key without updating it in your chatbot's AI settings breaks every AI node while the scripted branches keep working - which makes it look like a content bug rather than an auth one.

Timeouts on reasoning models

Reasoner responses take longer. On a flow with aggressive timeouts this shows up as intermittent failures on exactly the hard questions the model was chosen for.

Context length overruns

Very large retrieved passages plus a long conversation can exceed the window. Well-chunked knowledge base content avoids this and reduces cost at the same time.

What still works when the model fails

Scripted branches, buttons, forms, integrations and human handover are all independent of the provider. A model outage should degrade the bot, not kill it - and that is a flow design decision you make in advance.

Cost per conversation and reasoning strength push DeepSeek toward particular shapes of business.

E-commerce support

Order status, returns policy and sizing questions repeat endlessly and are cheap to answer well. High volume is exactly where token cost decides whether AI answers ship. See the e-commerce chatbot patterns.

SaaS technical support

Multi-step troubleshooting is the flow shape reasoning models handle best and scripted trees handle worst.

Education and courses

Course selection and eligibility questions combine several answers before reaching a recommendation - genuine reasoning, at volume, on tight budgets.

Internal IT and HR desks

Lower stakes on tone, high sensitivity to cost, and a natural first place to try a new provider before pointing it at customers.

Where to be careful

Healthcare, legal and financial advice carry regulatory weight and the hosted API is in China. Either use a provider whose jurisdiction your policy accepts, or run open weights on your own hardware. This is a compliance decision, not a model-quality one.

Conferbot supports twenty-one providers, so the honest answer to "is DeepSeek right for me" is sometimes no. The switch costs one setting.

If China hosting is disqualifying

Run open weights on your own hardware through a self-hosted endpoint, or pick a provider in a jurisdiction your policy accepts.

If you need EU data residency

Mistral is a French company with EU-hosted inference and open weights on several models - the clearest GDPR story of any provider here.

If tone matters more than cost

Claude is the most careful and least likely to invent an answer when the knowledge base does not cover the question.

If latency is the priority

Groq and Cerebras serve open models on custom hardware fast enough that the bot feels instant.

If you want maximum breadth

OpenRouter reaches hundreds of models through one key with automatic failover.

Compare them properly

The full list, grouped by jurisdiction and open-weight status, is on the AI model providers page.

The flows where cost and reasoning characteristics actually change the decision:

High-volume customer support

Deflecting repetitive questions is where per-token cost compounds fastest. A bot answering ten thousand questions a month is exactly the case where a cheaper model turns a pilot into something finance approves.

Qualification with real logic

Lead flows that check eligibility, combine several answers or calculate an indicative quote benefit from a reasoning model in a way simple FAQ flows do not.

Troubleshooting assistants

Multi-step diagnosis - asking the next question based on the last answer - is the shape reasoning models handle best and scripted trees handle worst.

Internal tools

HR and IT bots have lower stakes on tone and higher sensitivity to cost, making them a sensible first place to try a new provider before pointing it at customers.

Choosing a provider is a small part of shipping a chatbot. These come with it:

• Visual flow builder - drag-and-drop branches, conditions and integrations, with AI nodes wherever you want generation rather than a script.
• Knowledge base - upload documents or point at your site; answers cite your content instead of inventing it.
• Human handover - a shared inbox with the transcript attached, on every plan including the free one.
• Multi-channel deployment - the same bot on your website, WhatsApp, Telegram, Messenger, Instagram, Slack, Discord, LINE and Teams.
• Analytics - drop-off by node, unanswered questions, handover outcomes.
• Templates - a library of complete flows to start from rather than a blank canvas.

There are two costs, billed separately by two different companies.

What DeepSeek charges

Token usage, billed by DeepSeek against your own API key at their published rates. Conferbot does not mark this up, resell it, or take a cut - your key, your account, your invoice.

What Conferbot charges

A conversation-based plan starting free with 600 conversations a month. A conversation is an entire session, not an individual message, so a visitor asking six follow-up questions counts once rather than six times.

Why the split matters

Bring-your-own-key means a cheaper model actually makes your bot cheaper. On platforms that bundle AI into per-message pricing, switching to a cheaper provider saves the vendor money, not you.

Key storage. Provider API keys are encrypted at rest, scoped to one workspace, never exposed to the browser and never written to logs in plaintext.

Where conversations go. With DeepSeek selected, prompt and completion traffic for AI nodes goes to DeepSeek's API, hosted in China, under your account and their terms. Read their data-retention policy directly before sending customer data - it is their policy, not ours, and for some organisations this alone rules the hosted API out.

What stays with us. Transcripts, contacts and analytics live in your Conferbot workspace regardless of provider, so changing model does not move or re-key your history.

Self-hosting. If your requirement is that inference never leaves your infrastructure, DeepSeek's open weights can be served through a self-hosted Ollama endpoint and selected from the same provider setting.

• Test on your own questions. Twenty real visitor questions tell you more than any benchmark. Model choice changes tone more than accuracy.
• Be explicit in the system prompt. DeepSeek follows instructions literally. Vague guidance produces vague answers; a specific brief produces a specific voice.
• Use the chat model by default. Reserve reasoning models for flows that genuinely reason - they are slower, and first-token latency is what visitors feel.
• Ground answers in a knowledge base. Retrieval reduces invention far more reliably than telling the model not to invent.
• Configure a fallback provider. It costs nothing until an outage, and an outage without one is a dead chat widget.
• Always offer the human. The exit to a person is the most important node in the flow, whichever model sits behind it.

The free plan includes 600 conversations a month, the visual builder, knowledge base, human handover and every deployment channel - no credit card, no expiry. Bring a DeepSeek key and the AI nodes run on DeepSeek from the first conversation.

Still deciding between providers? Configure two. Running the same flow against DeepSeek and against GPT or Claude on your own questions is the fastest way to settle it, and leaves you with a fallback configured either way.