Kimi K3.1 Pro JSON Schema structured output configuration: strict, MFJS, and final content parsing

One-sentence takeaway

Kimi K3.1 Pro uses response_format.type="json_schema" and strict=true to constrain fields, types, and nested structures; the client should parse only choices[0].message.content and should not treat reasoning_content or the entire response object as the JSON body.

Use cases

• Suitable tasks: Passing news summaries, information extraction, or other API output directly to downstream typed programs.

• Unsuitable tasks: Tasks requiring free-form text, fields that have not yet been determined, or complex Schema features not verified in the K3.1 Pro documentation.

• Applicable model version: kimi-k3.1-pro.

• Applicable client, agent, or API: Kimi API Chat Completions; the official example uses the Python OpenAI SDK and https://api.moonshot.ai/v1.

• Recommended reasoning level and parameters: Use json_schema for response_format.type, explicitly set json_schema.strict=true, and ensure that max_tokens covers the length of the complete JSON.

Ready-to-use content

The following is the complete minimal request structure from the official page. It preserves kimi-k3.1-pro, json_schema.name, strict, schema, and final content parsing:

import json
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.ai/v1",
)

completion = client.chat.completions.create(
    model="kimi-k3.1-pro",
    messages=[
        {"role": "system", "content": "You are a news summarization assistant."},
        {"role": "user", "content": "Please summarize: AI technology made a major breakthrough today."},
    ],
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "news_summary",
            "strict": True,
            "schema": {
                "type": "object",
                "properties": {
                    "title": {"type": "string"},
                    "summary": {"type": "string"},
                    "keywords": {"type": "array", "items": {"type": "string"}},
                },
                "required": ["title", "summary", "keywords"],
                "additionalProperties": False,
            },
        },
    },
)

# Parse only the final answer; do not call json.loads on the entire response or reasoning_content.
content = completion.choices[0].message.content
result = json.loads(content)
print(result["title"])
print(result["keywords"])

Testing or workflow steps

1. Confirm that the request uses model kimi-k3.1-pro and is sent through Kimi API Chat Completions.

2. Set response_format.type to json_schema, and provide both json_schema.name and json_schema.schema.

3. Use strict=true; declare properties, required, and, when needed, additionalProperties:false for the object.

4. K3.1 Pro's official documentation explicitly covers nested objects, arrays, and anyOf; test more complex features against the target model first.

5. Run the MFJS static check with walle -schema 'your_schema_json' -level strict.

6. After sending the request, check completion.choices[0].finish_reason; if it is length, increase max_tokens or shorten the input.

7. Run json.loads on completion.choices[0].message.content, then validate fields and types as required by the business logic.

Original evidence and data

• The page defines json_object as guaranteeing only a valid JSON object, and json_schema as a schema that constrains field names, types, and nested structures.

• The json_schema format requires both name and schema; the page recommends explicitly setting strict to true.

• The official model comparison states that kimi-k3.1-pro and kimi-k3 reliably support structured output, including nested objects, arrays, and anyOf.

• When strict=true, the Schema must conform to MFJS (Moonshot Flavored JSON Schema); the official recommendation is to use walle for static checking.

• additionalProperties:false prevents fields not defined in the Schema from being output; required fields should always appear in the result.

• Missing information should preferably be represented with a union type that allows null, avoiding a single type that prompts the model to fabricate content or return an empty string.

• Structured output still requires the prompt to specify the business objective and data source; the Schema only controls the output shape.

• The official example parses the result with json.loads(completion.choices[0].message.content) and reads fields separately.

Scope and limitations

• This article includes only nested objects, arrays, and anyOf, which the official documentation explicitly covers, in Kimi K3.1 Pro's supported range; the page does not list its complete MFJS subset.

• The page attributes oneOf, $ref, additionalProperties:true, and complex Partial Mode behavior to descriptions for other models; they must not be rewritten as capabilities verified for Kimi K3.1 Pro.

• strict=true is not a switch that bypasses Schema validation; if the Schema does not conform to MFJS or is not an object, the request may receive 400 invalid_request_error.

• The output may be truncated when finish_reason="length"; whether json.loads succeeds cannot replace checking finish_reason and validating the business Schema.

• This collection did not use an API Key to send a K3.1 Pro request, so it did not measure parsing success rate, latency, complex Schema behavior, oneOf, $ref, or Partial Mode.

Reproduction notes

1. Open the official response_format documentation and confirm the page title and the basic kimi-k3.1-pro example.

2. Set MOONSHOT_API_KEY, install openai, and run the Python example above.

3. Record finish_reason, message.content, and (if present) reasoning_content from the raw response; parse JSON only from message.content.

4. Pre-check the same Schema with walle at the strict level, then send a real request to the target model.

5. Run independent field validation on the JSON parsing result; this note does not treat static pre-checks or HTTP 200 as proof of full K3.1 Pro compatibility.