Comment utiliser gpt-6-astra via l'API hiapi : exemples de requêtes curl, Python et exécutables

gpt-6-astra est un modèle textuel doté de capacités de raisonnement, désormais disponible sur hiapi, accessible via un point de terminaison compatible OpenAI : /v1/responses. Ce guide fournit un exemple de requête curl et Python exécutable, une exigence non évidente qui piège facilement (l'utilisation obligatoire du streaming), ainsi que les bonnes pratiques de production nécessaires avant la mise en ligne.

Ce que vous allez construire

Un script qui envoie un prompt à gpt-6-astra et lit la réponse du modèle via un flux en streaming. Pas de polling, pas d'ID de tâche ici — il s'agit d'un appel de chat synchrone, simplement livré sous forme de Server-Sent Events plutôt qu'une réponse JSON bloquante.

Prérequis : une clé API hiapi. Récupérez-la depuis la console — chaque requête ci-dessous doit la transmettre dans l'en-tête Authorization.

Exemple minimal exécutable

gpt-6-astra ne prend en charge qu'un seul point de terminaison — POST /v1/responses — et n'accepte que "stream": true. Quel que soit le reste du payload, envoyer "stream": false renvoie une erreur 400 invalid_request ; ce modèle n'a pas de mode non-streaming sur hiapi. Concevez votre client pour lire un flux d'événements, et non pour attendre une réponse JSON unique.

curl

curl -N -X POST "https://api.hiapi.ai/v1/responses" \
  -H "Authorization: Bearer sk-your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-astra",
    "input": [
      {
        "type": "message",
        "role": "user",
        "content": [
          { "type": "input_text", "text": "Explain one practical way to check an AI-generated answer against its source." }
        ]
      }
    ],
    "stream": true,
    "store": false,
    "reasoning": { "effort": "medium" }
  }'

-N désactive la mise en tampon de sortie de curl, ce qui vous permet de voir les événements dès leur arrivée au lieu de tout recevoir d'un coup à la fin. La réponse est de type text/event-stream, chaque ligne data: est un objet JSON, et une ligne event: en indique le type. Une exécution réduite ressemble à ceci :

event: response.created
data: {"type":"response.created","response":{"id":"resp_...","status":"in_progress", ...}}

event: response.output_text.delta
data: {"type":"response.output_text.delta","delta":"OK", ...}

event: response.completed
data: {"type":"response.completed","response":{"status":"completed","usage":{"input_tokens":12,"output_tokens":5,"total_tokens":17}, ...}}

Le texte qui vous intéresse réellement arrive en streaming via les événements répétés response.output_text.delta — concaténez les champs delta dans l'ordre pour obtenir la réponse complète. response.completed porte le bloc final usage, utile pour le suivi des coûts.

Python

import json
import requests

payload = {
    "model": "gpt-6-astra",
    "input": [
        {
            "type": "message",
            "role": "user",
            "content": [
                {
                    "type": "input_text",
                    "text": "Explain one practical way to check an AI-generated answer against its source.",
                },
            ],
        },
    ],
    "stream": True,
    "store": False,
    "reasoning": {"effort": "medium"},
}

with requests.post(
    "https://api.hiapi.ai/v1/responses",
    headers={
        "Authorization": "Bearer sk-your-api-key",
        "Content-Type": "application/json",
    },
    json=payload,
    stream=True,
    timeout=60,
) as resp:
    resp.raise_for_status()
    answer = []
    for line in resp.iter_lines():
        if not line or not line.startswith(b"data: "):
            continue
        event = json.loads(line[len(b"data: "):])
        if event.get("type") == "response.output_text.delta":
            answer.append(event["delta"])
        elif event.get("type") == "response.completed":
            usage = event["response"]["usage"]
            print(f"\n\ntokens: {usage['input_tokens']} in / {usage['output_tokens']} out")

    print("".join(answer))

resp.raise_for_status() intercepte les échecs au niveau HTTP (authentification, limitation de débit) avant que vous ne commenciez à analyser les lignes SSE — un flux mal formé et une requête rejetée sont deux modes d'échec distincts que vous devez distinguer dans votre gestion des erreurs.

Deux champs du payload méritent une attention particulière :

