HiAPI
Blog

Tutorial

So rufst du gpt-6.1 Sol über HiAPI auf: curl, Python und Streaming im Praxistest (deutsches Tutorial)

Oct 20, 2026
So rufst du gpt-6.1 Sol über HiAPI auf: curl, Python und Streaming im Praxistest (deutsches Tutorial)

Ziel und Voraussetzungen dieses Artikels

Nachdem du diesen Artikel gelesen hast, wirst du gpt-6.1 Sol mit einer einzigen HTTP-Anfrage zum Laufen bringen – das Textmodell der GPT-6.1-Sol-Familie auf HiAPI, das auf komplexe Programmierung, Dokumentenanalyse und mehrstufiges Reasoning spezialisiert ist – und eine gestreamte Antwort erhalten. Du bekommst direkt kopierbare curl- und Python-Beispiele sowie die drei häufigsten Stolperfallen: Die Schnittstelle ist /v1/responses (nicht /v1/chat/completions), Streaming muss aktiviert sein und input muss ein Array sein.

Voraussetzung: Ein HiAPI-API-Key. Erstelle ihn auf der API-Schlüssel-Seite und bewahre ihn sicher auf; bei jeder Anfrage wird er über Authorization: Bearer sk-<dein key> gesendet.

gpt-6.1 Sol ist ein reines Textmodell (Chat / Reasoning / Programmierung) und erzeugt keine Bilder. Fähigkeiten und Online-Test findest du auf der gpt-6.1-Sol-Modellseite.

Minimales lauffähiges Beispiel

Die Sol-Familie nutzt die Responses API: POST /v1/responses. Zwei harte Regeln – fehlt eine, gibt es 400:

  1. "stream": true – das Modell unterstützt nur Streaming, stream:false wird abgelehnt.
  2. input ist ein Array von Nachrichtenobjekten – bei aktiviertem Streaming führt ein einfacher String zu input: has incorrect type.

curl

curl -N https://api.hiapi.ai/v1/responses \
  -H "Authorization: Bearer sk-<dein key>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6.1-sol",
    "input": [
      {
        "type": "message",
        "role": "user",
        "content": [
          { "type": "input_text", "text": "Erkläre in einem Satz, was eine API-Ratenbegrenzung ist." }
        ]
      }
    ],
    "stream": true
  }'

-N schaltet die Ausgabepufferung von curl ab, sodass du die Server-Sent Events (SSE) in Echtzeit einzeln zurückkommen siehst. Der Stream besteht aus einer Reihe von event:- / data:-Zeilen; der gewünschte Text erscheint in den response.output_text.delta-Fragmenten und wird im finalen response.completed-Event vollständig wiederholt.

Die Kurzform "input": [{"role":"user","content":"……"}] funktioniert ebenfalls; die obige kanonische Schreibweise mit type/input_text ist beim Kombinieren von Multimodalität oder mehreren Runden stabiler und wird als Standard empfohlen.

Python

Kein SDK nötig – HiAPI ist normales HTTP, mit requests und stream=True reicht es:

import json
import requests

API_KEY = "sk-<dein key>"

