DeepSeek API Guide: Python, Streaming & Costs (2026)

Updated October 2, 2026. DeepSeekagi.org is an independent publication and is not affiliated with DeepSeek. Model names, prices, and API behavior below were checked against DeepSeek’s official documentation on this date.

A useful DeepSeek integration needs more than a successful “hello” response. It needs a key that never reaches the browser, a deliberate choice about reasoning, a stream that can fail safely, and a bill you can explain. This DeepSeek API guide builds those pieces in order, using Python and the OpenAI-compatible Chat Completions interface.

There is an important freshness trap: older tutorials commonly use deepseek-chat or deepseek-reasoner. DeepSeek’s change log scheduled those names for discontinuation on July 24, 2026. Its current quick start uses deepseek-flash; the live model table also lists deepseek-v4-pro. Start with the current identifiers rather than trying to repair an outdated example. See the official change log and API quick start.

What you will build: a small server-side client, a normal text request, a streaming reader, a validated JSON extraction, a bounded retry policy, and a transparent cost calculation. The examples are original instructional code. They have been checked for Python syntax, but were not executed against a paid DeepSeek account; the token counts later in this guide are hypothetical, not benchmark measurements.

1. Choose your model and API interface

For the examples here, use deepseek-flash with thinking explicitly disabled for short extraction and summarization tasks. That is an economical starting configuration to evaluate, rather than a claim that it will win every quality test. Keep model selection in configuration so that you can compare a second model without rewriting business logic.

The current model table advertises a one-million-token context and a maximum output of 384K tokens. Treat these as ceilings, not sensible defaults for every request. Sending an entire document collection because it fits can increase processing time, cost, and the difficulty of inspecting the answer. For a support assistant, retrieve a few relevant passages and preserve their source identifiers; for a document summary, set an output budget that matches the document your user actually needs.

DeepSeek supports more than one wire format. This guide stays with Chat Completions because its message list is easy to inspect and its SDK interface is familiar. Set the OpenAI SDK base URL to https://api.deepseek.com; the resulting chat request goes to /chat/completions. DeepSeek separately documents an Anthropic-format base URL at https://api.deepseek.com/anthropic. These are provider endpoints, not URLs for the consumer chat website. See DeepSeek’s connection settings.

If you are migrating an existing Responses API application, do a capability review first. DeepSeek’s Responses guide describes a stateless implementation: previous_response_id, server-stored conversations, and background mode are unsupported. Several built-in tool types are ignored. Responses streaming also finishes with semantic completion, incomplete, or failed events, rather than Chat Completions’ [DONE] marker. A shared SDK does not make those contracts interchangeable. Source: DeepSeek Responses API compatibility.

Before a release, verify that your chosen identifier appears in the authenticated GET /models response. The current model-list reference describes capability metadata as well as IDs. Record the returned model information with your evaluation results. If a provider updates an alias, your application can continue working while its answers change; a small regression suite helps you notice that change.

2. Set up authentication without exposing your API key

Create your key through the official DeepSeek API platform, then provide it as a bearer credential. You need a DeepSeek-issued key even when your Python import says openai. The library supplies the client; the configured endpoint and credential determine which service receives the request. DeepSeek’s quick start shows the Authorization: Bearer header used below.

For a website or mobile app, put this call behind your own authenticated backend. Anything shipped in browser JavaScript, a public repository, or a downloadable mobile bundle should be treated as discoverable. A backend also gives you one place to reject oversized inputs, limit each user’s spend, and decide which model and tools a user is permitted to access.

Use a deployment secret manager in production. For local learning, an environment variable avoids hard-coding the key, but it is not a complete secret-management system: shell history, process access, debug logs, and accidentally committed environment files still matter. The OWASP secrets-management guidance is a useful checklist for storage, access, rotation, and audit controls.

