Hy4-Update für den Client-Code: Was ich beim Model-ID-Wechsel geändert habe

AI-Assisted: Dieser Artikel wurde mit KI-Unterstützung geschrieben; die unten dokumentierten API-Aufrufe stammen aus von mir am 2026-11-05 manuell durchgeführten Tests.

Tencent Hunyuan hat Hy4 am 2026-11-04 als Formalversion freigegeben. Die Preview (hy4-preview) hing seit Ende August 2026 in der Luft. Mich hat nicht die Pressemappe interessiert, sondern eine engere Frage: Wenn ich in meinem OpenAI-kompatiblen Client das model-Feld auf hy4 umstelle — welche Checks im Client-Code muss ich vorher anfassen?

Am 2026-11-05 habe ich das über https://api.crazyrouter.com/v1 mit model: "hy4" durchgespielt. In diesem Gateway-Katalog steht nur hy4, kein hy4-preview. Einen gleichen-Eingangs-A/B gegen Preview kann ich deshalb nicht fahren. Offizielle Deltas markiere ich als offiziell. Alles, was ich als „gesehen“ behaupte, kommt aus den heutigen Formal-Calls.

Hy4 formal vs Hy4 preview: was am Client überhaupt zählt

Zeitlinie kurz: Preview ungefähr 2026-08-27/28, Formal Hy4 am 2026-11-04.

Laut Vendor gegenüber Preview neu: erstmals Vision, erstmals Computer-Use-Claim (CLI/GUI), stärkere Long-Horizon-/Agent-Sprache, gleiche TokenHub-Listenpreisbandbreite. Formal-Gewichte waren beim Schreiben noch nicht öffentlich; Preview-Gewichte waren unter Apache 2.0 offen. IDs: Preview hy4-preview, Formal hy4 (anderswo z. B. tencent/hy4).

Für den Client-Code zählt davon vor allem dreierlei:

1. Content-Empty-Guard — HTTP 200 heißt nicht „Antwort brauchbar“.
2. Vision-Payload — Bild und Text in derselben messages-Struktur.
3. max_tokens-Budgetierung — Reasoning kann das Limit auffressen.

Computer-Use und lange Agent-Loops habe ich nicht getestet. Die lasse ich aus dem Flip-Grund heraus.

Hy4 aufrufen: base_url und model-Feld

Der Flip selbst ist kurz. Base und Model müssen stimmen:

curl https://api.crazyrouter.com/v1/chat/completions \
 -H "Authorization: Bearer $API_KEY" \
 -H "Content-Type: application/json" \
 -d '{
 "model": "hy4",
 "messages": [{"role": "user", "content": "Reply with exactly: ok"}],
 "max_tokens": 256
 }'

Erfolg bewerte ich nicht nur am Statuscode. Ich prüfe choices[0].message.content, usage und bei Bedarf finish_reason. 401, Quota und „Modell nicht freigeschaltet“ behandle ich als eigene Fehlerklassen.

Wer schon OpenAI-kompatible Agenten verdrahtet hat — etwa über den OpenCode-Setup-Leitfaden oder die Hermes-Agent-Konfiguration — ändert in der Praxis meist nur Base, Key und die Model-Zeichenkette. Der restliche Client-Code ist der Teil, der bei Hy4 wirklich knackt.

Hy4 Content-Empty-Guard: HTTP 200 reicht nicht

Der Tag-eins-Risiko beim Hy4-ID-Wechsel ist nicht „Route tot“. Es ist „Route sieht gesund aus, Text ist leer“.

Reasoning kann das gesamte max_tokens-Budget auffressen. Du bekommst trotzdem HTTP 200 und einen nicht-null Output-Zähler. choices[0].message.content ist "", finish_reason oft length. Jeder Client, der nur den Status prüft, markiert das als Erfolg — und schickt leere Antworten weiter.

Was ich am selben Tag gesehen habe

max_tokens	Aufgabe	Ergebnis
128–1024	reasoning-lastige Frage	HTTP 200, Content leer, Reasoning füllt das Cap
2048	dieselbe Familie	Text beginnt zu erscheinen; kann trotzdem length enden
2048 / 8192	langer Coding-Prompt	leerer Content weiterhin möglich
4096	kurze Coding-Nebenwirkungsfrage	rows.sort() In-place-Mutation korrekt markiert + Rewrite
512	Identitäts-Smoke	「我是混元…版本号为Hy4。」 (~9.5 s)
256 × 12	„Nur antworten: 收到“	alle 200, alle「收到」, ~2.6–4.0 s

In meinen Guard baue ich deshalb ein:

• content leer → Fail (nicht Success)
• finish_reason == "length" → Limit anheben oder Prompt kürzen, dann Retry
• usage.completion_tokens groß, aber Content leer → Reasoning-Budget-Verdacht, nicht „Gateway ok“

