Direct Responses

Direct Responses is the direct endpoint for the Responses format: POST /ai/v2/direct/responses sends your request straight to the model you name. It exposes the entire Gloo AI model catalog through a single endpoint — text, vision, reasoning, tool use, and native image generation — with one request and response shape that works the same across every provider. Direct endpoints add no platform fee. You pay the model’s published rate (see the Models page and GET /platform/v2/models). Coming from another gateway? Direct endpoints cost what you would pay going straight to the model providers. It takes the same request body as the guarded Responses endpoint; the difference is what runs around it. Nothing here applies guardrails, output moderation, values-alignment (tradition), model_family selection or auto-routing. Choose this when your application owns its own safety and prompting; choose guarded Responses when it should inherit Gloo’s. See Which endpoint should I use? for the full comparison across all three endpoint families.

New to Gloo AI? Direct Responses is a good place to start. If you want Gloo’s guardrails and values-alignment applied, switch to the guarded Responses endpoint: same request shape, different path. If you already use Completions V2, it remains fully supported and backwards-compatible — see Moving from Completions to Responses.

Why the Responses API

The Responses API offers a more capable, forward-looking request shape that the broader ecosystem is standardizing on:

One shape for every modality. Text, image input (vision), and image generation all use the same input array and the same typed output array — no separate endpoints or bespoke payloads per capability.
OpenAI-compatible. The request and response formats mirror the OpenAI Responses API, so existing tooling, SDKs, and mental models carry over directly. Point your base URL at https://platform.ai.gloo.com/ai/v2/direct and go.
Typed, structured output. Responses come back as an output[] array of typed items (message, image_generation_call, reasoning, tool calls) instead of a single opaque choices[].message.content string — easier to parse, and extensible as new item types arrive.
Built for multimodal. Native image generation and image input are first-class, not bolted on. The same endpoint that answers a text prompt can return a generated image.

If you are starting a new integration, build on the Responses API.

Endpoint

URL: https://platform.ai.gloo.com/ai/v2/direct/responses Operation: POST

curl -X POST 'https://platform.ai.gloo.com/ai/v2/direct/responses' \
  -H "Authorization: Bearer $GLOO_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "gloo-anthropic-claude-sonnet-4.6",
    "input": [
      { "role": "user", "content": "Explain prompt caching in two sentences." }
    ]
  }'

Authentication is identical to the rest of the platform — send your API key as a Bearer token. See Generate API Keys.

Request format

The Responses API uses input instead of messages, and a few renamed fields. If you know the chat-completions format, the mapping is small:

Responses API	Chat Completions equivalent	Notes
`input`	`messages`	A string, or an array of input items (`role` + `content`).
`instructions`	`system` message	Top-level system / developer instructions.
`max_output_tokens`	`max_tokens`	Cap on generated tokens.
`model`	`model`	A Gloo model ID — see Supported Models.