The following Bash setup prompts for the key without echoing it or placing its value in the command itself. Run it in a trusted local terminal, not a shared notebook. The placeholder model is intentionally an ordinary environment setting. On Windows, use your shell or IDE’s secret/environment-variable facility instead of pasting a credential into source code.

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade openai
read -rsp 'DeepSeek API key: ' DEEPSEEK_API_KEY; echo
export DEEPSEEK_API_KEY
export DEEPSEEK_MODEL='deepseek-flash'
python -m pip freeze > requirements.lock.txt

Use a supported Python version; the current OpenAI Python library requires Python 3.10 or newer. A virtual environment keeps these dependencies separate from unrelated projects. The installation command gets the current SDK; the lock file records what you installed. After your own smoke tests succeed, keep that dependency set reproducible rather than upgrading production packages during every deployment.

If a key is exposed, rotate it through the provider and remove it from the affected systems. Deleting a line from the newest commit does not remove older copies. Do not paste keys into a support ticket or a public issue when debugging authentication. Share a redacted error, the endpoint, and the time of the failure instead.

3. Make a minimal, inspectable Python request

Save this shared configuration as deepseek_client.py. It fails immediately when the key is missing, uses an explicit endpoint, and turns off automatic SDK retries so the retry behavior later in the guide is visible. The 60-second SDK timeout is a tutorial setting, not a service promise or a guaranteed total wall-clock deadline.

import os
from openai import OpenAI

key = os.environ.get("DEEPSEEK_API_KEY", "").strip()
if not key:
    raise RuntimeError("Set DEEPSEEK_API_KEY in your environment")

MODEL = os.environ.get("DEEPSEEK_MODEL", "deepseek-flash")
client = OpenAI(
    api_key=key,
    base_url="https://api.deepseek.com",
    timeout=60.0,
    max_retries=0,
)

Next save first_request.py in the same directory. Its deliberately small, synthetic input makes the first result easy to check. Avoid debugging a new integration with confidential customer data or a thousand-page document; that makes authentication, formatting, answer quality, and privacy problems harder to separate.

from deepseek_client import client, MODEL

response = client.chat.completions.create(
    model=MODEL,
    messages=[
        {"role": "system", "content": "Summarize supplied text faithfully in one sentence."},
        {"role": "user", "content": "Synthetic note: The demo moved to Friday. The owner is Alex."},
    ],
    max_tokens=180,
    extra_body={"thinking": {"type": "disabled"}},
)

if not response.choices:
    raise RuntimeError("The response contained no choices")
choice = response.choices[0]
if choice.finish_reason != "stop":
    raise RuntimeError(f"Incomplete or unexpected result: {choice.finish_reason}")
if not choice.message.content:
    raise RuntimeError("The response contained no answer text")

print(choice.message.content)
print("model:", response.model)
print("completion_id:", response.id)
if response.usage is not None:
    print("usage:", response.usage.model_dump())

Run it with python first_request.py. A successful result should preserve both facts: the demo is on Friday and Alex is responsible. Exact wording can vary. Check that semantic requirement yourself; a successful HTTP response only tells you the transport worked. It does not establish that the model preserved a name, understood an ambiguous date, or obeyed every instruction.

The example treats anything other than a normal stop as something the application must inspect. DeepSeek documents additional finish reasons including a length limit, filtering, tool calls, resource interruption, and an aborted generation. A tool-using application would route tool calls to a separate handler rather than rejecting them. Our simple summarizer has no tools, so an unexpected finish should stay visible. Source: Chat Completions response reference.

Keep a completion ID, model, elapsed time, finish reason, and token usage for operational diagnosis. In a tutorial terminal these fields are useful. In a deployed service, write them to access-controlled structured logs and keep raw prompts out of routine telemetry unless you have a specific, approved reason to retain them.

4. Choose thinking mode deliberately

