Cómo llamar a gpt-6.1 Sol a través de HiAPI: curl, Python y prueba real de streaming (tutorial en chino)

Objetivo y requisitos de este artículo

Al terminar este artículo, habrás ejecutado gpt-6.1 Sol con una sola solicitud HTTP — el modelo de texto de la familia GPT-6.1 Sol en HiAPI especializado en programación compleja, análisis de documentos y razonamiento de varios pasos — y obtendrás la respuesta en streaming. Tendrás ejemplos de curl y Python listos para copiar, además de los tres puntos donde es más fácil tropezar: el endpoint es /v1/responses (no /v1/chat/completions), el streaming es obligatorio y input debe ser un array.

Requisitos: una API Key de HiAPI. Créala y guárdala bien en la página de claves de API; envíala en cada solicitud mediante Authorization: Bearer sk-<tu key>.

gpt-6.1 Sol es un modelo solo de texto (conversación / razonamiento / programación); no genera imágenes. Consulta las capacidades y la prueba en línea en la página del modelo gpt-6.1 Sol.

Ejemplo mínimo funcional

La familia Sol usa la Responses API: POST /v1/responses. Dos reglas estrictas; si falta una, devuelve 400:

1. "stream": true — el modelo solo admite streaming; stream:false se rechaza.
2. input es un array de objetos de mensaje — con el streaming activado, pasar una cadena simple devuelve input: has incorrect type.

curl

curl -N https://api.hiapi.ai/v1/responses \
  -H "Authorization: Bearer sk-<tu key>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6.1-sol",
    "input": [
      {
        "type": "message",
        "role": "user",
        "content": [
          { "type": "input_text", "text": "Explica en una frase qué es el límite de velocidad de una API." }
        ]
      }
    ],
    "stream": true
  }'

-N desactiva el búfer de salida de curl, así puedes ver los Server-Sent Events (SSE) llegar uno a uno en tiempo real. El flujo es una serie de líneas event: / data:; el texto que buscas aparece en los fragmentos response.output_text.delta y se repite completo en el evento final response.completed.

La forma abreviada "input": [{"role":"user","content":"……"}] también funciona; la forma canónica con type/input_text de arriba es más robusta al combinar multimodalidad o varios turnos, así que se recomienda usarla por defecto.

Python

No necesitas SDK; HiAPI es HTTP normal, basta con requests y stream=True:

import json
import requests

API_KEY = "sk-<tu key>"

payload = {
    "model": "gpt-6.1-sol",
    "input": [
        {
            "type": "message",
            "role": "user",
            "content": [
                {"type": "input_text", "text": "Explica en una frase qué es el límite de velocidad de una API."}
            ],
        }
    ],
    "stream": True,
}

with requests.post(
    "https://api.hiapi.ai/v1/responses",
    headers={
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    },
    json=payload,
    stream=True,
    timeout=120,
) as resp:
    resp.raise_for_status()

    text = ""
    for line in resp.iter_lines(decode_unicode=True):
        if not line or not line.startswith("data:"):
            continue
        event = json.loads(line[len("data:"):].strip())
        etype = event.get("type")
        if etype == "response.output_text.delta":
            text += event["delta"]
        elif etype == "response.completed":
            usage = event["response"]["usage"]
            print(f"\n[tokens: in={usage['input_tokens']} "
                  f"out={usage['output_tokens']} total={usage['total_tokens']}]")

print(text)

Es más robusto despachar según el campo type incluido en el JSON (en lugar de analizar la línea event:): cada trama SSE son dos líneas — event: <type> y data: <json> — basta con filtrar las líneas data: y leer event["type"].

Puntos clave para producción

• Solo existe el modo streaming. No hay variante sin streaming; stream:false devuelve 400 directamente. El cliente debe diseñarse en torno a SSE desde el principio: añadir tiempo de espera de lectura, reconectar / reintentar tras cortes del flujo.
• No envíes max_output_tokens. Este perfil de ejecución no acepta ese parámetro (devuelve not supported by this execution profile). Para controlar la longitud, hazlo desde el prompt o las instrucciones del sistema. El modelo puede generar hasta unos 128 000 tokens por respuesta, pero ese límite no se puede configurar mediante parámetros.
• El prompt del sistema va en el nivel superior, en instructions (cadena), no dentro de un mensaje concreto:

{
  "model": "gpt-6.1-sol",
  "instructions": "Eres un asistente conciso; responde en una sola frase.",
  "input": [
    { "type": "message", "role": "user",
      "content": [{ "type": "input_text", "text": "¿Qué es un webhook?" }] }
  ],
  "reasoning": { "effort": "low" },
  "stream": true
}

