ChatCompletions vs Anthropic Messages vs Responses API: Testing DeepSeek V4 Pro's Three API Formats

DeepSeek-V4-Pro-0813 reached general availability on August 12, 2026, served behind the evergreen deepseek-v4-pro model ID at https://api.deepseek.com, alongside the cheaper deepseek-v4-flash (Unite.AI covered the GA announcement). The headline specs are strong: a 1M-token context window, 384K max output, tool calling, structured outputs, and three thinking modes that surface the model’s reasoning trace in a reasoning_content field.

The unusual part is not the specs. It’s that one model answers in three API dialects. V4 Pro accepts OpenAI ChatCompletions requests, Anthropic Messages requests, and requests to DeepSeek’s own Responses API. Point your existing OpenAI SDK code at it, point a Claude-built agent at it, or wire it into a Codex-style agent loop, same weights, three wire formats.

Nobody has laid the three DeepSeek V4 Pro API formats out side by side yet, so this guide does. You’ll see one working request per format, where the shapes genuinely differ, a comparison table, and how to test all three from a single Apidog project with shared environment variables. If you want the account setup and first-call walkthrough, start with how to use the DeepSeek V4 API and come back.

TL;DR

• DeepSeek-V4-Pro-0813 is GA behind deepseek-v4-pro at https://api.deepseek.com; deepseek-v4-flash shares the same surfaces at a lower price point.
• It speaks three API formats: OpenAI ChatCompletions (works with the standard openai SDK by changing base_url), Anthropic Messages (drop-in for anthropic-SDK-shaped requests, including Claude Code), and DeepSeek’s Responses API (its newest interface, built for Codex-style agents and stateful workflows).
• Specs: 1M context, 384K max output, tool calling, structured outputs, three thinking modes with reasoning_content.
• Pricing: $0.435/M input tokens (cache miss), $0.003625/M on a cache hit, $0.87/M output.
• The formats differ in system-prompt placement, max_tokens semantics, tool schema shape, and streaming event shape, details below.
• One Apidog project with {{DEEPSEEK_API_KEY}} and per-format base URL variables lets you fire the same prompt at all three and diff the raw responses.

Why one model speaks three dialects

This is an ecosystem compatibility play: every API format is an installed base of tooling DeepSeek gets for free. ChatCompletions is the lingua franca, thousands of SDKs and frameworks can call V4 Pro with a one-line base_url change. The Anthropic Messages format targets teams that built on Claude: agents, eval harnesses, and tools like Claude Code can point at V4 Pro without a rewrite. And the Responses API is DeepSeek’s bet on agents: deepseek-v4-flash gained it in July for Codex-style compatibility, and V4 Pro ships with it at GA for stateful, multi-step workflows.

V4 Pro is also listed on aggregators (see the OpenRouter page for deepseek-v4-pro-0813), but the three-format story applies to DeepSeek’s first-party API, which is what this article tests. For a broader look at the V4 family, see how to use DeepSeek V4.

Format 1: OpenAI ChatCompletions

This is the shape you already know: a messages array where the system prompt rides along as the first message with role: "system", and an optional max-tokens cap. Setup is the same for all three formats, so here it is once: your DeepSeek API key, DeepSeek’s base URL, and model set to deepseek-v4-pro (or deepseek-v4-flash). Only the endpoint and body shape change.

Python, through the standard openai SDK:

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_DEEPSEEK_API_KEY",
    base_url="https://api.deepseek.com",
)

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[
        {"role": "system", "content": "You are a precise technical writer."},
        {"role": "user", "content": "Explain idempotency keys in two sentences."}
    ],
)

print(response.choices[0].message.content)

No new SDK, no new auth scheme. Tool calling uses the familiar nested function shape, and streaming arrives as chat.completion.chunk deltas terminated by data: [DONE], matching the OpenAI spec. One V4-specific behavior to plan for: with a thinking mode active, the reasoning trace arrives in a separate reasoning_content field alongside content, so parsers should tolerate the extra field.

When to use it: you have existing OpenAI tooling, LangChain-style frameworks, or internal libraries that already speak ChatCompletions. It’s the lowest-friction path and the easiest to verify, the request anatomy is identical to what’s covered in testing the ChatGPT API with Apidog, with only the host and model swapped.

Format 2: Anthropic Messages

The Messages format looks similar at a glance and differs in ways that break naive translation. Three differences matter most, all inherited from the Anthropic spec:

1. The system prompt moves out of the array. It’s a top-level system parameter; the messages array holds only alternating user and assistant turns.
2. max_tokens is required, not optional. Every request declares an explicit output budget. With V4 Pro’s 384K max output, that ceiling is generous, but you must state it.
3. Tool definitions are flat. Each tool carries name, description, and an input_schema at the top level, no nested function wrapper. Tool calls come back as tool_use content blocks, and you return results as tool_result blocks inside a user message.

Python, Messages request through the anthropic SDK:

import os
import anthropic

client = anthropic.Anthropic(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com/anthropic", # Anthropic-compatible base; confirm current path in DeepSeek's docs
)

message = client.messages.create(
    model="deepseek-v4-pro",
    max_tokens=8192,
    system="You are a precise technical writer.",
    messages=[
        {"role": "user", "content": "Explain idempotency keys in two sentences."}
    ],
)

print(message.content[0].text)

Responses come back as a list of content blocks rather than a single string, and streaming uses typed SSE events message_start, content_block_delta, message_stop instead of uniform chunks. Authentication follows the Anthropic spec’s header conventions rather than a bearer token. The DeepSeek API docs carry the current details of the compatible surface.

