Responses API

The Responses API provides an OpenAI-compatible interface for text generation, reasoning, structured output, and tool calling. Streaming is optional — the same pattern as Chat Completion V2: omit stream or set it to false for one JSON response (default).

Create a response

Use POST /v2/responses. The endpoint is stateless: send the complete conversation in input on every request. Omit store or set it to false (true returns 400).

Nothing is stored for later retrieval — GET /v2/responses/{id} returns 404. GET /v2/responses and DELETE /v2/responses/{id} return 405 (documented in the API Reference alongside POST /v2/responses).

from sarvamai import SarvamAI
client = SarvamAI(api_subscription_key="YOUR_SARVAM_API_KEY")
response = client.responses.create(
    model="glm5.3",
    input="Explain database indexing in three short points.",
    store=False,
)
print(response.output)

Stream a response (optional)

Set stream to true when you want named server-sent events instead of one JSON body. Streams end with response.completed, response.incomplete, or response.failed; they do not emit a [DONE] sentinel. On glm5.3, streamed items can nest — pair events by item_id. Usage appears on the terminal event (there is no stream_options).

from sarvamai import SarvamAI
client = SarvamAI(api_subscription_key="YOUR_SARVAM_API_KEY")
stream = client.responses.create(
    model="glm5.3",
    input="Explain database indexing in three short points.",
    store=False,
    stream=True,
)
for event in stream:
    print(event.type)

Continue a conversation

The endpoint does not store response state. To continue a conversation, send the prior messages and outputs again in input. Do not use previous_response_id or conversation — both return 400.

from sarvamai import SarvamAI
client = SarvamAI(api_subscription_key="YOUR_SARVAM_API_KEY")
response = client.responses.create(
    model="gemma4",
    input=[
        {"role": "user", "content": "Name one advantage of a B-tree index."},
        {"role": "assistant", "content": "It keeps lookups efficient as data grows."},
        {"role": "user", "content": "When should I avoid one?"},
    ],
    store=False,
)

For message parts in input, text uses {"type": "input_text", "text": "…"} (not chat completions’ {"type": "text"}).

Reasoning (glm5.3, deepseekv4-flash)

Both reasoning models support three modes — low, high, and max — and Chat Completion V2 accepts all three directly for both. On this route (Responses), the two models differ:

Chat trace: choices[].message.reasoning_content.

Responses trace: on glm5.3, a reasoning item is always in output — read summary[0].text (content is null). Optional reasoning.summary: auto or detailed.

Reasoning tokens count toward max_output_tokens, which has no default cap on this route — omitting it means unbounded generation. On chat, the equivalent budget is max_tokens, which does default to 2048 when omitted — see the Chat Completion V2 API Reference.

Defaults when omitted (glm5.3)

Parameters

Refused or unsupported on this route

These return 400 (the error names the field): store: true, background: true, previous_response_id, conversation, max_tool_calls, prompt, item_reference.

On Responses, logprobs, top_logprobs, min_p, and repetition_penalty may be accepted and echoed without changing output. On Chat Completion V2, logprobs and top_logprobs are supported on sarvam-105b and gemma4. They aren’t supported on glm5.3, which returns a clean 400, or on deepseekv4-flash, which returns a 503 model_overloaded instead of a clean rejection — omit the field for that model. See Chat Completion V2 for details.

See the Responses API Reference for the complete request, response, error, and streaming-event schemas. Model-specific limits for glm5.3 are also summarized on the GLM-5.3 model page.