• Usa reasoning.effort para equilibrar profundidad de razonamiento y coste. gpt-6.1 Sol es un modelo de razonamiento; reasoning.effort admite cinco niveles: low / medium / high / xhigh / max, con medium por defecto. Cuanto menor el nivel, menos tokens de razonamiento se consumen — y los tokens de razonamiento se factura como salida, apareciendo en usage.output_tokens_details.reasoning_tokens del evento final. No actives niveles altos para tareas que se resuelven con niveles bajos.
• Cuando necesites salida estructurada, usa text.format. El modelo admite el modo estricto de JSON Schema (strict), ideal para que devuelva JSON parseable de forma estable en lugar de confiar en que el prompt acierte el formato.
• Admite llamadas a herramientas (function calling). Los campos tools + tool_choice de nivel superior están disponibles, y se puede devolver el resultado de la herramienta a la conversación para seguir razonando, ideal para escenarios de agentes.
• Conversación multiturno: basta con añadir en orden los mensajes previos de user y assistant al array input y enviar la siguiente solicitud.
• Fallo de autenticación es 401. Una key incorrecta o revocada devuelve 401, código permission_denied ("This API key is invalid."). En ese caso lanza el error directamente y no reintentes — reintentar no arregla una key incorrecta; usa el request_id del cuerpo de la respuesta para que soporte técnico investigue.
• La facturación es por tokens. input y output se tarifan por separado, y el precio unitario de output es notablemente mayor que el de input; los tokens de entrada que aciertan en caché son más baratos; los tokens de razonamiento se cuentan como output y se cobran con él (por eso bajar reasoning.effort ahorra directamente); cuando la entrada de una solicitud supera unos 272 000 tokens se entra en el tramo de precio de contexto largo. Los números concretos dependen de la página de precios en tiempo real; no fijes precios en el código.

Registro de prueba real: una solicitud que funcionó de verdad

Los ejemplos de este artículo no son copiados de la documentación — se llamó realmente a /v1/responses con el curl de arriba (reasoning.effort: low, prompt "Explica en una frase qué es el límite de velocidad de una API") y se observó:

• El usage del evento final response.completed: input_tokens=31, output_tokens=28, total_tokens=59, con output_tokens_details.reasoning_tokens=0 — con nivel bajo y una pregunta sencilla, los tokens de razonamiento pueden ser 0, y el coste es casi solo la parte de salida visible.
• El texto llega en el flujo como incrementos response.output_text.delta, y en el estado final se puede obtener el resultado completo de una vez desde response.output[0].content[0].text; ambas formas sirven.
• El cuerpo de respuesta incluye campos como el eco de reasoning.effort, service_tier y prompt_cache_retention, lo que confirma que effort y la caché se aplican realmente.

También se provocaron de verdad varios errores comunes para que puedas comparar y diagnosticar (todos son respuestas reales):

Qué hiciste mal	HTTP	code	message
Enviar a /v1/chat/completions	400	unsupported_protocol	Model does not support this protocol
Enviar stream:false	400	invalid_parameter	stream: must be true
Enviar max_output_tokens	400	invalid_parameter	max_output_tokens: is not supported by this execution profile
input enviado como cadena	400	invalid_parameter	input: has incorrect type
key inválida	401	permission_denied	This API key is invalid. (con request_id)

Regla mnemotécnica para diagnosticar: si da 400, revisa primero estas tres cosas — si el endpoint es /v1/responses, si stream es true y si input es un array. La gran mayoría de los "no funciona" son una de estas tres.

Enlaces relacionados

• Página del modelo gpt-6.1 Sol — capacidades, parámetros y prueba en línea
• Documentación de HiAPI — visión general de la API y más modelos
• Página de precios — precios unitarios en tiempo real con pago por uso
• ¿Aún eligiendo modelo? Consulta GPT-6 Astra vs GPT-5.6 Sol: cómo elegir, y la página del modelo GPT-6 Astra, que también usa la Responses API

Preguntas frecuentes

¿Se puede conectar directamente con el SDK oficial de OpenAI? gpt-6.1 Sol usa el protocolo de la Responses API, y la forma del endpoint es compatible con él; sin embargo, los ejemplos de este artículo usan el HTTP más ligero (requests + stream=True), sin depender de ningún SDK, y se pueden copiar y ejecutar tal cual. Lo clave es apuntar la base URL a https://api.hiapi.ai y llevar la key de HiAPI.

¿Por qué enviar stream:false siempre da 400? Es por diseño, no es un bug. La familia Sol solo admite streaming; stream debe ser true, de lo contrario devuelve invalid_parameter (stream: must be true). Cambia el cliente para leer SSE.

¿Cómo controlo la longitud de salida? ¿No se puede usar max_output_tokens? No, enviarlo devuelve 400. Especifica el requisito de longitud en instructions (por ejemplo, "responde en una sola frase") o restringe en el prompt.

¿Cómo reducir el coste? Baja primero reasoning.effort (los tokens de razonamiento se facturan como salida, un nivel bajo ahorra directamente); reutiliza el prompt del sistema para que la entrada acierte en caché y sea más barata; evita meter contextos muy largos de una vez y activar el tramo de precio alto. Consulta los precios unitarios en tiempo real en la página de precios.