OpenAI Responses profile

Status: openai-responses-v1-draft.1, a defined draft within cheapgpu.endpoint.v1-draft.4. Hosted inference, hosted checker and production supplier qualification for this profile are not externally available. The downloadable examples are synthetic; no model or supplier is offered through them.

This profile uses the native Responses body and typed SSE events. It does not convert Chat Completions requests or Anthropic Messages. The selected endpoint’s registered inference URL receives an HTTP POST; the example path is /v1/responses. Authentication and destination checks follow the shared endpoint security requirements.

Send a request

The bounded request example uses an invented supplier model mapping:

{
  "model": "example-responses",
  "input": "Say hello.",
  "store": false,
  "max_output_tokens": 64,
  "reasoning": {
    "effort": "low"
  }
}

Requests and responses use the frozen binding’s supplier_model_id as model. The returned string does not prove immutable model identity. The real source catalog still has unresolved revisions and no qualified profiles. The request’s output ceiling includes reasoning tokens and must fit the selected model’s output limit and the run/admission budget. Full input, output and model context limits must also be enforced by the implementation; the offline schema does not tokenize prompts or decode images.

max_output_tokens is optional and accepts null. When specified as a number, it must be an integer of at least 16, including visible output and reasoning tokens. Preserve omission and explicit null when forwarding the request. The validator uses the selected model’s declared output limit as a conservative internal ceiling when no numeric cap is supplied; it does not insert that value into the request or claim it is the provider’s default generation length. Execution and financial bounds must cover that ceiling before dispatch. These field semantics follow the official Responses create reference, checked October 28, 2026.

input accepts a string or an ordered list of messages and replayable output items. Messages use system, developer, user or assistant roles. Content is a string or an array of input_text and supported input_image parts. instructions is an optional string. Preserve the input order and contents.

stream and background may be omitted or null for foreground JSON execution. Set stream: true for SSE. truncation may be omitted, null, disabled or auto; omission uses the official disabled behavior. Requests remain unchanged, including valid nulls and omitted fields. instructions also accepts null.

store is optional and nullable; omitting it defaults to true. Preserve null and explicit false without rewriting the request. A response reports its effective boolean store mode. A stored response can be retrieved, inspected, continued or deleted through the native resource endpoints below.

Conversations, files, WebSocket and hosted tools remain support gaps. Unsupported fields and model combinations return structured errors; the platform does not remove fields or select another API, model or supplier.

Stored response lifecycle

Operation	Native endpoint	Result
Create	POST /v1/responses	Native Response, JSON or typed SSE
Retrieve	GET /v1/responses/{response_id}	Original Response from its source
List inputs	GET /v1/responses/{response_id}/input_items	Native list with data, cursors and has_more
Continue	POST /v1/responses with previous_response_id	A new Response using the original source
Delete	DELETE /v1/responses/{response_id}	{ "id": "resp_example", "object": "response.deleted", "deleted": true }

Use the returned response ID, including the ID in streaming response events. Resources belong to the buyer account. Every operation requires a currently valid API key for that account; knowing an ID does not grant access. A second valid key for the same account can access its stored responses. Revoked keys, unavailable accounts and keys from other accounts cannot.

A continuation is a new inference with a new authorization and reservation. It remains bound to the original supplier, endpoint configuration and model; unavailable original supply is an error. Send function results with the original call_id and your new instructions. Previous instructions do not carry over. Prior context counts toward the new input usage. No automatic inference retry or supplier switch is implied by a failed read, missing response or lost stream.

Input lists accept after, limit (1–100, default 20) and order (asc or desc, default desc). The supported include[] value is reasoning.encrypted_content. Retrieve supports that same include and foreground JSON or the background stream operations below. Cursors belong to the selected response. Content, function arguments, item IDs and call IDs remain unchanged.