Thinking is enabled by default in the current API, with high effort. For Chat Completions through the OpenAI SDK, DeepSeek-specific thinking belongs inside extra_body; reasoning_effort can be supplied directly. Supported named effort levels are low, high, and max. The returned reasoning text is separate from the final answer in reasoning_content. See DeepSeek’s thinking-mode guide.

from deepseek_client import client, MODEL

response = client.chat.completions.create(
    model=MODEL,
    messages=[{"role": "user", "content":
        "Compare two retry policies: three immediate retries versus "
        "three retries with exponential backoff. Explain operational trade-offs."}],
    reasoning_effort="high",
    max_tokens=4096,
    extra_body={"thinking": {"type": "enabled"}},
)
choice = response.choices[0]
print("finish:", choice.finish_reason)
print(choice.message.content or "No final answer was returned")

Use your task’s acceptance criteria to decide whether that extra work is worthwhile. Compare correctness, first visible answer time, total duration, and billed output on the same test cases. For extracting a single label, disabled thinking may be sufficient. For analyzing conflicting requirements, evaluate enabled thinking and require evidence that the better result justifies the additional latency and spend.

Do not assume every familiar sampling setting changes behavior. DeepSeek states that temperature has no effect in thinking mode, and documents mode-specific behavior for other controls. Avoid tuning several parameters at once. Keep a baseline, change one decision, and compare the resulting failures as well as the successful examples. A model returning a longer explanation is not, by itself, a quality improvement.

5. Stream answers without confusing progress with completion

Streaming helps a user see text as it arrives, but it adds states your application must handle: connected, working, receiving answer text, completed, and interrupted. A spinner that disappears on the first network packet is misleading because a packet may contain a keep-alive or metadata rather than an answer. Likewise, a socket closing is not enough evidence that a complete answer was delivered.

For Chat Completions, set stream=True. The protocol uses server-sent events and finishes with data: [DONE]. The current DeepSeek reference places usage on the last chunk, alongside a choice with a finish reason and no new answer text; it explicitly says no separate usage-only chunk is emitted. Keep-alive comments can also arrive while waiting. Sources: streaming contract and keep-alive behavior.

This reader prints only answer content, retains the last usage object, and requires an ordinary stop. It tolerates a chunk without choices defensively, without assuming such a chunk is DeepSeek’s usage format. Save it as stream_answer.py. The SDK handles the SSE framing; do not try to parse each network packet as a complete JSON object.

import sys
from deepseek_client import client, MODEL

finish_reason = None
usage = None
answer_parts = []
stream = client.chat.completions.create(
    model=MODEL,
    messages=[{"role": "user", "content":
        "Explain exponential backoff in a short paragraph for a junior developer."}],
    stream=True,
    stream_options={"include_usage": True},
    max_tokens=500,
    extra_body={"thinking": {"type": "disabled"}},
)

try:
    for chunk in stream:
        if chunk.usage is not None:
            usage = chunk.usage
        if not chunk.choices:
            continue
        choice = chunk.choices[0]
        text = choice.delta.content or ""
        if text:
            answer_parts.append(text)
            print(text, end="", flush=True)
        if choice.finish_reason is not None:
            finish_reason = choice.finish_reason
finally:
    stream.close()
    print()

if finish_reason != "stop":
    raise RuntimeError(f"Answer was not complete: {finish_reason}")
if not answer_parts:
    raise RuntimeError("Stream completed without answer text")
if usage is None:
    print("Usage unavailable; do not record zero cost", file=sys.stderr)
else:
    print("usage:", usage.model_dump(), file=sys.stderr)

If you enable thinking in this example, answer text may begin only after reasoning deltas have arrived. Keep those channels separate. A “working” indicator is enough for many interfaces; there is no need to concatenate every provider field into the visible answer. If you intentionally display reasoning, distinguish it from the final response and apply your normal data-retention rules.

