Skip to content

OpenAI Chat text profile

Draft stateless text request, response, streaming, and usage requirements.

Status: defined draft openai-chat-text-v1-draft.1. No public buyer inference API implements this profile yet. This is a CheapGPU compatibility subset, not a promise to implement the full OpenAI API.

POST JSON to the registered full inference_url using bearer authentication. The example path is /v1/chat/completions; the registered path is authoritative. Do not forward a buyer’s platform credential to a supplier.

The request example is:

{
"model": "example-local-model",
"messages": [{"role": "user", "content": "Describe how rain forms."}],
"max_completion_tokens": 64,
"stream": true,
"stream_options": {"include_usage": true}
}

model is the mapped supplier ID. messages is a nonempty array of text messages with system, user, or assistant roles. max_completion_tokens is a required positive integer within the admitted output ceiling. stream is required. For stream: true, require stream_options.include_usage: true; omit stream_options for stream: false.

The request schema rejects other fields, including max_tokens, tools, response_format, sampling controls, multimodal content, and stored conversation references. These exclusions define this first draft, not the upstream API. An endpoint must return 400 or 422 for a request outside this subset rather than silently ignoring its unsupported parameters. Unknown model IDs return 400 or 404 without falling back to another model. Missing or invalid authentication returns 401 or 403 before inference starts.

For stream: false, return HTTP 200 with application/json and the completion schema. It requires an ID, object: "chat.completion", integer created, the same supplier_model_id sent in the request, exactly one choice at index 0, an assistant message, a finish reason, and usage. The message content is text, or null for an explicitly filtered result. The defined finish reasons are stop, length, and content_filter; their presence does not decide billability.

For stream: true, return HTTP 200 with text/event-stream. Parse complete SSE events, not TCP reads. Flush generated content as it becomes available; a final JSON response wrapped in SSE is insufficient evidence of incremental delivery.

Every JSON chunk has the same ID, creation timestamp, and declared response model. Non-usage chunks have one index-0 choice with a delta and a null or terminal finish reason. A role-only delta may precede content. Only assistant text deltas are supported. After the terminal choice, send one usage-only chunk with choices: [], then data: [DONE]. Do not send content after the terminal choice, multiple terminal choices, duplicate usage summaries, or events after [DONE]. Comment-only SSE heartbeats do not count as content or completion.

The stream example shows the event order. JSON Schema validates each chunk; the checker must separately validate order, identity consistency, incremental arrival, and termination.

This usage-chunk convention follows the official OpenAI request reference. The upstream streaming reference describes chunk fields. The stricter subset and ordering requirements here are CheapGPU draft rules, not claims about every upstream endpoint.

Require nonnegative safe-integer prompt_tokens, completion_tokens, and total_tokens, with total equal to their sum. They map to reported input and output tokens. Optional usage-detail fields are retained as evidence; they do not introduce cache, reasoning, or other price dimensions.

Missing usage, an upstream error, malformed data, or EOF without the required terminal sequence cannot be treated as confirmed billable completion. After headers, an error may appear as an SSE data object containing error; record failure and never append a synthetic successful finish or usage summary. Non-2xx JSON errors use the error schema. There are no automatic inference retries, including for 429 or 5xx.

A complete protocol response is still only evidence. Real usage acceptance, collection, length/filtered-result billing, partial-output billing, and cancellation billing remain release blockers. Unknown execution or billable usage follows the original bounded deadline and zero-charge closure described in Endpoint integration.