Only a confirmed source deletion returns deleted: true. Timeouts and unknown results return errors. Deleted responses cannot be retrieved or continued. Foreground unstored responses cannot be retrieved; background responses have a temporary polling window. Foreground unstored responses do not provide stored-history continuation. For temporary background resources, the original source determines whether the requested resource operation or continuation is still available. Deleting a parent does not delete an already created child. Reads and deletion do not start generation or renew a financial deadline.

The official default retention is at least 30 days when stored, subject to OpenAI data retention exceptions. Suppliers must honor the declared retention contract. Wallet deadlines do not set response retention. This draft adds no storage fee or cleanup schedule. Synthetic conformance cannot establish 30-day durability or production readiness. See the official conversation state guide, retrieve reference, delete reference and input items reference.

Background tasks

Set background: true to create an asynchronous response. The source returns a Response with an ID; query GET /v1/responses/{response_id} while its status is queued or in_progress. Other statuses are terminal. The original client connection may close while the source continues the work.

background is optional and nullable; omission defaults to false. Forward it and store unchanged. Background requests can use store: false: the source retains temporary data for execution and polling. Retrieve the result within that source’s polling window. Resource operations keep the requested storage mode and depend on the original source’s availability. Data-retention exceptions apply to persistent storage; ZDR and Modified Abuse Monitoring have specific background retention rules in the official background guide.

Cancel with POST /v1/responses/{response_id}/cancel. Only background responses support this operation. The returned native Response describes the final state; a request that already completed can remain completed. Repeating cancellation returns the same final Response. A timeout is an unconfirmed cancellation, not proof that the source stopped.

For stream recovery, create with both background: true and stream: true. Track the sequence_number of stored events, excluding keepalive events whose counters belong to the current connection. Reconnect with:

GET /v1/responses/resp_example?stream=true&starting_after=42

The source sends events after that cursor. A suffix can begin inside an item or content part; it does not need a new response.created event. Keep original response/item IDs and event numbers. Validate the received suffix and terminal Response without manufacturing the missing prefix. Only responses originally created with stream: true can start a new stream.

Every query, cancellation and resumed stream uses the account-owned ID and original source. These operations do not start another inference or renew a wallet deadline. The platform keeps routing and bounded status evidence; full results and execution remain with the original source. Missing, expired or unavailable source data produces an error.

The background suite defines the shared supplier/Gateway cases separately from the existing baseline and stored lifecycle suites. A historical pass does not confer this capability. These draft contracts do not activate hosted inference or production eligibility. The official cancel reference and retrieve reference were checked October 29, 2026.

Reasoning and text options

reasoning may be omitted, null or an object. Its effort and summary fields are optional and nullable. Validate an explicit effort against the selected model’s declared efforts; omission and null retain the source’s native default. The API vocabulary includes minimal, but a model need not support it. This profile currently covers effort and summary; other reasoning controls remain gaps.

text may be omitted or an object, including an empty object. Its format is optional; omission uses text format. Neither text nor text.format accepts null in the current create reference. verbosity is optional and nullable, with explicit values low, medium and high; the documented default is medium. Preserve all valid omissions and values instead of inserting defaults.

For text.format.type: "json_schema", strict is optional and nullable, with false as its documented default. Only explicit true guarantees adherence to the supported supplied schema. Completed non-refusal output must be JSON in both JSON Schema and json_object modes; non-strict mode does not establish schema adherence. Refusal and incomplete results retain their separate handling.

The field-options suite uses the same cases for suppliers and Gateway. Existing reports do not prove this additional scope. These semantics follow the official Responses create reference, checked October 29, 2026; they do not activate hosted inference or production eligibility.

Functions and stateless continuation

tools contains native function definitions with type, name, parameters. parameters is required by the ordinary Responses function-tool reference and accepts an object schema or null. Do not import Chat Completions’ omission rule. Null supplies no schema: the validator asserts no invented parameter shape. Strict effective modes still require JSON arguments; explicit non-strict mode preserves the best-effort argument string. strict is optional and nullable; description may be omitted or null. tool_choice may be omitted and defaults to auto; explicit null is outside its official request union. parallel_tool_calls may be omitted or null, retaining the provider’s native default. Explicit false limits the response to one call. tool_choice accepts auto, none, required, or a native {"type":"function","name":"..."} selection. Function names must be unique.