If an exception occurs halfway through, retain a clear “interrupted” state. A retry can generate different wording, so appending it to the existing half-answer can create a false composite. For an interactive application, offer an explicit replacement attempt; for background work, discard the incomplete artifact or version it as a failed attempt. Record unavailable usage as unknown until reconciled, not as free.

Test the whole delivery path. Reverse proxies, hosting platforms, and response middleware can buffer chunks even when your Python loop is streaming correctly. Exercise cancellation, slow clients, idle connections, and server restarts. Measure time to first answer content separately from time to first byte; that distinction exposes cases where a healthy-looking connection still leaves the user waiting.

6. Manage conversation history and validate JSON outputs

Conversation history belongs to your application

DeepSeek’s Chat Completions guide describes a stateless conversation interface: subsequent requests must include the history needed for the next answer. For a simple non-tool chat, append the assistant’s final answer and then the next user message. Your database or session store decides which history exists, who can access it, and when it expires. Source: multi-round conversation guide.

Preserve important constraints when trimming a long conversation. An early message may contain a user’s budget or a document’s confidentiality rule. Blindly dropping the oldest messages can remove that instruction while retaining later small talk. A practical design stores durable task facts separately, keeps a recent message window, and labels any generated summary as a summary rather than treating it as an authoritative original.

Thinking plus tools has an additional contract: DeepSeek requires prior reasoning_content to be passed back when the request carries tools, including turns without a tool invocation. Omitting it can produce a 400 error. Without tools, that reasoning history does not need to be passed back. Check the current thinking-mode rules before adding an agent loop to a basic chat demo.

JSON syntax is only the first validation layer

For structured extraction, use response_format={"type": "json_object"} and explicitly request JSON in the prompt. DeepSeek recommends showing the intended format, budgeting enough output tokens, and handling occasional empty content. These settings do not replace validation of your application’s required fields and values. Source: DeepSeek JSON Output guide.

import json
from deepseek_client import client, MODEL

response = client.chat.completions.create(
    model=MODEL,
    messages=[
        {"role": "system", "content":
            'Extract the owner and day. Return JSON only, exactly like '
            '{"owner":"Alex","day":"Friday"}. Do not add fields.'},
        {"role": "user", "content": "Synthetic note: Morgan owns the Tuesday demo."},
    ],
    response_format={"type": "json_object"},
    max_tokens=160,
    extra_body={"thinking": {"type": "disabled"}},
)
choice = response.choices[0]
if choice.finish_reason != "stop" or not choice.message.content:
    raise ValueError("Missing or incomplete JSON response")
data = json.loads(choice.message.content)
if not isinstance(data, dict) or set(data) != {"owner", "day"}:
    raise ValueError("Unexpected JSON shape")
if not isinstance(data["owner"], str) or not data["owner"].strip():
    raise ValueError("Owner must be a non-empty string")
if data["day"] not in {
    "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"
}:
    raise ValueError("Day must be a day-of-week name")
print(data)

This validates shape and a small allowed vocabulary. It cannot prove Morgan actually owns the demo; for this synthetic example, you can compare against the input directly. In a real extraction pipeline, preserve the source passage, distinguish missing values from invented guesses, and add checks for contradictions. Never let merely valid JSON authorize a payment, delete a file, or change a customer account.

If you move from extraction to tool calling, the application remains responsible for executing tools and checking their arguments. DeepSeek separately documents a beta strict-schema mode for tool definitions. That feature has its own endpoint and schema requirements; it is not the same setting as JSON output. See the tool-calling guide.

7. Estimate DeepSeek API costs with the right token categories

A useful budget separates uncached input, cached input, and generated output. Count all requests in a workflow, including retries and intermediate agent steps. Counting only the final paragraph shown to the user hides the cost of unsuccessful attempts and reasoning. Use API-returned usage rather than word count; DeepSeek notes that text-to-token ratios vary. Source: token-usage guidance.