• input est un tableau d'objets message, et non une chaîne à plat — chaque entrée nécessite type: "message", un role, et un tableau de contenu composé de parties typées (input_text pour le texte brut).
• reasoning.effort (low / medium / high) est facultatif, mais il contrôle la quantité de raisonnement interne que le modèle effectue avant de répondre. Si vous ne le définissez pas, hiapi applique une valeur par défaut ; si vous devez arbitrer entre latence et qualité de réponse, définissez-le explicitement.

Considérations de production

• Le streaming n'est pas facultatif. Ne construisez pas de chemin de code qui se rabat sur stream: false lors d'une nouvelle tentative — pour ce modèle, cela échouera systématiquement. Si votre framework ou SDK suppose une réponse JSON unique, encapsulez la boucle SSE ci-dessus et mettez le texte concaténé en tampon avant de le transmettre.
• Les échecs d'authentification sont explicites. Une clé invalide ou révoquée renvoie un HTTP 401 avec "code": "permission_denied" dans le corps de l'erreur — vérifiez ce code plutôt que de faire du pattern matching sur la chaîne du message, car celle-ci peut changer.
• store: false rend la requête sans état. hiapi ne conserve pas la réponse côté serveur, donc lors d'appels ultérieurs, aucun previous_response_id n'est disponible pour le chaînage. Si vous avez besoin d'un contexte multi-tours, renvoyez les tours précédents comme messages input supplémentaires plutôt que de compter sur un état de conversation côté serveur.
• Définissez des délais d'expiration côté client, avec ou sans streaming. Une connexion SSE peut rester suspendue en cas de déconnexion du réseau sans que l'une des parties n'envoie de signal de fermeture propre ; définir un timeout sur le requests.post initial (comme dans l'exemple ci-dessus) évite le blocage sur le premier octet, mais vous devez aussi suivre une durée maximale de flux dans votre propre code pour une défense en profondeur.
• Réutilisez prompt_cache_key pour un contexte système répété. Le payload de réponse contient un prompt_cache_key ; si vous envoyez les mêmes instructions à chaque appel, garder les requêtes sur la même clé permet à hiapi d'appliquer le cache de prompts au lieu de les retraiter à chaque fois.

Lectures associées

• Page du modèle gpt-6-astra — référence complète des paramètres et tarification en temps réel
• Documentation de l'API hiapi — authentification, autres familles de modèles et liste complète des points de terminaison
• Tarification hiapi — tarifs par token pour gpt-6-astra et tous les autres modèles

Questions fréquentes

gpt-6-astra prend-il en charge /v1/chat/completions ? Non. L'appeler via /v1/chat/completions renvoie une erreur 400 unsupported_endpoint vous invitant à utiliser /v1/responses. Sur hiapi, il n'est enregistré que pour l'API Responses.

Puis-je obtenir une réponse JSON unique au lieu d'un flux ? Pour ce modèle, non. "stream": false est directement rejeté (invalid_request), quel que soit le réglage des autres paramètres. Construisez votre intégration autour de la consommation du flux SSE et de l'assemblage du texte final côté client, comme montré ci-dessus.

gpt-6-astra prend-il en charge l'appel d'outils ? Le modèle accepte un tableau tools dans la structure de requête de l'API Responses (affiché comme un tableau vide dans l'objet de réponse lorsqu'il n'est pas défini). Si vous intégrez des appels de fonctions, définissez vos outils comme pour tout modèle compatible avec l'API OpenAI Responses, et surveillez dans le flux les événements response.output_item.added de type function_call.

À quoi ressemblent les erreurs de limitation de débit ou de quota ? Comme les autres erreurs hiapi, elles sont renvoyées en JSON, avec type: "hiapi_error" et un champ code sur lequel vous pouvez brancher votre logique, plus un request_id — incluez cet ID lorsque vous contactez le support afin qu'il puisse retrouver la requête exacte côté serveur.

Puis-je utiliser la même structure de requête avec d'autres modèles de raisonnement sur hiapi ? La structure de requête /v1/responses est partagée parmi les familles de modèles hiapi compatibles avec OpenAI Responses — il suffit de remplacer le champ model pour changer de modèle. La disponibilité varie selon le modèle, donc consultez la page propre à chaque modèle avant de supposer qu'il est en ligne.