So verwendest du gpt-6-astra über die hiapi API: curl, Python und lauffähige Anfragebeispiele

gpt-6-astra ist ein Textmodell mit Reasoning-Fähigkeiten, das jetzt auf hiapi verfügbar ist und über einen OpenAI-kompatiblen Endpunkt erreichbar ist: /v1/responses. Diese Anleitung enthält ein lauffähiges curl- und Python-Anfragebeispiel, eine nicht offensichtliche Anforderung, bei der man leicht stolpert (Streaming ist Pflicht), sowie die Produktionsmuster, die du vor dem Go-live benötigst.

Was du baust

Ein Skript, das einen Prompt an gpt-6-astra sendet und die Antwort des Modells über eine Streaming-Antwort liest. Kein Polling, keine Task-ID – es ist ein synchroner Chat-Aufruf, der lediglich als Server-Sent Events geliefert wird statt als blockierende JSON-Antwort.

Voraussetzungen: ein hiapi-API-Schlüssel. Hole ihn aus der Konsole – jede Anfrage unten benötigt ihn im Authorization-Header.

Minimales lauffähiges Beispiel

gpt-6-astra unterstützt nur einen Endpunkt – POST /v1/responses – und akzeptiert ausschließlich "stream": true. Unabhängig davon, was sonst noch im Request-Payload steht, führt das Senden von "stream": false zu einem 400-invalid_request-Fehler; das Modell hat auf hiapi keinen Nicht-Streaming-Modus. Konzipiere deinen Client also rund um das Lesen eines Event-Streams und nicht rund um eine einzelne JSON-Antwort.

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 deaktiviert die Ausgabepufferung von curl, sodass du die Events siehst, sobald sie eintreffen, statt alles erst am Ende auf einmal zu erhalten. Der Antworttyp ist text/event-stream, jede data:-Zeile ist ein JSON-Objekt, und eine event:-Zeile gibt ihren Typ an. Ein kompakter Lauf sieht so aus:

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}, ...}}

Der Text, den du eigentlich willst, kommt über wiederholt auftretende response.output_text.delta-Events gestreamt herein – verkette die delta-Felder in der Reihenfolge, um die vollständige Antwort zu erhalten. response.completed enthält den abschließenden usage-Block für die Kostenverfolgung.

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() fängt Fehler auf HTTP-Ebene (Authentifizierung, Rate-Limits) ab, bevor du mit dem Parsen der SSE-Zeilen beginnst – ein fehlerhaft formatierter Stream und eine abgelehnte Anfrage sind zwei unterschiedliche Fehlermodi, die du in deiner Fehlerbehandlung unterscheiden musst.

Zwei Felder im Request-Payload verdienen besondere Erwähnung:

• input ist ein Array von Nachrichtenobjekten, kein flacher String – jeder Eintrag benötigt type: "message", ein role und ein Inhaltsarray aus typisierten Teilen (input_text für reinen Text).
• reasoning.effort (low / medium / high) ist optional, steuert aber, wie viel internes Reasoning das Modell vor der Antwort betreibt. Ohne Angabe wendet hiapi einen Standardwert an; wenn du Latenz gegen Antwortqualität abwägst, setze es explizit.

Hinweise für den Produktivbetrieb

• Streaming ist keine Option.Baue keinen Codepfad, der bei Wiederholungen auf stream: false zurückfällt – für dieses Modell schlägt das jedes Mal fehl. Wenn dein Framework oder SDK eine einzelne JSON-Antwort voraussetzt, kapsle die obige SSE-Schleife ein und puffere den zusammengesetzten Text, bevor du ihn übergibst.
• Authentifizierungsfehler sind eindeutig.Ein ungültiger oder widerrufener Schlüssel liefert HTTP 401 mit "code": "permission_denied" im Fehlertext – prüfe diesen Code, statt auf den Nachrichtenstring zu matchen, denn der String kann sich ändern.
• store: false macht die Anfrage zustandslos.hiapi behält die Antwort nicht serverseitig, daher steht bei Folgeaufrufen kein previous_response_id zum Verketten zur Verfügung. Wenn du Kontext über mehrere Runden brauchst, sende die vorherigen Runden als zusätzliche input-Nachrichten erneut, statt dich auf serverseitigen Gesprächszustand zu verlassen.
• Setze Client-Timeouts unabhängig vom Streaming.SSE-Verbindungen können hängen bleiben, wenn die Verbindung abbricht, ohne dass eine der beiden Seiten ein sauberes Schließen signalisiert; ein timeout am initialen requests.post (wie im obigen Beispiel) verhindert einen Stillstand beim ersten Byte, aber du solltest in deinem eigenen Code zusätzlich eine maximale Stream-Dauer verfolgen, um Defense-in-Depth zu betreiben.
• Verwende prompt_cache_key für wiederkehrenden Systemkontext wieder.Der Response-Payload enthält einen prompt_cache_key; wenn du bei jedem Aufruf dieselben Anweisungen sendest, ermöglicht es das Beibehalten desselben Schlüssels hiapi, Prompt-Caching anzuwenden, statt sie jedes Mal neu zu verarbeiten.

Weiterführende Lektüre

• Modellseite von gpt-6-astra – vollständige Parameterreferenz und Live-Preise
• hiapi API-Dokumentation – Authentifizierung, weitere Modellfamilien und die vollständige Endpunktliste
• hiapi-Preise – Token-Preise für gpt-6-astra und alle anderen Modelle

Häufig gestellte Fragen

Unterstützt gpt-6-astra /v1/chat/completions? Nein. Ein Aufruf über /v1/chat/completions liefert einen 400-unsupported_endpoint-Fehler mit dem Hinweis, stattdessen /v1/responses zu verwenden. Auf hiapi ist es ausschließlich für die Responses API registriert.

Kann ich eine einzelne JSON-Antwort statt eines Streams erhalten? Bei diesem Modell nicht. "stream": false wird direkt abgelehnt (invalid_request), unabhängig davon, ob andere Parameter gesetzt sind. Konzipiere deine Integration rund um das Konsumieren des SSE-Streams und das Zusammensetzen des endgültigen Textes auf dem Client, wie oben gezeigt.

Unterstützt gpt-6-astra Tool-Aufrufe? Das Modell akzeptiert ein tools-Array in der Request-Struktur der Responses API (wenn nicht gesetzt, erscheint es im Response-Objekt als leeres Array). Wenn du Function Calling anbindest, definiere deine Tools wie bei jedem OpenAI-Responses-API-kompatiblen Modell und achte im Stream auf response.output_item.added-Events mit dem Typ function_call.

Wie sehen Rate-Limit- oder Quota-Fehler aus? Wie andere hiapi-Fehler werden sie als JSON zurückgegeben, mit type: "hiapi_error" und einem code-Feld, nach dem du verzweigen kannst, plus einer request_id – gib diese ID beim Kontakt mit dem Support an, damit sie die exakte Anfrage serverseitig nachverfolgen können.

Kann ich dieselbe Request-Struktur bei anderen Reasoning-Modellen auf hiapi verwenden? Die Request-Struktur von /v1/responses wird von den OpenAI-Responses-kompatiblen Modellfamilien auf hiapi gemeinsam genutzt – du musst nur das model-Feld ersetzen, um das Modell zu wechseln. Die Verfügbarkeit variiert je nach Modell, prüfe daher die Seite des jeweiligen Modells, bevor du davon ausgehst, dass es live ist.