The published peak windows are 01:00–04:00 and 06:00–10:00 UTC, Monday through Friday, excluding Chinese public holidays. Other periods are off-peak. Recheck the provider’s live table before committing a budget, and avoid hard-coding local time-zone assumptions into a batch scheduler.

Worked example: 10,000 synthetic requests

Suppose each request uses 2,000 uncached input tokens and 500 output tokens, with no cache hits, and all requests fall in the same pricing period. For Flash at the listed peak rates, input costs $6 and output costs $6, for a $12 model-usage total. At the listed off-peak rates, the same token volume is $6. This arithmetic excludes infrastructure, taxes or payment-related charges, and additional attempts.

from decimal import Decimal

def cost_usd(hit_tokens, miss_tokens, output_tokens, rates):
    counts = (hit_tokens, miss_tokens, output_tokens)
    if any(n < 0 for n in counts):
        raise ValueError("Token counts must be non-negative")
    return sum(
        Decimal(n) * Decimal(rate) / Decimal(1_000_000)
        for n, rate in zip(counts, rates)
    )

# Rates are USD per million: cached input, uncached input, output.
flash_peak = ("0.006", "0.30", "1.20")
flash_off_peak = ("0.003", "0.15", "0.60")
print(cost_usd(0, 20_000_000, 5_000_000, flash_peak))
print(cost_usd(0, 20_000_000, 5_000_000, flash_off_peak))

Use the returned completion-token total for Chat Completions accounting; do not add a reasoning-token breakdown to that total again. If your bill model is based on visible answer length, a reasoning-enabled workload can surprise you. Keep input and output counters separate and reconcile sampled estimates against actual account usage before treating a monthly projection as reliable. See the usage-field definitions.

Caching helps when you measure it

DeepSeek enables context caching automatically. Cache reuse depends on matching persisted prefix units; partial overlap alone does not guarantee an immediate hit. The documentation exposes prompt_cache_hit_tokens and prompt_cache_miss_tokens and describes caching as best effort. Source: context-cache behavior.

Keep stable instructions and reusable reference material before the changing question when the application permits it. Avoid putting a fresh timestamp or random request identifier at the beginning of every prompt if it serves no model-facing purpose. Then measure the actual hit fraction. Do not assume that every repeated document becomes a full cache hit, or include guaranteed caching savings in a customer quote before observing the workload.

A budget alert should trigger early enough for someone to act. DeepSeek documents a GET /user/balance endpoint with availability and balance information. Use a protected operational check rather than exposing this account-wide information to ordinary application users. Source: balance endpoint.

8. Diagnose errors before deciding to retry

Handle failures by category. Authentication and malformed input usually need a configuration or code change; overload may resolve after waiting. Repeating every failure three times hides the real issue, makes logs noisier, and can multiply traffic during an incident. Your user-facing message should explain whether the person can retry, needs to edit their input, or should wait for the service to recover.

The following wrapper is intentionally narrow: it retries complete, non-streaming, side-effect-free text generations only for 429, 500, and 503. It attempts the call at most three times, adds jitter, and leaves authentication, validation, and connection failures visible. It also honors a numeric or HTTP-date Retry-After when present, without assuming DeepSeek always sends that header.

import math
import random
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime
from openai import APIStatusError
from deepseek_client import client, MODEL

def retry_delay(header, attempt):
    if header:
        try:
            seconds = float(header)
        except ValueError:
            try:
                when = parsedate_to_datetime(header)
                if when.tzinfo is None:
                    when = when.replace(tzinfo=timezone.utc)
                seconds = (when - datetime.now(timezone.utc)).total_seconds()
            except (TypeError, ValueError, OverflowError):
                seconds = None
        if seconds is not None and math.isfinite(seconds):
            return max(0.0, seconds)
    return random.uniform(0.5, 1.5) * (2 ** attempt)