strict: true requires every object property to be required and additionalProperties: false at every object level. An optional value can use a nullable type. strict: false explicitly requests non-strict generation; it does not authorize ignoring arguments or silently changing the chosen mode. Non-strict function arguments are best effort: their native string is preserved even when it is malformed JSON or fails the parameter schema. When a schema is supplied, strict-mode arguments must satisfy its effective strict schema. Function names, call IDs and one-call limits still apply in either mode.

For omitted/null strict, the validator checks an internal strict-normalized copy of the supported schema: object properties become required and additional properties are disabled recursively. The forwarded schema is unchanged. The official function calling guide specifies non-strict behavior when normalization is impossible. In that case the response’s matching function in tools must report strict: false, and the validator preserves best-effort argument strings. An explicit strict: true request still rejects unsupported strict schemas; it cannot change to non-strict. The supported schema subset includes typed if/then/else conditions for non-strict functions. These conditions are unsupported in strict mode. Broader JSON Schema support remains a gap. Null parameters are accepted without inventing a schema; the ordinary Responses tool reference requires the field.

Read every typed output item. A function_call contains a distinct item id, call_id, function name and string arguments. The application executes its function and sends a function_call_output with the original call_id and string output. Gateway does not execute arbitrary customer functions. Reject unknown generated names, duplicate call IDs and unmatched results. Validate generated arguments according to the effective mode. Replay prior argument strings unchanged rather than applying the current generation schema to history. parallel_tool_calls: false allows at most one call in a response.

For a continuation, replay the entire earlier input and every returned output item in order, then append the matching function results or new user input. Preserve reasoning encrypted_content, reasoning summaries, function identities and assistant phase values without editing them. Return a result for every pending function call before the next inference request. The tool example shows this sequence. It contains invented opaque reasoning data, not a usable encrypted token.

Reasoning and structured output

An explicit reasoning.effort must appear in the selected model’s documented set. Summary support also depends on the model. Do not replace an unsupported effort or infer hidden chain-of-thought text. See the official reasoning guide.

For strict structured output, set text.format to json_schema with name, schema and explicit strict: true. The structured example includes a complete strict request and response. The other JSON modes and their separate guarantees are described under Reasoning and text options above.

The strict structured-output subset supports objects, arrays, strings, numbers, integers, Booleans, null, scalar enums and one non-null type combined with null. An object supplies properties, all property names in required, and additionalProperties: false; an array supplies items. The root is an object and cannot use anyOf. Nested anyOf branches follow the same strict rules.

Use $defs for reusable schemas and $ref for references within the supplied schema. Both root recursion ("$ref": "#") and recursive definitions are supported. JSON Pointer escapes such as ~1 for / and ~0 for ~ are preserved. Each reference must resolve to a schema. A reference cycle must descend through a data property or array item; cycles that never consume instance data are rejected. See the recursive examples.

The same schema features apply to function parameters. When function strict is omitted or null, normalization visits definitions and anyOf branches in an internal copy; the supplied schema is forwarded unchanged. Explicit non-strict function arguments remain best effort. Non-strict JSON text modes require valid JSON without asserting schema adherence.

The schema suite adds shared reference, recursion, union and invalid-schema checks. An earlier conformance pass does not confer this scope. External references, named anchors, other schema keywords remain support gaps. The offline validator retains its separate 32-level physical schema traversal bound and its request/response byte limits. These local gaps do not redefine the official API’s supported schemas or limits.

Field constraints and schema limits

