gpt-6-astra

GPT-6 Astra is an OpenAI model for complex reasoning, coding, research, and document work, including code review and multistep analysis. This integration covers text input and text output; check the relevant integration reference before using other input or output formats.

Use model gpt-6-astra and POST /v1/responses. Set your OpenAI SDK base URL to https://api.hiapi.ai/v1, supply a HiAPI API key, and use the Responses client. The same key can access models enabled for your account. Media models using /v1/tasks require a different request structure.

This integration uses a message array in input, streams events with stream=true, and leaves conversation storage to your client with store=false. Adapt Chat Completions messages and choices handling to Responses, and do not parse an entire SSE response as a single JSON object.

Set reasoning.effort to low, medium, high, xhigh, or max. Examples and Playground start with medium; try low for simpler requests and compare higher efforts on difficult work. Higher effort may increase latency and output tokens. Compare results and cost on representative tasks, and send the desired effort explicitly in API requests.

GPT-6 Astra does not support reasoning.effort=none. This integration does not expose temperature, top_p, or max_output_tokens controls. Follow this model's examples and check the exact endpoint contract when a parameter is rejected.

The published model limits are a 1,050,000-token context window and 128,000 output tokens. Input and generated content share the context budget, and reasoning consumes output budget. Maximum output is a specification limit, not the expected response length or an adjustable max_output_tokens control in this integration.

Content may already have arrived through response.output_text.delta or response.output_item.done. Accumulate those events and read status and usage at completion instead of requiring the final event to repeat every output item. Handle response.failed and response.incomplete separately.

With store=false, replay the user messages, assistant items, and tool results needed for the next turn in input. Replayed history counts as input again, with any reported cache hits billed at the cache-read rate. Keep the context needed for the task rather than unrelated history.

Each category uses the rate shown in live pricing. Total input includes cache reads and writes; subtract both when calculating ordinary input to avoid charging them twice. Reasoning tokens are already included in output. Page estimates are informational; account usage logs record settled charges.

The threshold uses total input, including cache reads and writes. Exactly 272,000 input tokens stays in the standard band; 272,001 selects the long-context band for the entire request, including output and cache usage. It is not a surcharge only on the excess. Expand the pricing details to compare both bands.

No. Cache writes and hits depend on server policy, reusable prefixes, and retention. Use cached_tokens and cache_write_tokens from usage. Zero means no usage was reported for that category; repeating a prompt alone is not evidence of a cache discount.

Declare functions in tools. Your application executes a returned function_call and sends function_call_output with the same call_id and required context. Use text.format.type=json_object for JSON, or json_schema for field constraints. Assemble streamed JSON before parsing and validating it; see the documented request examples.

Check the API key, exact model ID, endpoint, and request fields first. For missing text, verify SSE handling rather than reading only final output. For pricing questions, compare input, cache, output, and the selected context band against usage. Provide the request ID, error code, and time for support, without disclosing your API key.