DeepSeek API Bug: Strict Mode Malforms JSON

Discover a critical bug affecting DeepSeek API's strict mode, where function call arguments are returned as malformed JSON. This article delves into the specifics of this issue, its impact, and how to navigate around it while we await a fix. This problem primarily surfaces when utilizing the beta endpoint of the DeepSeek API, and it can be a significant roadblock for developers relying on strict schema validation for their function calls. We'll explore why this happens and what steps you can take to ensure your applications continue to function smoothly.

Understanding the DeepSeek API Strict Mode Bug

When you're working with the DeepSeek API's beta endpoint and enable the strict: true parameter within your function or tool definitions, a peculiar issue arises. Instead of receiving cleanly formatted JSON for the function.arguments field, you're presented with data that's slightly, yet critically, off. The core of the problem lies in the JSON serialization: the very first key within the arguments object seems to lose its closing double quote. This seemingly minor omission renders the entire JSON string unparseable by standard JSON parsers, leading to errors like JSONDecodeError: Expecting ':' delimiter. This means that any system expecting valid JSON to process the arguments passed to your functions will halt, potentially causing application instability. It's a high-severity bug because it directly interferes with a core feature – structured output validation – that developers often rely on for robust application logic. The expected output should be a perfectly formed JSON object, such as {"selected": ["A", "C", "D"]}, but instead, you might see something like {"selected: ["A", "C", "D"]}. The missing quote after "selected is the culprit, breaking the JSON structure.

The Technical Breakdown: Why Strict Mode Fails

The strict: true mode in DeepSeek's API is designed to be a powerful tool for ensuring that the model's output adheres precisely to the schema you've defined for your function calls. This is incredibly useful for preventing unexpected data formats and maintaining data integrity. It acts as a gatekeeper, ensuring that the model doesn't just try to call a function but calls it with arguments that strictly match the expected types and structure. This often goes hand-in-hand with additionalProperties: False in your schema, which further restricts the model to only using properties explicitly defined in your schema. When strict: true is enabled, the API should perform a validation step to ensure the generated arguments conform to the specified schema. However, it appears that during this validation and serialization process, a bug is introduced specifically when additionalProperties: False is also present. The model might correctly identify the intended arguments and their values, but in the final step of packaging this information into a JSON string for the function.arguments field, the serialization process falters. It misses the closing double quote on the first key of the JSON object. This means that while the logic of the function call might be sound, the delivery mechanism of its arguments is broken. Imagine a perfectly packaged gift, but the ribbon is tied incorrectly – the intention is there, but it's not presentable. This is precisely what happens with the malformed JSON. The underlying data structure might be correct, but the string representation is invalid. This bug is confirmed to be present on the /beta endpoint and using the deepseek-chat model, making it a concrete issue for users of these specific configurations. Understanding this nuance is key to diagnosing the problem and exploring workarounds.

Reproducing the Bug: A Step-by-Step Guide

To fully grasp the severity and nature of this DeepSeek API bug, it's essential to be able to reproduce it. Fortunately, the steps are straightforward and require minimal setup. We'll walk through a minimal reproducible code example using the OpenAI Python SDK, which is commonly used to interact with the DeepSeek API due to its compatibility. The key components to trigger this bug are the beta endpoint, the strict: True parameter, and a function schema that includes additionalProperties: False. Let's dive into the code and the process.

Minimal Reproducible Code Example

from openai import OpenAI
import json

# Initialize client with beta endpoint
client = OpenAI(
    api_key="<your-api-key>",
    base_url="https://api.deepseek.com/beta"
)

# Define tool with strict=True and additionalProperties=False
tools = [{
    "type": "function",
    "function": {
        "name": "submit_answer",
        "description": "Submit multiple choice answer",
        "strict": True,  # ← This triggers the bug
        "parameters": {
            "type": "object",
            "properties": {
                "selected": {
                    "type": "array",
                    "description": "Selected options",
                    "items": {"type": "string"}
                }
            },
            "required": ["selected"],
            "additionalProperties": False # ← Crucial for triggering the bug pattern
        }
    }
}]

# Send request to trigger function calling
response = client.chat.completions.create(
    model="deepseek-chat",
    messages=[{
        "role": "user",
        "content": "Which are Python core features? A. Dynamic typing B. Compiled language C. OOP D. Multithreading. Use submit_answer tool."
    }],
    tools=tools,
    tool_choice="auto"
)

# Attempt to parse the arguments - this is where it breaks
try:
    arguments_raw = response.choices[0].message.tool_calls[0].function.arguments
    print(f"Raw arguments: {arguments_raw}")
    args = json.loads(arguments_raw)  # ❌ Crashes here
    print(f"Parsed arguments: {args}")
except json.JSONDecodeError as e:
    print(f"JSONDecodeError: {e}")
except Exception as e:
    print(f"An unexpected error occurred: {e}")

Step-by-Step Reproduction

1. Configure the Client: Ensure your OpenAI client is initialized with the correct API key and, crucially, points to the beta endpoint: base_url="https://api.deepseek.com/beta". This is non-negotiable for triggering this specific bug.
2. Define the Tool: Create your tool definition. The type must be "function". The function object should contain a name, description, and the parameters. The parameters should define an "object" type with at least one "property". For this bug, it's vital to set "strict": True within the function object and include "additionalProperties": False within the parameters schema.
3. Trigger Function Calling: Send a chat.completions.create request to the API. The model should be set to "deepseek-chat" (or another compatible model on the beta endpoint). The messages payload should contain a user prompt that is likely to trigger the model to use the defined tool (e.g., asking a question that the tool is designed to answer). Set tool_choice="auto" to allow the model to decide when to use the tool.
4. Inspect the Response: After receiving the response, access the tool_calls from response.choices[0].message. Navigate to function.arguments. Print this raw string.
5. Attempt JSON Parsing: Use json.loads() to parse the arguments_raw string. This is the point where the JSONDecodeError will occur if the bug is present. The error message typically indicates a problem with expecting a colon (:), which is a direct consequence of the missing closing double quote on the key.

By following these steps, you can reliably reproduce the malformed JSON output when strict: True and additionalProperties: False are used together on the DeepSeek API's beta endpoint. This hands-on experience confirms the issue and highlights the need for a workaround.

Expected vs. Actual Behavior: A Clear Distinction

When interacting with AI models for tasks that involve structured data, such as function calling, clarity and correctness in the output are paramount. The DeepSeek API, particularly with its strict mode enabled, promises a higher degree of reliability by enforcing schema adherence. However, as we've identified, a bug undermines this promise. Understanding the difference between what should happen and what is happening is crucial for debugging and for developers to anticipate potential issues. Let's break down the expected behavior and contrast it with the actual, problematic output.

The Ideal Scenario: Valid JSON Output

In an ideal world, and indeed when strict: True functions correctly, the API should return a function.arguments field containing valid JSON. This means the string adheres to all the rules of the JSON format, making it easily parsable by any standard JSON library. For our example scenario, where the user is asked to select Python core features and the tool expects an array of strings under the key `