def summarize_with_retry(text):
    for attempt in range(3):
        try:
            return client.chat.completions.create(
                model=MODEL,
                messages=[{"role": "user", "content": "Summarize this note: " + text}],
                max_tokens=200,
                extra_body={"thinking": {"type": "disabled"}},
            )
        except APIStatusError as exc:
            if exc.status_code not in {429, 500, 503} or attempt == 2:
                raise
            delay = retry_delay(exc.response.headers.get("retry-after"), attempt)
            if delay > 15:
                raise  # Hand longer waits to a queue or the caller.
            time.sleep(delay)
    raise RuntimeError("Retry loop ended unexpectedly")

if __name__ == "__main__":
    result = summarize_with_retry("Synthetic note: The demo is ready.")
    choice = result.choices[0]
    if choice.finish_reason != "stop" or not choice.message.content:
        raise RuntimeError("The response requires inspection")
    print(choice.message.content)

The OpenAI Python SDK already has automatic retries for selected failures. Our shared client disables them to avoid nesting two retry policies. If you prefer SDK retries, remove this wrapper and configure a single policy instead. The SDK also distinguishes HTTP status failures from connection and timeout failures. Source: official Python SDK error handling.

A timeout leaves uncertainty: the client may have stopped waiting while the provider continued processing. This wrapper does not automatically retry that case. Decide whether another text generation is acceptable for your product, and never infer exactly-once execution from a successful retry. If tools send emails or update records, their side effects need their own authorization, deduplication, and transaction design.

Bound the whole operation at the application or job-runner level as well. A per-read timeout, three attempts, queue delay, and sleeps do not automatically add up to a fixed end-to-end deadline. When the overall deadline expires, cancel work where possible, return a clear status, and retain enough metadata to investigate the attempt.

9. A production checklist that catches expensive mistakes

Control concurrency before an incident

DeepSeek currently documents account-level concurrency limits of 2,500 for Flash and 500 for Pro. A request occupies a slot until its response completes, and issuing more API keys does not create separate account quotas. The documentation also describes user_id for isolation and says not to include private user information in that field. See rate limits and isolation.

Your own limit should reflect what your backend and budget can handle, which may be far smaller. Use a queue or semaphore, cap waiting jobs, and reject overload cleanly. A rough planning example illustrates why latency matters: 20 requests per second with an average 10-second duration implies about 200 simultaneous requests in steady state. Tail latency and traffic bursts require additional headroom; that estimate is not a provider throughput guarantee.

Build a small, representative evaluation set

Create test cases from the decisions your application makes. Include ordinary requests, long inputs, ambiguous dates, missing fields, adversarial instructions inside quoted documents, and genuinely unanswerable questions. Write the expected behavior before comparing models. For a support assistant, “ask for the missing order identifier” can be a correct outcome; an eloquent invented answer should fail.

Score correctness separately from formatting, latency, and cost. For extraction, count field-level errors. For summaries, check whether essential facts survived. For code, run the relevant tests in an isolated environment. For retrieval, verify cited passages actually support the answer. Keep a record of the model identifier, prompt version, date, settings, and test-data revision so a later change can be investigated.

Run a failure-first smoke test

Before the pilot, rehearse the failures you expect support staff to see. Start with a missing environment variable and confirm the application stops before making a request. Then use mocked responses to exercise a 401, a 402, an overloaded server, a truncated answer, and a stream that ends after several words. These offline tests should not require a real credential or consume model tokens.

For each case, check three outcomes: what the user sees, what the operator can diagnose, and whether another attempt occurs. A missing key should not become a generic “try again” button. A partial summary should not be saved as a finished report. A 402 should not create an endless retry queue. A provider error body should not be copied wholesale into a public response, where it could expose implementation details.

When you are ready for a live smoke test, use one small synthetic prompt with a deliberately modest output limit. Verify the response model, completion status, usage fields, and account deduction. Run a separate streaming request and confirm your proxy forwards incremental content. Keep a note of what was actually observed and what remains untested. That evidence is more useful than labeling an entire integration “production ready” after its first successful response.