Das ist kein Beweis, dass Formal Hy4 „stabiler als Preview“ wäre. Ohne gleichen-Eingangs-Preview-Kontrolle schreibe ich kein Ranking.

Hy4 Vision-Payload: multimodale messages

Die Preview war für meine Arbeit textlastig. Formal Hy4 ist laut Vendor die erste Version mit Vision im Vordergrund. Genau das ändert den Client: Bild und Text müssen in derselben OpenAI-kompatiblen Message-Struktur fahren — nicht über eine zweite Vision-Route.

Heute habe ich ein synthetisches Q1-Umsatz-Balkendiagramm (Nord 80 / Ost 160 / Süd 200 / West 120) an hy4 geschickt und nach den vier Zahlen gefragt. In etwa 8,9 s kam der Content als 80 160 200 120. Ein früherer Solo-Lauf lieferte den Peak korrekt als S 200. Klare Labels, saubere Balken — kein unscharfes Handyfoto, kein dichtes Multi-Panel-UI. Also: dieses Chart funktioniert; eure Produktionsscreenshots brauchen euer eigenes Sample-Pack.

Das synthetische Diagramm aus dem Vision-Test.

Für den Client heißt das konkret:

• content als Array mit type: "text" und type: "image_url" (bzw. Base64, je nach Client)
• Timeout und Retry-Policy nicht nur für Text-Pings kalibrieren
• Leeren Content auch bei Vision-Calls als Fail behandeln

Text-zu-Bild-Jobs sind eine andere Aufgabenform und nicht dasselbe wie „Hy4 liest eine bestehende Abbildung“. Computer-Use bleibt bei mir ungetestet; Vendor-Claim ≠ meine Beobachtung.

Hy4 max_tokens-Budgetierung: kurze Pings ≠ lange Prompts

Zwölf kurze Pings, die alle「收到」zurückgeben, beweisen nur: die kurze Schleife lebt heute. Sie beweisen nicht, dass ein langer Agent-Prompt in dein aktuelles max_tokens passt.

Am selben Tag kam ein längerer Coding-Prompt bei 2048 und sogar bei 8192 mit leerem Content zurück, wenn Reasoning das Budget fraß. Ein kürzeres Coding-Briefing bei 4096 funktionierte. Daraus ziehe ich drei Client-Regeln:

1. Pro Prompt-Form budgetieren, nicht global „256 reicht ja beim Ping“.
2. Bei reasoning-lastigen Tasks mit höherem Cap starten oder den Prompt schrumpfen.
3. Canary nicht nur mit Ping-Tabellen freigeben — mit dem Prompt-Shape, den ihr wirklich ausliefert.

Wenn Codex-CLI oder ähnliche Agenten schon an eine Dritt-API hängen, hilft der Codex-CLI-Integrationsleitfaden beim Verdrahten. Die Budget-Logik bleibt trotzdem eure: der Agent darf ein leeres Content-Feld nicht als erfolgreichen Schritt verbuchen.

Coding war bei diesem Hy4-Update ohnehin nicht die Headline. Auf einer kurzen Python-Nebenwirkungsfrage hat Formal Hy4 korrekt erkannt, dass rows.sort() die Caller-Liste mutiert, und ein sorted(...) / max(..., default=None)-Rewrite angeboten. Brauchbar als Scratch-Pad. Kein Beleg für einen Repo-weiten Flip. Große Repository-Umbauten habe ich nicht gefahren.

Hy4 wann ich die ID flippe — und wann nicht

• Flip / Canary, wenn Bilder schon in denselben Wochen-Call gehören wie Text. Das ist die Preview-Lücke, die Formal Hy4 schließt — und das habe ich heute verifiziert. Vorher: Empty-Guard und Vision-Payload im Client.
• Alte ID lassen, wenn nur kurze Prosa und leichte Code-Hilfe reichen. Formal-Release-Zeremonie ist kein Grund, Configs zu drehen.
• Nicht flottenweit tauschen, weil Computer-Use vermarktet wird oder weil „HTTP bleibt 200“. Ersteres habe ich nicht validiert. Letzteres ist am selben Tag am Empty-Body-Test gescheitert.

Listenpreis laut Tencent Cloud TokenHub: CNY 6 / 18 / 0.3 pro 1M Input / Output / Cache — gleiche Bandbreite wie Preview. Abrechnung gegen Response-usage abstimmen.

Minimales Prove-it-Pack vor dem Behalten des Flips: eines eurer echten Bilder durch hy4, plus ein bewusst enges max_tokens-Lauf, das bestätigt, dass der Client bei leerem Content fail-closed geht. Desktop-Steuerung und lange Agents: erst mit eigenem Sandbox-Beweis.