Strict schemas support string pattern and format; numeric minimum, maximum, exclusiveMinimum, exclusiveMaximum and multipleOf; and array minItems and maxItems. Supported formats are date-time, time, date, duration, email, hostname, ipv4, ipv6 and uuid. Time and date-time formats require a timezone; UUID values use a plain UUID, not a URN. Patterns use ECMA-style regular-expression search semantics. Numeric multiples use the canonical decimal values represented by the runtime, so 0.3 is a multiple of 0.1; validation does not round an invalid value into a valid one. Arbitrary numeric precision beyond that representation remains a gap.

The official strict-schema limits are:

• At most 5,000 object properties in total and 10 levels of nesting.
• At most 120,000 characters across property names, definition names, string enum values and string const values.
• At most 1,000 enum values across the schema.
• For an enum with more than 250 values, at most 15,000 characters across its string values.

References count the supplied definitions once for aggregate limits. The nesting check follows object and array containers through references and anyOf. Supported recursive schemas do not impose a ten-level limit on recursive instance data; response-size and runtime limits still apply.

These field constraints are unavailable in strict schemas for fine-tuned models. Applicability comes from the selected catalog revision’s structured_output_constraints value. An unknown value does not establish base model support and rejects strict use of these constraints. The synthetic catalog contains separate base and fine-tuned fixtures; neither is an offered model. Explicit non-strict function arguments remain best effort, and non-strict JSON text output guarantees valid JSON only. Function strict omitted or null retains the official effective-mode behavior described above; its forwarded request is unchanged and the returned tools must report an effective non-strict mode when strict normalization is unavailable.

The constraints suite and constraint examples apply the same checks to a supplier and Gateway. New scope requires a new check; an earlier passing report does not confer it. This follows the official Structured Outputs guide, checked October 29, 2026, and the JSON Schema format definitions.

Only a completed, non-refusal text result under explicit strict: true is checked for adherence to its requested schema. A native refusal content part is a refusal, even when response status is completed; it is not malformed schema output. An incomplete result can contain partial JSON and must not be relabeled as a complete structured answer. See the official Structured Outputs guide.

Image input

User content can include input_image with an inline base64 image_url and explicit detail: low, high, original or auto, subject to the selected model’s verified support. This revision accepts PNG, JPEG, WEBP and GIF data URLs; an implementation must validate the actual image and reject animated GIFs. The image example includes an invented prompt and a tiny inline PNG.

Remote image URLs and provider file IDs require additional fetch/ownership contracts and are rejected here. No image URL fetch is authorized by this profile. Input byte, image dimensions/count and model context limits remain mandatory; accepting the JSON shape alone is insufficient. Image tokens are part of native input usage, not a separately invented per-image charge. See the official vision guide.

Responses and terminal outcomes

For JSON, return an HTTP 200 response object with object: "response", stable id, created_at, declared model, status, ordered output, effective boolean store, error, incomplete_details and usage. This revision permits message, reasoning and function_call output items. Defined item metadata is preserved; unsupported item fields or types are protocol errors. Top-level response/event metadata can contain additional native fields. Top-level output_text is an SDK convenience, not a replacement for reading the native output array.

The terminal states have different meanings:

Status	Required details	Meaning
completed	Non-null valid usage; null error and incomplete details; completed output items	Generation finished; inspect for functions or refusal
failed	Non-null error; null incomplete details	Generation failed; usage may be unknown
cancelled	Background response; null error and incomplete details	Cancellation completed; usage may be unknown
incomplete	Null error; reason max_output_tokens or content_filter	Generation stopped with a partial result; usage may be unknown

queued and in_progress describe active background work and may appear in background JSON responses. Foreground JSON must be terminal. An HTTP error uses the native error object with message, type and optional nullable code/param. Invalid or unsupported requests return 400 or 422, invalid credentials 401 or 403, rate limits 429, and upstream failures a suitable 5xx. Preserve failures instead of manufacturing a response or switching models.

Streaming