Keep trust boundaries explicit

Before sending production content, decide which data the provider may receive and what your own organization may log. Remove unnecessary identifiers, check contractual requirements, and keep sensitive test fixtures out of development notebooks. A stateless conversation interface describes how context is supplied; it does not by itself establish a data-retention promise or a regulatory compliance guarantee.

Treat model outputs and retrieved documents as untrusted inputs to the application. Validate destinations before fetching URLs, restrict tools to an allowlist, and enforce authorization outside the model. If an external document tells an assistant to reveal its secret or contact an unrelated endpoint, that text should not gain permission simply because it appeared in the context window. Apply the same discipline to generated HTML before rendering it.

Check these before exposing the feature to users

• Configuration: The production endpoint and model are explicit; the API key is server-side; development secrets are absent from the bundle
• Input limits: Prompt size, file size, request frequency, and per-user budgets have tested limits
• Completion: A normal finish is distinguished from truncation, filtering, interruption, and tool calls
• Streaming: Partial answers stay visibly incomplete; cancellation closes resources; proxy buffering has been checked
• Accounting: Cache hits, cache misses, and output are tracked; missing usage is not treated as zero
• Resilience: Retries have one owner; total deadlines exist; queues have bounded capacity
• Quality: Representative evaluations pass after SDK, prompt, or model changes
• Operations: Funding alerts, incident messages, a rollback path, and a responsible owner are in place

Roll out to a small internal or consenting pilot group first. Inspect real failure categories and compare estimated cost with observed usage before raising traffic limits. Good operations make it easier to adopt a better model later: you can change the provider configuration, run the same evaluations, and understand what improved or regressed.

10. Frequently asked questions

Can I use an OpenAI API key with DeepSeek?

No. Use a DeepSeek key with the DeepSeek endpoint. The OpenAI Python package is being used as a compatible client library here; it does not transfer account access or billing between providers. Keep credentials clearly named so a deployment cannot silently select the wrong secret.

Should new code use deepseek-chat or deepseek-reasoner?

Use the currently documented model identifiers shown earlier in this guide. Older tutorials predate the model-name transition. Confirm availability with the model-list endpoint when you deploy, and keep the model setting outside application logic so a future migration has a small, reviewable configuration change.

Can I call DeepSeek directly from a browser?

A public web application should call your own backend, which then calls DeepSeek. Putting a shared provider key in client-side code gives other people an opportunity to extract and misuse it. Browser-side user authentication and server-side spend controls are still necessary even when your interface is only a simple chat box.

Does streaming make generation cheaper?

Do not assume a discount. Streaming changes how the response is delivered; budget using reported usage and the applicable model rates. It can improve perceived responsiveness, but a long answer, reasoning step, or repeated failed attempt still needs to be included in your workload accounting.

Why can JSON mode still break my application?

Your application needs more than parseable JSON. It may need particular keys, constrained values, correct units, accurate facts, and a complete answer. Check finish status and non-empty content before parsing, then validate the structure and meaning your workflow requires.

The practical next step

Start with the smallest non-streaming request and synthetic data. Make its success criteria explicit, record usage, and prove the failure path works. Then add streaming or structured output, followed by your own concurrency and cost controls. Once those foundations are observable and tested, comparing models becomes a controlled engineering decision instead of a guessing exercise.

For additional practice inputs, adapt the research-summary and process-analysis exercises in our Top 10 Prompt Library. Our Innovation Prompt Library also provides starting points for defining problems and success criteria. Turn those ideas into explicit, testable tasks before sending them through an automated workflow; interactive prompts often need simplifying when a program must validate the result.

Maintenance note: Recheck model availability, pricing, thinking defaults, stream semantics, and SDK compatibility before copying this configuration into a future deployment. The official pages linked throughout this guide are the source of truth for provider behavior; the architecture, operational recommendations, and worked examples are independent editorial guidance.