Responses API
Create a model response using the OpenAI Responses-compatible format. Supports multi-turn conversations, multimodal input, structured output, and tool calling, with both streaming (stream:true, SSE) and non-streaming responses.
Authorizations
Body
Model identifier. Currently supports LongCat-2.5-Preview and LongCat-2.0.
The input content, in two forms:
- String: equivalent to a single
usermessage, e.g."input": "Hello". - Message/item array: for multi-turn conversations, multimodal input, and tool result backfill. Array elements can be:
- Message items:
{ "role": "user" | "assistant" | "system" | "developer", "content": ... }, wherecontentis a string or an array of content parts (e.g.input_text,input_image). - Tool result items:
{ "type": "function_call_output", "call_id": "...", "output": "..." }.
- Message items:
Note: image URLs must be publicly accessible.
System/developer instructions.
Whether to return the response as an SSE stream. When the stream ends normally, the connection is closed directly without an extra [DONE] marker.
Tools the model may call while generating the response. Tool fields (type, name, etc.) are declared flat on the tool object — do NOT wrap them in a function sub-object (that is the Chat Completions shape; this API rejects it with tools[0].name is required). See the "Function Calling" and "Custom Tools" scenarios on the right.
Define a function in your own code that the model may choose to call.
Tool type, fixed to function.
The function name.
Function description, used by the model to decide when to call it.
Function parameters, described as a JSON Schema object.
Whether to strictly enforce the parameter schema when generating function calls.
Whether the model may call multiple tools in parallel.
Sampling temperature. Fixed at 1.0 with thinking enabled and 0.7 with thinking disabled; other values are overridden with the corresponding default.
Nucleus sampling parameter, range (0, 1]. For example, 0.1 means the model only considers tokens comprising the top 10% of probability mass.
Maximum number of tokens the model may generate (including reasoning tokens).
Reasoning controls. effort: none / minimal / low / medium / high / xhigh; summary: auto / concise / detailed.
Configure the format of the text response. format.type values: text (plain text, default), json_object (guarantees valid JSON without field validation), json_schema (strictly constrains fields and types by a schema; requires name and schema). See the "Structured Output" scenario on the right for a full example.
For both JSON modes, we recommend explicitly asking the model to "answer in JSON" in input / instructions.
String key-value metadata, returned with the response object.
Prompt cache key.
Response Object
On success, an object with object:"response" is returned; fields with null values are omitted:
ID of this response (resp_xxx).
Object type, always response.
Response status: completed (finished), failed (run failed, see error), incomplete (truncated, e.g. max_output_tokens reached).
Array of output items for this response (length and order depend on the model's actual calls). Assistant text lives in content[].text of the message item.
Assistant message item: { "id": "msg_xxx", "role": "assistant", "content": [{ "type": "output_text", "text": "...", "annotations": [] }] }.
Reasoning item, containing the model's chain-of-thought content.
Function call item; the client must execute the function and backfill function_call_output: { "call_id": "call_xxx", "name": "get_weather", "arguments": "{\"city\":\"Beijing\"}" }.
Custom tool call item.
Token usage statistics.
Number of input tokens; input_tokens_details.cached_tokens is the portion served from cache.
Number of output tokens; output_tokens_details.reasoning_tokens is the portion used for reasoning.
Total number of tokens.
Error details { "code", "message" } when the run failed; omitted on success.
Creation time as a Unix timestamp in seconds.
Completion time as a Unix timestamp in seconds; only present on success.
The remaining fields mostly echo the request parameters: model, text, reasoning, temperature, top_p, max_output_tokens, metadata, parallel_tool_calls, etc.
Stream Events
You usually only need to handle three event types: response.created (start), response.output_text.delta (text increments), and response.completed (end). Every event's data contains type and sequence_number; lifecycle events carry the full response object in data.
Full event types:
| Event | Description |
|---|---|
response.created | First event; the response has been created with status in_progress |
response.in_progress | The response is being generated |
response.output_item.addedresponse.output_item.done | An output item (reasoning / message / function_call / custom_tool_call) started / finished |
response.content_part.addedresponse.content_part.done | A content part within an output item started / finished |
response.reasoning_text.deltaresponse.reasoning_text.done | Reasoning text increment / complete reasoning text |
response.output_text.deltaresponse.output_text.done | Output text increment / complete output text |
response.function_call_arguments.deltaresponse.function_call_arguments.done | Function call arguments increment / complete arguments |
response.custom_tool_call_input.deltaresponse.custom_tool_call_input.done | Custom tool call input increment / complete input |
response.completed | Final event on success; carries the full response object including usage |
response.incomplete | Final event when the response is truncated (e.g. max_output_tokens reached); carries the full response object |
response.failed | Final event on failure; carries the full response object with error details |