payload = {
    "model": "gpt-6.1-sol",
    "input": [
        {
            "type": "message",
            "role": "user",
            "content": [
                {"type": "input_text", "text": "Erkläre in einem Satz, was eine API-Ratenbegrenzung ist."}
            ],
        }
    ],
    "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 ist stabiler, nach dem im JSON enthaltenen type-Feld zu verteilen (statt die event:-Zeile zu parsen): Jeder SSE-Frame besteht aus zwei Zeilen – event: <type> und data: <json> – es genügt, nur die data:-Zeilen zu filtern und event["type"] zu lesen.

Hinweise für den Produktiveinsatz

  • Nur ein Modus: Streaming. Es gibt keine Nicht-Streaming-Variante, stream:false liefert direkt 400. Der Client muss von Anfang an um SSE herum konzipiert sein: Lese-Timeout setzen, nach Verbindungsabbruch neu verbinden / erneut versuchen.
  • max_output_tokens nicht übergeben. Dieses Ausführungsprofil akzeptiert diesen Parameter nicht (Fehler not supported by this execution profile). Um die Länge zu steuern, beschränke sie im Prompt oder in den Systemanweisungen. Das Modell kann pro Aufruf maximal etwa 128.000 Token ausgeben, aber diese Obergrenze lässt sich nicht per Parameter setzen.
  • System-Prompt in das Top-Level-Feld instructions (String) legen, nicht in eine Message packen:
{
  "model": "gpt-6.1-sol",
  "instructions": "Du bist ein knapper Assistent, antworte nur mit einem Satz.",
  "input": [
    { "type": "message", "role": "user",
      "content": [{ "type": "input_text", "text": "Was ist ein Webhook?" }] }
  ],
  "reasoning": { "effort": "low" },
  "stream": true
}
  • Mit reasoning.effort Reasoning-Tiefe und Kosten ausbalancieren. gpt-6.1 Sol ist ein Reasoning-Modell; reasoning.effort unterstützt fünf Stufen low / medium / high / xhigh / max, Standard ist medium. Je niedriger die Stufe, desto weniger Reasoning-Token werden verbraucht – und Reasoning-Token werden als Output abgerechnet und erscheinen im finalen Event unter usage.output_tokens_details.reasoning_tokens. Aufgaben, die mit einer niedrigen Stufe lösbar sind, sollte man nicht mit einer hohen Stufe lösen.
  • Für strukturierte Ausgaben text.format verwenden. Das Modell unterstützt den Strict-Modus von JSON Schema, ideal, um stabil parsebares JSON zu erhalten, statt per Prompt auf das Format zu hoffen.
  • Tool-Aufrufe (Function Calling) werden unterstützt. Top-Level tools + tool_choice sind verfügbar, und Tool-Ergebnisse können zur weiteren Reasoning in die Konversation zurückgeführt werden – geeignet für Agent-Szenarien.
  • Mehrrundige Konversation: Die bisherigen User- und Assistant-Nachrichten in Reihenfolge an das input-Array anhängen und die nächste Anfrage senden.
  • Fehlgeschlagene Authentifizierung ist 401. Bei falschem oder widerrufenem Key kommt 401, code permission_denied ("This API key is invalid."). Dann direkt einen Fehler werfen, nicht wiederholen – Wiederholen repariert keinen falschen Key. Die request_id aus dem Antworttext dient dem Support zur Fehlersuche.
  • Abrechnung erfolgt nach Token. Input und Output werden getrennt berechnet, der Output-Preis ist deutlich höher als der Input-Preis; bei Cache-Treffern sind Input-Token günstiger; Reasoning-Token zählen als Output und kosten mit (deshalb spart das Senken von reasoning.effort direkt Geld); bei einer Eingabe von mehr als etwa 272.000 Token greift eine höhere Langkontext-Preisstufe. Die konkreten Zahlen gelten in Echtzeit laut Preisseite – Preise nicht im Code hartkodieren.

Praxistest: eine real durchgelaufene Anfrage

Die Beispiele in diesem Artikel sind nicht aus der Dokumentation abgeschrieben – mit dem obigen curl wurde /v1/responses tatsächlich einmal aufgerufen (reasoning.effort: low, Prompt war "Erkläre in einem Satz, was eine API-Ratenbegrenzung ist"), beobachtet wurde:

  • usage im finalen response.completed-Event: input_tokens=31, output_tokens=28, total_tokens=59, davon output_tokens_details.reasoning_tokens=0 – bei niedriger Stufe + einfacher Frage können die Reasoning-Token 0 sein, die Kosten beschränken sich praktisch auf den sichtbaren Output.
  • Der Text kommt im Stream als response.output_text.delta-Inkremente an; im finalen Zustand lässt sich das vollständige Ergebnis auf einmal über response.output[0].content[0].text abrufen; beide Varianten funktionieren.
  • Der Antworttext enthält Felder wie reasoning.effort-Echo, service_tier, prompt_cache_retention usw., was bestätigt, dass Effort und Cache tatsächlich wirksam sind.

Auch einige häufige Fehler wurden real ausgelöst, damit du sie zur Fehlersuche vergleichen kannst (alles echte Antworten):

Was du falsch gemacht hast HTTP code message
An /v1/chat/completions gesendet 400 unsupported_protocol Model does not support this protocol
stream:false übergeben 400 invalid_parameter stream: must be true
max_output_tokens übergeben 400 invalid_parameter max_output_tokens: is not supported by this execution profile
input als String übergeben 400 invalid_parameter input: has incorrect type
Key ungültig 401 permission_denied This API key is invalid. (mit request_id)

Merkregel zur Fehlersuche in einem Satz: Bei 400 zuerst diese drei Dinge prüfen – ist die Schnittstelle /v1/responses, ist stream true, ist input ein Array. Die allermeisten "geht nicht"-Fälle sind eine dieser drei Bedingungen.

Relevante Links

Häufige Fragen

Kann ich das offizielle OpenAI-SDK direkt anbinden? gpt-6.1 Sol nutzt das Protokoll der Responses API, die Schnittstellenform ist damit kompatibel, aber die Beispiele in diesem Artikel verwenden das leichteste reine HTTP (requests + stream=True), ohne Abhängigkeit von einem SDK – einfach kopieren und es läuft. Entscheidend ist, dass die base URL auf https://api.hiapi.ai zeigt und der HiAPI-Key mitgesendet wird.

Warum bekomme ich bei stream:false ständig 400? Das ist so gewollt, kein Bug. Die Sol-Familie unterstützt nur Streaming, stream muss true sein, sonst kommt invalid_parameter (stream: must be true). Stelle den Client auf SSE-Lesen um.

Wie steuere ich die Ausgabelänge? Geht das nicht mit max_output_tokens? Nein, wird es übergeben, gibt es 400. Gib die Längenanforderung in instructions an (z. B. "Antworte nur mit einem Satz") oder beschränke sie im Prompt.

Wie senke ich die Kosten? Vorrangig reasoning.effort senken (Reasoning-Token werden als Output abgerechnet, niedrige Stufe spart direkt); den System-Prompt wiederverwenden, damit der Input den Cache trifft und günstiger wird; vermeiden, einen überlangen Kontext auf einmal hineinzugeben und damit die höhere Preisstufe auszulösen. Echtzeit-Einzelpreise siehe Preisseite.

Ähnliche Artikel

Alle Artikel ansehen →

Starte mit persistenten KI-Artefakten

Hol dir deinen API-Key und rufe Bild-, Video- und Audiomodelle über eine einzige task-basierte API auf.

API-Dokumentation lesen