Parameter	Type	Required?	Description
`model`	string	Yes	Gloo model ID (e.g. `gloo-anthropic-claude-sonnet-4.6`).
`input`	string \| array	Yes	A plain string prompt, or an array of typed input items.
`instructions`	string	No	System-level instructions applied to the request.
`max_output_tokens`	integer	No	Maximum number of tokens to generate.
`temperature`	float	No	Sampling temperature.
`top_p`	float	No	Nucleus sampling.
`tools`	array	No	Tool / function definitions. See Tool Use.
`tool_choice`	string \| object	No	Controls tool selection.
`stream`	boolean	No	Stream the response as SSE events (default `false`).
`reasoning`	object	No	`effort` (`none`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max`) sets how much a reasoning model thinks; `summary` (`auto`, `concise`, `detailed`) asks for the reasoning, returned as a `reasoning` item in `output[]` and streamed as reasoning events before the answer. See Reasoning summaries.
`response_format`	object	No	Structured-output / JSON schema controls.
`prompt_cache_key`	string	No	Improves cache-hit routing — see Prompt Caching.
`image_generation`	object	No	Image-generation options (`quality`, `size`) for image-capable models.

Conversation state is managed client-side: send the full conversation in input on every request. previous_response_id and conversation (OpenAI’s server-side conversation chaining) are not supported, and a model’s reasoning is not carried from one request to the next. See Reasoning across turns.

This is a direct endpoint: /ai/v2/direct/responses does not apply Gloo’s guarded pipeline. Requests here call the exact model you specify with no additional processing. None of the following runs:

Input guardrails and output moderation
Values-alignment (tradition)
model_family selection and auto-routing

Want the same request body with those applied? Use the guarded Responses endpoint at /ai/v2/guarded/responses — same body, different URL. Completions V2 and Grounded Completions are guarded too, on the Chat Completions shape.“Direct” describes this URL, not the Responses format in general: the same format is served by the guarded endpoint above and by Grounded Responses, which adds retrieval-augmented (RAG) generation over your own content.

Response format

Responses return a typed output[] array. Each item has a type; a normal text answer arrives as a message item, a generated image as an image_generation_call item.

{
  "id": "resp_...",
  "object": "response",
  "model": "gloo-anthropic-claude-sonnet-4.6",
  "output": [
    {
      "type": "message",
      "role": "assistant",
      "content": [
        { "type": "output_text", "text": "Prompt caching reuses processed prompt tokens..." }
      ]
    }
  ],
  "usage": { "input_tokens": 24, "output_tokens": 38, "total_tokens": 62 }
}

Streaming

Set "stream": true to receive the response as Server-Sent Events. Each event has an event: line and a data: line carrying a typed JSON payload:

event: response.output_item.added
data: {"type":"response.output_item.added","output_index":0,"item":{"id":"msg_...","type":"message","role":"assistant"}}

event: response.content_part.added
data: {"type":"response.content_part.added","item_id":"msg_...","part":{"type":"output_text","text":""}}

event: response.output_text.delta
data: {"type":"response.output_text.delta","item_id":"msg_...","delta":"Prompt "}

event: response.output_text.delta
data: {"type":"response.output_text.delta","item_id":"msg_...","delta":"caching "}

event: response.content_part.done
data: {"type":"response.content_part.done","item_id":"msg_...","part":{"type":"output_text","text":"Prompt caching reuses..."}}

event: response.output_item.done
data: {"type":"response.output_item.done","output_index":0,"item":{"id":"msg_...","type":"message",...}}

event: response.completed
data: {"type":"response.completed","response":{"id":"resp_a1b2c3",...,"output":[...],"usage":{...}}}

This is the stream from an OpenAI model served over OpenAI’s Responses API. For other models, Gloo converts the stream to this format, with two differences: response.completed (or response.incomplete) carries the response’s top-level fields (id, object, status, usage and the request settings), not nested under a response key and without output[], and text deltas identify their item by output_index rather than item_id. Build the answer from the events before the final one. Key event types to handle:

response.output_item.added / response.output_item.done — mark the start and end of each typed item in output[] (including message, image_generation_call, and function_call).
response.content_part.added / response.content_part.done — mark the start and completion of a content part within an item. response.content_part.done is the signal that a message’s text is complete, followed by response.output_item.done.
response.output_text.delta — incremental text tokens for a message item.
response.function_call_arguments.delta — incremental tool-call argument tokens for a function_call item.
response.completed — emitted once when the response is finished. For OpenAI models served over OpenAI’s Responses API, its response object includes the full output[] array and usage; for other models the payload is the response’s top-level fields and usage, without output[]. An answer cut off at max_output_tokens ends with response.incomplete instead.

Errors follow the direct endpoint error contract: a short message you can show your end users, a developer_message, and an X-Gloo-Error-Code header. A streamed request that fails before any output gets the same HTTP status and body as a non-streamed one (a raised exception in the SDK). A stream that fails after output has started ends with a response.failed event, as in OpenAI’s Responses API: response.error.code is the string error code, and Gloo adds the numeric gloo_code, developer_message and retryable. See Streaming on the direct endpoints.

Reasoning summaries

Set reasoning.effort to choose how much a reasoning model thinks, and reasoning.summary (auto, concise or detailed) to get a summary of its reasoning back as a reasoning item in output[]. Without it, OpenAI and Claude models normally return no summary. A non-streamed response carries the summary for every model that returns one. On a stream, the reasoning arrives as a reasoning item with OpenAI’s events before the answer: response.reasoning_summary_text.delta, or response.reasoning_text.delta for models outside the Anthropic, Google and OpenAI families (details). An effort the model doesn’t run as sent is listed in ignored_params as reasoning.effort=<level>. This includes Claude Opus 5.5, Sonnet 5.5 and Haiku 5.5, and the earlier Opus 5, Sonnet 5, Fable 5 and Fable 5.1. These Claude models always think: an effort of none runs them at low and returns no summary, and minimal runs them at low and returns the summary when reasoning.summary is set. They decide how much to reason, so at a low effort on an easy prompt they may return no summary. For examples on every endpoint and in every language, see Reasoning. A request for a summary:

curl -X POST 'https://platform.ai.gloo.com/ai/v2/direct/responses' \
  -H "Authorization: Bearer ${GLOO_API_KEY}" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "gloo-anthropic-claude-opus-5.5",
    "reasoning": { "effort": "medium", "summary": "auto" },
    "max_output_tokens": 4000,
    "input": "A train leaves at 9:40 and arrives at 13:05. How long is the trip? Answer in one sentence."
  }'

The summary comes back as a reasoning item before the answer. It has an id and a summary, and no encrypted_content:

{
  "id": "resp_...",
  "object": "response",
  "created_at": 1792527259,
  "model": "gloo-anthropic-claude-opus-5.5",
  "status": "completed",
  "max_output_tokens": 4000,
  "reasoning": { "effort": "medium", "summary": "auto" },
  "output": [
    {
      "id": "rs_...",
      "type": "reasoning",
      "summary": [
        { "type": "summary_text", "text": "From 9:40 to 13:05 is 3 hours and 25 minutes.\n\n" }
      ]
    },
    {
      "id": "msg_...",
      "type": "message",
      "role": "assistant",
      "status": "completed",
      "content": [
        { "type": "output_text", "text": "The trip lasts **3 hours and 25 minutes**.", "annotations": [] }
      ]
    }
  ],
  "usage": {
    "input_tokens": 45,
    "input_tokens_details": { "cached_tokens": 0 },
    "output_tokens": 41,
    "output_tokens_details": { "reasoning_tokens": 0 },
    "total_tokens": 86
  }
}

Reasoning across turns

Reasoning models can return a reasoning item in output[] with a summary of how they reasoned. Gloo does not carry a model’s reasoning from one request to the next: each request is reasoned from the conversation you send in input.

What comes back

Reasoning items keep their id and summary. They never include encrypted_content, in a non-streamed response or in any streamed event, and that includes requests that ask for include: ["reasoning.encrypted_content"]. That include value is accepted, not rejected; it just returns nothing.

What happens to reasoning you send back

You can still send output items back in input, reasoning items included. The request is not rejected: Gloo removes the reasoning state before calling any model and answers normally.

Any reasoning item that carries encrypted_content is removed, whatever the value is: an OpenAI blob saved from an earlier response, a value from another provider, or anything else.
If the most recent assistant turn loses a reasoning item, every reasoning item in the request is removed, so the model sees a conversation with no reasoning in it rather than reasoning from older turns only.
Items tied to a removed reasoning item are adjusted so the request stays valid for OpenAI models. In each assistant turn that lost reasoning:
- a function_call is sent without its id; its call_id, and your function_call_output for it, are kept;
- an assistant message is sent without its id, with its text kept, or removed if it has no text;
- hosted and client tool calls OpenAI ties to the reasoning by id (web_search_call, file_search_call, image_generation_call, code_interpreter_call, computer_call, local_shell_call, the MCP items and similar) are removed, together with your items that answer them;
- an item_reference to anything removed or sent without its id is removed.
Requests with no reasoning items are unchanged.

Removing a hosted tool call removes its results from what the model sees. Text the assistant already wrote from those results stays in the conversation.

How to tell what was removed

Direct Responses reports removed reasoning in ignored_params. input.reasoning=<n> is the number of reasoning items removed because they carried encrypted_content or went with one that did, and input.reasoning_paired=<n> the number of other items removed with them: hosted tool calls, your items answering them, assistant messages with no text and item_reference items (omitted when there were none). input.reasoning does not count the other reasoning items on a request that is converted for the model, those without encrypted_content that did not go with one that did, though those are still not sent to it. Here one reasoning item carrying an OpenAI blob was sent back:

{
  "id": "resp_...",
  "object": "response",
  "model": "gloo-openai-gpt-5.4-nano",
  "status": "completed",
  "output": [ ... ],
  "ignored_params": {
    "params": ["input.reasoning=1"],
    "model": "gloo-openai-gpt-5.4-nano",
    "reason": "These parameters were ignored and did not affect the response: the model does not accept them, or this surface does not forward them to the provider."
  }
}

On a stream, the names are listed in the X-Ignored-Params header without counts, for example X-Ignored-Params: input.reasoning, input.reasoning_paired. A check on a non-streamed response:

def reasoning_items_removed(response: dict) -> int:
    """How many reasoning items Gloo removed from this request's input."""
    for entry in (response.get("ignored_params") or {}).get("params", []):
        if entry.startswith("input.reasoning="):
            return int(entry.split("=", 1)[1])
    return 0

With the OpenAI Python SDK, pass response.model_dump(): ignored_params is a Gloo addition, so the SDK keeps it as an extra field rather than a typed attribute. Direct Responses does not return a reasoning_carryover object or an X-Gloo-Reasoning-Carryover header. Those are how the guarded Responses and Grounded Responses endpoints report removals, described next.

The `reasoning_carryover` object on Responses and Grounded Responses

It appears only when your input contained at least one reasoning item, or when you asked for include: ["reasoning.encrypted_content"]. Every reasoning item you send back is removed and listed in dropped, including one sent back exactly as it was received, with no encrypted_content. On a non-streamed response the object is a top-level field. Here the first turn’s output was sent back as received, with one reasoning item:

{
  "id": "resp_...",
  "object": "response",
  "model": "gloo-openai-gpt-5.4-nano",
  "status": "completed",
  "output": [ ... ],
  "usage": { ... },
  "reasoning_carryover": {
    "received": 1,
    "carried": 0,
    "dropped": [{ "id": "rs_...", "reason": "not_gloo_state" }],
    "not_sealed": null
  }
}

Field	Meaning
`received`	The number of `reasoning` items in your `input`.
`carried`	The number of reasoning items passed to the model as reasoning state. Always `0`.
`dropped`	One entry per removed `reasoning` item, in input order: its `id` (`null` when the item had no string `id`, or one longer than 256 characters) and a `reason`.
`not_sealed`	`"unsupported_route"` when you asked for `include: ["reasoning.encrypted_content"]`, otherwise `null`. Gloo returns no reasoning state for you to send back.
`paired_removed`	The number of other items removed with that reasoning. Omitted when `0`.

Reasons in dropped:

`reason`	Meaning
`not_gloo_state`	The item carried reasoning state Gloo did not issue, such as an OpenAI `encrypted_content` blob, or no reasoning state at all, as in a reasoning item sent back exactly as Gloo returned it. These endpoints convert the conversation for the model, so `reasoning` items are never sent to it.
`unsupported_route`	The item carried Gloo-issued reasoning state that this endpoint does not use.
`invalid`	The item carried a Gloo reasoning-state value in a format Gloo does not recognize.

On a stream, the counts arrive in the X-Gloo-Reasoning-Carryover response header (for example received=1, carried=0, dropped=1), and the object arrives as a top-level field of the final response.completed or response.incomplete event. See Responses: Reasoning across turns.

What to do

Keep sending the full conversation in input on every request: your messages, the assistant’s messages, function calls and your function call outputs. You can send output items back as you received them; Gloo removes what it can’t carry and tells you.
Treat reasoning summaries as display text. Show them to your users if they help; sending them back does not give the model its earlier reasoning.
Restate what the model needs. If a later turn depends on something only a hosted tool call returned, such as web search results, put it in a message: that call can be removed with its turn’s reasoning.
Don’t build on encrypted_content. Gloo does not return it, and removes it when you send it.

For example, a second turn that sends the first turn’s output back as it was received, reasoning item included, followed by the next user message:

{
  "model": "gloo-openai-gpt-5.4-nano",
  "reasoning": { "effort": "low" },
  "input": [
    { "role": "user", "content": "How many positive integers n below 1000 make n^2 + 3n + 5 divisible by 121? Give the count in one sentence." },
    {
      "id": "rs_...",
      "type": "reasoning",
      "content": [],
      "summary": [{ "type": "summary_text", "text": "**Confirming the solution count** ..." }]
    },
    {
      "id": "msg_...",
      "type": "message",
      "role": "assistant",
      "status": "completed",
      "phase": "final_answer",
      "content": [{ "type": "output_text", "text": "So there are 0 positive integers n < 1000.", "annotations": [], "logprobs": [] }]
    },
    { "role": "user", "content": "Now double that number and say only the result." }
  ]
}

The request succeeds. Nothing in it carries encrypted_content, so for this OpenAI model nothing is removed: there is no input.reasoning entry in ignored_params. The model reasons afresh from the conversation.

Multi-turn behavior

What changes depends on how the model is served. OpenAI models served over OpenAI’s Responses API, including its reasoning models. Gloo passes your input items to OpenAI’s Responses API, so all of the rules in What happens to reasoning you send back apply. Before this change, encrypted_content you sent back was passed to OpenAI and gave the model its earlier reasoning; now it is removed. A reasoning item without encrypted_content is passed on as sent when neither its own turn nor the most recent assistant turn lost a reasoning item. All other models. Gloo converts your conversation into the format the model accepts, and reasoning items have never been sent to these models. What the model sees does not change. The difference is that removals are now reported in ignored_params, which counts only the reasoning items that carried encrypted_content, or went with one that did; the others are still not sent to the model. An OpenAI-model request that cannot be passed to OpenAI as sent, for example because the first attempt failed before any output, is served this way too.

Moving off `encrypted_content` and `previous_response_id`

If you sent encrypted_content back to keep OpenAI reasoning across turns: the request still succeeds, and the model now reasons from the conversation alone. Code that stores the blob can stay or go; Gloo removes it either way.
If you asked for include: ["reasoning.encrypted_content"]: it returns nothing and you can remove it.
If you used previous_response_id or conversation: send the earlier turns in input instead. Don’t send these parameters, or background: true: for those OpenAI models they are passed to OpenAI as sent and the request can fail, and for other models they have no effect. Gloo sets store on requests to OpenAI itself, so a store value you send has no effect either. Where they have no effect, they can be listed in ignored_params.

Multimodal

Image input (vision)

Pass images as input items alongside text. Any vision-capable model accepts them:

curl -X POST 'https://platform.ai.gloo.com/ai/v2/direct/responses' \
  -H "Authorization: Bearer $GLOO_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "gloo-google-gemini-3.1-pro",
    "input": [
      { "role": "user", "content": [
        { "type": "input_text", "text": "Describe this image." },
        { "type": "input_image", "image_url": "https://example.com/photo.jpg" }
      ]}
    ]
  }'

Images may be supplied as a remote URL or a base64 data: URI.

Image generation

Image-capable models return a generated image as an image_generation_call output item (base64 result). Optional image_generation controls (quality, size) are forwarded to providers that support them.

curl -X POST 'https://platform.ai.gloo.com/ai/v2/direct/responses' \
  -H "Authorization: Bearer $GLOO_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "gloo-google-gemini-3-pro-image",
    "input": [
      { "role": "user", "content": [
        { "type": "input_text", "text": "A watercolor painting of a lighthouse at sunset." }
      ]}
    ]
  }'

The generated image comes back as a typed image_generation_call item in output[]. The result field carries the image as a base64-encoded string:

{
  "id": "resp_...",
  "object": "response",
  "model": "gloo-google-gemini-3-pro-image",
  "output": [
    {
      "type": "image_generation_call",
      "id": "ig_...",
      "status": "completed",
      "result": "iVBORw0KGgoAAAANSUhEUgAA...<truncated base64 PNG>..."
    }
  ],
  "usage": { "input_tokens": 14, "output_tokens": 1290, "total_tokens": 1304 }
}

Decode the base64 result to get the image bytes. Optional image_generation controls (quality, size) are forwarded to providers that support them.

OpenAI: image generation via the image_generation tool

OpenAI’s image generation runs as an image_generation tool on a GPT-5 model — gpt-image-1 is not a top-level Responses model (exactly as on OpenAI’s own API, where it is an Images API model rather than a Responses one). Call a GPT-5 model and attach the tool; the model decides when to draw and can combine the image with text in the same response. The tool accepts an optional model field to pin its backing image model (e.g. gpt-image-1) plus quality/size controls:

curl -X POST 'https://platform.ai.gloo.com/ai/v2/direct/responses' \
  -H "Authorization: Bearer $GLOO_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "gloo-openai-gpt-5-mini",
    "input": [
      { "role": "user", "content": [
        { "type": "input_text", "text": "A watercolor painting of a lighthouse at sunset." }
      ]}
    ],
    "tools": [
      { "type": "image_generation", "model": "gpt-image-1", "quality": "low" }
    ]
  }'

The generated image arrives as the same image_generation_call output item shown above (alongside any reasoning and message items from the GPT-5 model). Image editing works through the same mechanism: include an input_image part in the conversation and it becomes the tool’s edit source. See Supported Models for which models support image input and image generation.

Pricing & token spend

The Responses API is billed per token at each model’s standard rates — there is no separate or premium price for using /responses. Cost is driven entirely by the model you select and the tokens you consume:

total_cost = input_tokens  × input_rate
           + cached_tokens  × cache_read_rate
           + output_tokens  × output_rate

Per-model rates. Input and output rates vary by model. The live rates are on the Supported Models page and programmatically on GET /platform/v2/models.
Prompt caching reduces input cost when prompt prefixes repeat — cached tokens are billed at a discounted cache_read rate. See Prompt Caching.
Image generation is billed using the image model’s token accounting; check the model’s rates on the models endpoint.
No platform fee. Direct endpoints bill the published per-model rate exactly. The 6.5% platform fee applies to the guarded endpoints, where guardrails run, and to Grounded Completions, which runs on the guarded pipeline. Grounded Responses carries no platform fee.

Track real spend in the Gloo Studio billing dashboard and API usage.

Supported models

The Responses API works across the full Gloo AI catalog — Anthropic, OpenAI, Google, and open-source families — including the multimodal and image-generation models. Use the Model ID as the model field. The complete, live list (with capabilities and pricing) is on the Supported Models page.

Moving from Completions to Responses

Completions V2 (/ai/v2/guarded/chat/completions) is fully supported and backwards-compatible — existing integrations continue to work unchanged, and it remains the home of auto-routing and model_family selection. Guardrails, output moderation and tradition have already reached the Responses shape on the guarded Responses endpoint, and RAG grounding on Grounded Responses. The Responses shape is the better fit for new work because it is the OpenAI-compatible standard and makes multimodal (vision + image generation) first-class. Below the URL, the migration is mostly a rename:

Completions V2	Responses API
`POST /ai/v2/guarded/chat/completions`	`POST /ai/v2/guarded/responses`
`messages`	`input`
`system` role message	`instructions`
`max_tokens`	`max_output_tokens`
`choices[].message.content` (string)	`output[]` (typed items)

The URL is the one row that is not a rename. Completions V2 applies guardrails, output moderation and tradition; this page’s endpoint applies none of them. POST /ai/v2/guarded/responses is the like-for-like destination — it keeps the governance layer while changing the request shape. Move to POST /ai/v2/direct/responses only if dropping that layer is a decision you are making deliberately, and the body stays identical either way.

// Completions V2
{
  "model": "gloo-anthropic-claude-sonnet-4.6",
  "messages": [
    { "role": "system", "content": "You are a helpful assistant." },
    { "role": "user", "content": "Hello" }
  ],
  "max_tokens": 256
}

// Responses API (equivalent)
{
  "model": "gloo-anthropic-claude-sonnet-4.6",
  "instructions": "You are a helpful assistant.",
  "input": [
    { "role": "user", "content": "Hello" }
  ],
  "max_output_tokens": 256
}

tradition, guardrails and output moderation are available now on the guarded Responses endpoint, and grounded (RAG) responses on Grounded Responses. Auto-routing and model_family selection remain on Completions V2, and grounding with citation metadata on Grounded Completions. Choose this page’s direct endpoint when your application owns its own safety and prompting.

Supported Models — model IDs, capabilities, and live pricing
Grounded Responses — RAG-grounded answers in the Responses API format
Prompt Caching — reduce cost and latency with cached prompt prefixes
Tool Use — function calling
Completions V2 — routing, values-alignment, and backwards-compatibility

Start Here

Inference and APIs

Data Engine

Studio

Gloo Code

Learn More

Legacy

Direct Responses

Why the Responses API

Endpoint

Request format

Response format

Streaming

Reasoning summaries

Reasoning across turns

What comes back

What happens to reasoning you send back

How to tell what was removed

The `reasoning_carryover` object on Responses and Grounded Responses

What to do

Multi-turn behavior

Moving off `encrypted_content` and `previous_response_id`

Multimodal

Image input (vision)

Image generation

OpenAI: image generation via the image_generation tool

Pricing & token spend

Supported models

Moving from Completions to Responses

​Why the Responses API

​Endpoint

​Request format

​Response format

​Streaming

​Reasoning summaries

​Reasoning across turns

​What comes back

​What happens to reasoning you send back

​How to tell what was removed

​The reasoning_carryover object on Responses and Grounded Responses

​What to do

​Multi-turn behavior

​Moving off encrypted_content and previous_response_id

​Multimodal

​Image input (vision)

​Image generation

​OpenAI: image generation via the image_generation tool

​Pricing & token spend

​Supported models

​Moving from Completions to Responses

​Related Documentation

Why the Responses API

Endpoint

Request format

Response format

Streaming

Reasoning summaries

Reasoning across turns

What comes back

What happens to reasoning you send back

How to tell what was removed

The `reasoning_carryover` object on Responses and Grounded Responses

What to do

Multi-turn behavior

Moving off `encrypted_content` and `previous_response_id`

Multimodal

Image input (vision)

Image generation

OpenAI: image generation via the image_generation tool

Pricing & token spend

Supported models

Moving from Completions to Responses

Related Documentation