The practical payoff is agents. Because tools like Claude Code read their endpoint from environment variables, you can point a Claude-built agent at DeepSeek without touching its code:

export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
export ANTHROPIC_AUTH_TOKEN=$DEEPSEEK_API_KEY
export ANTHROPIC_MODEL=deepseek-v4-pro

When to use it: your tooling was built against Claude. If your team already sends Messages-shaped requests to Anthropic models (the same anatomy covered in our Claude Opus 5 API guide), this format lets you A/B DeepSeek against Claude inside the same harness, with the same request bodies and the same streaming handlers.

Format 3: DeepSeek’s Responses API

The Responses API is DeepSeek’s newest interface, and the reason it exists is agents. V4 Flash picked it up in July so Codex-style agents could drive DeepSeek models; V4 Pro launched with it on day one. The request shape follows the OpenAI Responses spec: you send input (a string or a list of typed items) plus top-level instructions, instead of a single messages array.

curl, Responses API request:

curl https://api.deepseek.com/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -d '{
    "model": "deepseek-v4-pro",
    "instructions": "You are an API review agent. Be terse.",
    "input": "Review this OpenAPI diff and list any breaking changes: [diff here]",
    "stream": false
  }'

Three things separate this format from the other two, all following the Responses spec:

• State can live server-side. Instead of resending the full conversation each turn, a follow-up request can reference the previous response by ID (previous_response_id in the spec), which keeps multi-step agent loops cheap to orchestrate.
• Output is a list of typed items, not a single message: reasoning items, text items, and tool-call items arrive as distinct entries, which suits agents that act on each item type differently.
• Streaming is semantic. Rather than raw text deltas, the stream emits named events (response.output_text.delta, response.completed, and friends), so an agent can react to lifecycle changes without regex-parsing chunks.

Tool calling exists here too, with tool definitions and function_call/function_call_output items shaped per the Responses spec rather than either older format. Where DeepSeek’s implementation details go beyond the spec, treat api-docs.deepseek.com as the source of truth.

When to use it: agentic and Codex-style integrations, long multi-step workflows, or any system where server-managed conversation state and typed output items simplify your orchestration code. For a plain chat completion, it’s more machinery than you need.

The three formats side by side

Same model, same pricing, three contracts. The differences are entirely at the wire level, which is exactly the kind of difference that’s easiest to verify empirically instead of from memory.

Test all three in one Apidog project

Watching the same prompt produce three differently shaped responses catches the implementation details no comparison table can. The repeatable setup:

1. Create one project, three folders: chat-completions, anthropic-messages, responses, each holding one saved request per scenario (plain completion, tool call, streaming).
2. Share credentials through environment variables. Define {{DEEPSEEK_API_KEY}}, {{BASE_URL}}, and {{ANTHROPIC_BASE}} once; rotating a key or switching to deepseek-v4-flash becomes a one-field change.
3. Fire the identical prompt through each format and diff the raw bodies: choices[0].message.content versus a content block list versus typed output items.
4. Inspect the streams with stream: true. The built-in SSE view makes the differences vivid: anonymous [DONE]-terminated chunks, named Messages events, Responses lifecycle events. If SSE debugging is new to you, how to stream API responses with SSE covers the mechanics.
5. Add assertions on the fields your integration actually reads (content path, tool-call ID location, finish reason) and re-run the collection whenever DeepSeek ships a snapshot update.

The three-folder project doubles as living documentation: “what does the Messages tool schema look like again?” becomes a saved request with a real captured response.

Migration notes

Moving existing code onto V4 Pro is deliberately boring, and that’s the point.

From OpenAI: change three values base_url to https://api.deepseek.com, the API key, and the model to deepseek-v4-pro. Your message construction, tool definitions, and streaming handlers stay. Two checks before you ship: confirm any parameters beyond the core spec behave the way you expect (run them through your test collection rather than assuming), and make sure your response parsing tolerates reasoning_content showing up next to content.

From Anthropic: swap the base URL to the Anthropic-compatible path, swap the key, and set the model. Because the Messages shape carries over, required max_tokens, content blocks, typed stream events, a spec-compliant client needs no logic changes. For agents that read environment variables, migration is the three export lines shown earlier.

Onto the Responses API: this one is a rewrite of your request layer rather than a config change, since neither older format translates mechanically. Adopt it when you want what it uniquely offers, server-side state and typed output items, not because it’s newest.

In every direction the advice is the same: migrate the config, then re-run your regression collection before trusting it. At these prices, an afternoon of verification traffic costs less than the coffee you drink during it.

FAQ

Which format should a new project pick? Default to ChatCompletions for broadest tooling support. Pick Messages if your stack is Claude-native. Pick the Responses API if you’re building a multi-step agent and want server-managed state.

Can I point Claude Code at DeepSeek V4 Pro? Yes. Set ANTHROPIC_BASE_URL to DeepSeek’s Anthropic-compatible endpoint, use your DeepSeek key as the auth token, and set the model to deepseek-v4-pro. That’s the practical payoff of the Messages-format support.

Do tool calling and structured outputs work in every format? The model supports both, and each dialect exposes tool calling in its own spec’s shape, nested function objects, input_schema tools, or Responses-style items. Verify your specific schemas against each surface in a test collection before shipping; schema-shape edge cases are exactly where compatible implementations diverge.