/responses endpoint — text, vision, reasoning, tool use, and native image generation — with one request and response shape that works the same across every provider. It gives you direct access to the exact model you request. If your application relies on Gloo’s guardrails, output moderation, values-alignment (tradition), or intelligent routing, use Completions V2; see Which API should I use?.
New to Gloo AI? Start here. The Responses API is the standard surface going forward. 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
inputarray and the same typedoutputarray — 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 Gloo 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 opaquechoices[].message.contentstring — 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.
Which API should I use?
When in doubt, start with the Responses API — it’s the default for new work, and Completions V2 / Grounded Completions stay available whenever you need routing, values-alignment, or citation metadata.
Endpoint
URL:https://platform.ai.gloo.com/ai/v1/responses
Operation: POST
Request format
The Responses API usesinput instead of messages, and a few renamed fields. If you know the chat-completions format, the mapping is small:
Conversation state is managed client-side by passing the full
input history on each request. The previous_response_id parameter (used by OpenAI’s Responses API for server-side conversation chaining) is not supported.Response format
Responses return a typedoutput[] array. Each item has a type; a normal text answer arrives as a message item, a generated image as an image_generation_call item.
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:
response.output_item.added/response.output_item.done— mark the start and end of each typed item inoutput[](includingmessage,image_generation_call, andfunction_call).response.content_part.added/response.content_part.done— mark the start and completion of a content part within an item.response.content_part.doneis the signal that a message’s text is complete, followed byresponse.output_item.done.response.output_text.delta— incremental text tokens for amessageitem.response.function_call_arguments.delta— incremental tool-call argument tokens for afunction_callitem.response.completed— emitted once when the response is finished; the final payload includes the fulloutput[]array andusage.
error event in the stream.
Multimodal
Image input (vision)
Pass images as input items alongside text. Any vision-capable model accepts them:data: URI.
Image generation
Image-capable models return a generated image as animage_generation_call output item (base64 result). Optional image_generation controls (quality, size) are forwarded to providers that support them.
image_generation_call item in output[]. The result field carries the image as a base64-encoded string:
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 animage_generation tool on a GPT-5 model — gpt-image-1 is not a model id (exactly as on OpenAI’s own API). 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:
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:
- 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_readrate. See Prompt Caching. - Image generation is billed using the image model’s token accounting; check the model’s rates on the models endpoint.
- A 5.5% Studio markup applies to all segments, consistent with the rest of the platform.
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 themodel field. The complete, live list (with capabilities and pricing) is on the Supported Models page.
Moving from Completions to Responses
Completions V2 (/ai/v2/chat/completions) is fully supported and backwards-compatible — existing integrations continue to work unchanged, and it’s where Gloo’s auto-routing, model_family selection, tradition (values-aligned) responses, and guardrailed completions live today, while those capabilities make their way to the Responses API. Grounding has already arrived: Grounded Responses provides RAG in the Responses API format.
The Responses API is the recommended surface for new work because it standardizes on the OpenAI-compatible Responses shape and makes multimodal (vision + image generation) first-class. The migration is mostly a rename:
Auto-routing,
model_family, tradition, and guardrailed responses are planned for the Responses API; grounded (RAG) responses are available now via Grounded Responses. For the rest — including grounding with citation metadata — reach for Completions V2 / Grounded Completions when you need them today, and choose the Responses API for OpenAI-compatible, multimodal, direct-model integrations.Related Documentation
- 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