With stream: true, return text/event-stream. Each SSE event name equals the JSON payload’s type; stored-event sequence numbers strictly increase. Keepalive counters do not advance the stored-event cursor. Start with exactly one response.created, followed by native lifecycle (including response.queued), output-item, content-part, text/refusal, function-arguments and reasoning-summary events as applicable. Part and item indices, item IDs, call IDs and response identity stay consistent. Deltas must agree with their done events and the final completed response.

Exactly one response.completed, response.failed, response.incomplete or error terminates the stream. A completed terminal response includes valid final usage and the output assembled from its item events. There is no Chat [DONE] sentinel or separate Chat usage chunk. Item/text/arguments done events do not establish response success. EOF without a terminal event is an interrupted, unknown result; partial text and a closed connection cannot manufacture success, zero usage, cancellation proof or permission to redispatch.

The SSE example shows text deltas and terminal usage. Conformance needs incremental arrival observations; multiple deltas saved in a file do not prove that a network response streamed. Native event names and shapes are checked against the official streaming reference and streaming guide.

Usage and financial boundaries

Counts are safe nonnegative JSON integers in native Responses fields. Platform versions, limits and timestamps remain canonical decimal strings in the shared run/report envelope. Never substitute missing usage with zeros.

Require total_tokens = input_tokens + output_tokens. Input details contain cached_tokens and cache_write_tokens; reads and writes are disjoint subsets of input_tokens. Positive writes require both lifetime counts in cache_write_tokens_details, whose ttl_30m_tokens + ttl_12h_tokens equals cache_write_tokens. Ordinary input is the remainder after reads and writes. When zero writes have no lifetime breakdown, zero is still an explicit reported count. output_tokens_details.reasoning_tokens is included in output_tokens and cannot exceed it. Do not add any of these subsets to their totals again. These relationships follow the official prompt caching guide and reasoning usage documentation.

This profile defines source usage semantics, not a marketplace tariff, trusted meter, quote formula, cache discount, usage acceptance policy or debit authority. All inference prices come from supplier offers; model metadata contains no rates. Failed, incomplete, refused and cancelled outcomes do not acquire a new charging rule from this draft. Existing bounded recovery and zero-charge terminal rules remain in force for unknown execution/usage; an observed supplier count alone cannot create buyer charges or supplier income.

Conformance cases

The Responses suite is independent of the Chat suite. Every case is required for the profile’s full capability set. A Chat pass does not qualify Responses, and a source catalog candidate cannot use a synthetic passing report to qualify.

Case ID	Evidence	Passing condition
destination_security	URL, DNS, destination and TLS	Shared egress policy; inline images cause no fetch
authentication	Missing and invalid credentials	Rejection before generation; no redirect
model_mapping	Declared mapping and unsupported model/effort	Exact returned mapping; explicit rejection
native_response	Bounded JSON response	Typed items, terminal status and valid usage
function_round_trip	Definition, call and stateless continuation	Explicit strict, valid arguments, matched IDs and unchanged replay
structured_output	Schema, refusal and partial-result probes	Strict completed output; distinct refusal and incomplete outcomes
image_input	Inline image/detail and unsupported mode	Preserved native content; unsupported inputs rejected
incremental_stream	Arrival times and typed events	Incremental deltas; consistent identity and final output
terminal_usage	Terminal event and count details	One terminal outcome; valid inclusion relationships
failure_and_interruption	Failure, incomplete, error and cut stream	Distinct failure/unknown outcomes; no fabricated completion or replay
invalid_request	Invalid/unsupported fields and schemas	Structured rejection without silent normalization
bounded_io	Controlled transport faults and budgets	Original limits/deadlines; no redirect or inference replay

The supplemental stored lifecycle suite requires defaults, retrieval, input pagination, function continuation, unstored rejection, nullable-store SSE and confirmed deletion. Suppliers and the Gateway use the same cases. A baseline pass alone does not qualify the stored lifecycle.

Download the schema, endpoint, run and report. Their values are invented examples, not production limits or evidence of live inference. Protocol conformance does not prove image recognition quality, immutable model identity, usage honesty or production readiness.