DEV Community: boluo

GLM-5 gegen Gemini 3.8 Flash: was 19 gemeinsame Aufgaben offenlegen

boluo — Thu, 22 Oct 2026 13:24:42 +0000

Das Titelbild wurde mit KI erstellt.

Das Problem

Zwei Modelle, dieselben 19 Aufgaben. Das Ergebnis lautet 19/19 und 17/19.

Die Zahl stimmt, und sie ist das Erste, was auffällt. Sie sagt aber nur, wie viele Aufgaben danebengingen, nicht wie. Die beiden Aufgaben, die Gemini 3.8 Flash verfehlt hat, kamen beide mit HTTP 200 zurück und lösten keinen einzigen Fehler aus. Ein Dashboard, das nur Fehlerraten beobachtet, zeigt an dieser Stelle nichts an.

Die Umgebung

Die 19 Aufgaben verteilen sich auf sechs Bereiche: defekten Code reparieren, von Grund auf implementieren, Werkzeuge aufrufen, Fragen zu einem Repository beantworten, ein Ausgabeformat einhalten, einen Wert in einer langen Datei finden.

Beide Modelle liefen über denselben Endpunkt mit denselben Anfrageparametern. Pro Aufgabe und Modell ein Durchlauf, insgesamt 38 Aufrufe, alle protokolliert.

	GLM-5	Gemini 3.8 Flash
Bestanden	19/19	17/19
Turns pro Aufgabe, Mittel	2,9	3,3
Eingabe-Token	55.258	27.713
Ausgabe-Token	11.049	13.034
Reasoning-Token	6.444	9.105
Laufzeit	444,5 s	510,3 s
Kosten zu Listenpreisen	$0,0906	$0,0697

Ein Durchlauf pro Modell und Aufgabe. Diese Werte beschreiben diese Aufgabenliste, nicht die Modelle allgemein.

Beide Fehlschläge liegen in den zwei einzigen Aufgaben, die eine mehrere hundert Zeilen lange Datei lesen müssen.

Die Schritte

Aufgabe 1: Der Turn-Deckel hat den Aufruf beendet

Die erste Aufgabe verlangte einen Deploy-Schlüssel, der in einem 402 Zeilen langen Protokoll vergraben lag, bei einem Deckel von sechs Turns.

GLM-5 fand ihn im vierten Turn und beendete normal. Gemini 3.8 Flash verbrauchte alle sechs Turns und rief noch Werkzeuge auf, als der Deckel erreicht war. Als stop_reason wurde tool_calls protokolliert, der finale Text war leer.

Abbildung: die beiden Aufgaben mit Stoppgrund und Ausgabe. Die zweite Ausgabe steht im Original.

Das ist keine falsche Antwort. Das ist keine Antwort. Von außen sieht es aus wie eine Aufgabe, die das Modell nicht konnte. Tatsächlich ging ihm mitten in der Arbeit der Platz aus.

Der Punkt, an dem ich hängen geblieben bin: HTTP 200 heißt die Anfrage wurde nicht abgelehnt, nicht das Modell ist fertig. Das sind zwei verschiedene Dinge, und stop_reason ist das einzige Feld, das sie trennt.

Die Konsequenz ändert sich dadurch. Eine falsche Antwort verlangt ein anderes Modell. Eine abgeschnittene Antwort verlangt einen höheren Deckel oder eine aufrufende Schicht, die den Zustand erkennt und erneut versucht.

Aufgabe 2: Der Wert stimmt, das Format nicht

Die zweite Aufgabe verlangte den Wert einer Konstante aus einem 883 Zeilen langen Modul, und zwar ausschließlich die Zahl.

Beide Modelle brauchten zwei Turns. GLM-5 gab 17 zurück. Gemini 3.8 Flash gab RETRY_BUDGET 常量值为 17 zurück — den richtigen Wert, eingebettet in einen Satz.

Die Zahl ist korrekt, das Format nicht. Code, der diese Antwort als Ganzzahl parst, scheitert daran. Ein Mensch, der sie liest, wird sie mit hoher Wahrscheinlichkeit als bestanden markieren. Genau diese Art Fehlschlag verdeckt eine Erfolgsquote vollständig.

Eine Einschränkung gehört dazu. Die Aufgabenstellung war auf Chinesisch formuliert, der Arbeitssprache der Testumgebung, und die Antwort kam ebenfalls auf Chinesisch zurück. Ob dasselbe Modell unter einer deutschen oder englischen Anweisung ebenfalls einen Satz bildet, beantwortet dieser Durchlauf nicht. Prüfen Sie es in der Sprache, die Sie tatsächlich senden.

Verifikation und Fehlersuche

Beide Fehlschläge teilen eine Eigenschaft: keiner löste einen Fehler aus, und beide standen in Feldern, die die aufrufende Seite ohnehin empfängt. Der Aufwand besteht aus drei Änderungen, nicht aus weiteren Durchläufen.

Den Stoppgrund zusammen mit dem Ergebnis lesen. Er ist das billigste Signal, das eine abgeschlossene von einer abgeschnittenen Antwort trennt, und in einem Dashboard, das auf Fehlerraten schaut, taucht er nie auf.

Erst die Form prüfen, dann den Inhalt. Wenn nachgelagerter Code die Ausgabe parst, ist die Ausgabe ein Vertrag. Eine gescheiterte Prüfung gehört als Fehlschlag gezählt und nicht als Formatierungsproblem durchgewinkt.

Das eigene Verhältnis von Eingabe zu Ausgabe messen, bevor Preise verglichen werden. In diesem Durchlauf war Gemini 3.8 Flash auf die Gesamtsumme bezogen 23,1 % günstiger. Die beiden Modelle haben aber unterschiedlich viel Eingabe verbraucht. Auf eine gleiche Nutzungsmenge normalisiert stehen $0,0694 gegen $0,0697 — 0,4 % Unterschied, also ein Gleichstand.

Die Listenpreise trennen die beiden deutlicher als die Rechnung. GLM-5 liegt bei $1,00 pro Million Eingabe-Token und $3,20 pro Million Ausgabe-Token, mit Cache-Eingabe bei $0,20 und ohne Batch-Stufe. Gemini 3.8 Flash liegt bei $0,75 und $3,75, mit Cache-Eingabe bei $0,075 und einer Batch-Stufe von $0,375 und $1,88 für asynchrone Aufträge. Zwei dieser Unterschiede wiegen schwerer als der Grundtarif: Cache-Eingabe ist bei Gemini 3.8 Flash um den Faktor 2,7 günstiger und dürfte bei jeder Last mit langem, wiederkehrendem Präfix den Vergleich bestimmen. Die Batch-Stufe hilft nur, wenn die Arbeit warten kann — dann aber stärker als alles, was die Tokenpreise nahelegen.

Abbildung: die gemessenen Tokenmengen zu Listenpreisen.

Turnzahl und Eingabemenge gehören ebenfalls getrennt betrachtet. GLM-5 brauchte weniger Turns (55 gegen 63), verbrauchte aber fast die doppelte Eingabemenge. Pro Turn sind das rund 1.005 gegen rund 440 Token. Wer den Deckel aus dem Mittelwert ableitet, schneidet bei dem Modell, das pro Turn mehr mitführt, ausgerechnet die leseintensivsten Aufgaben ab — genau das ist in Aufgabe 1 passiert.

Ein weiterer Posten: Reasoning-Token werden zum Ausgabetarif abgerechnet, und Gemini 3.8 Flash hat den höheren Ausgabetarif. In diesem Durchlauf standen 6.444 gegen 9.105 Token, ein Unterschied von 41 %. Ein einzelner Durchlauf reicht allerdings nicht, um daraus ein festes Verhältnis zu machen.

Zum Austausch

Der Unterschied zwischen den beiden Modellen lag nicht im Ergebnis, sondern in der Art des Scheiterns. 17 der 19 Aufgaben haben beide bestanden. Die zwei abweichenden sind aus verschiedenen Gründen abgewichen: einmal der Turn-Deckel, einmal das Ausgabeformat.

Die Stichprobe umfasst 19 Aufgaben. Eine einzelne Aufgabe verschiebt die Quote um mehr als fünf Prozentpunkte. Lesen Sie diese Ergebnisse deshalb als Richtung für eigene Tests, nicht als zitierfähiges Resultat. Auch die Kontextleistung lässt sich hier nicht beurteilen: Das längste Dokument hatte rund 14.000 Token, die veröffentlichten Grenzen liegen bei 200.000 und 1.000.000. Ein Fenster tatsächlich zu füllen ist ein anderer Test. Gemessen wurde ausschließlich Texteingabe.

Wenn Sie die beiden Modelle für eine konkrete Aufgabe vergleichen wollen, hilft ein Blick auf die Modellseite von Gemini 3.8 Flash beim Eingrenzen, bevor Sie den eigenen Test aufsetzen. Die Preise sind Listenpreise mit Stand 22. Oktober 2026 und enthalten keine Cache- oder Batch-Rabatte.

Gelangen wichtige Informationen nach außen, wenn ich KI benutze? Was das Dokument selbst schon mitbringt

boluo — Thu, 22 Oct 2026 10:13:44 +0000

Ein Blick in die versteckten Bestandteile einer Bürodatei

Eigene Darstellung. Das Bild zeigt keine Messergebnisse eines bestimmten Dienstes.

Wer eine Datei in ein KI-Werkzeug zieht, will meist etwas über den Inhalt wissen. Die zweite Frage kommt später: Was ist von der Datei selbst noch mitgegangen? Eine Bürodatei ist kein Blatt Papier, sondern ein Archiv, und darin liegen Teile, die im Fenster nicht auftauchen.

Die Frage, ob wichtige Informationen nach außen gelangen, hat zwei Hälften. Die erste betrifft das Modell: Es ist zustandslos, es merkt sich die Datei nicht, und der eingesandte Text verändert keine Parameter. Die zweite Hälfte betrifft alles davor. Und dort entscheidet sich der größere Teil, weil ein Dokument schon vor dem Absenden Dinge mitbringt, die niemand eingetippt hat. Der geprüfte Ausschnitt ist deshalb bewusst klein: nur die Datei, noch vor jeder Anfrage.

Umgebung und Vorgehen

Bestandteil	Festlegung
Prüfobjekt	eine Word-Datei und eine Excel-Mappe, für diesen Test erzeugt
Sichtbarer Inhalt	Angebotsnummer, Kundenname, Ansprechpartner, Telefonnummer, Betrag
Zusätzliche Bestandteile	ein Kommentar, eine nachverfolgte Änderung, Autorenangaben, ein ausgeblendetes Blatt
Werkzeug zum Erzeugen	Python 3 mit `python-docx` und `openpyxl`
Werkzeug zum Lesen	`zipfile` aus der Standardbibliothek
Ort der Prüfung	lokal, vor jeder Anfrage
Datum	22. Oktober 2026

Die Testdateien sind absichtlich unauffällig. Im geöffneten Fenster zeigen sie einen Absatz mit einer Angebotsnummer und einen Betrag. Alles Weitere wird erst sichtbar, wenn man die Datei als Archiv öffnet.

Schritt 1: Die Datei als Archiv lesen

Sowohl .docx als auch .xlsx sind ZIP-Archive mit einer festgelegten Ordnerstruktur. zipfile listet die Teile auf, ohne dass ein Büroprogramm beteiligt ist:

import zipfile

with zipfile.ZipFile("beispiel-angebot.docx") as z:
    for name in z.namelist():
        print(name)

Die Testdatei besteht aus 18 Teilen. Die meisten sind unauffällig: Formatvorlagen, Schriftdefinitionen, Beziehungsdateien. Interessant sind vier Einträge, nämlich docProps/core.xml, word/comments.xml, word/document.xml und, in der Excel-Mappe, xl/workbook.xml.

Schritt 2: Die vier Bestandteile einzeln prüfen

Autorenangaben. docProps/core.xml enthält unter anderem dc:creator und cp:lastModifiedBy. Das sind keine technischen Kennungen, sondern Namen. In der Testdatei steht M. Keller als Ersteller und S. Brandt als letzte Bearbeitung.

Kommentare. Liegt word/comments.xml im Archiv, hängen Kommentare an der Datei. Sie stehen nicht im Fließtext und werden beim Kopieren des sichtbaren Absatzes nicht mitgenommen, beim Hochladen der Datei aber sehr wohl. Im Test lautet der Kommentar: „Betrag bitte gegen die Kalkulation prüfen, alter Wert war 138000 EUR."

Änderungsverlauf. Bei eingeschalteter Nachverfolgung steht in word/document.xml neben dem sichtbaren Text eine <w:ins>- und eine <w:del>-Auszeichnung. Entscheidend ist der Inhalt der Löschung: Sie wird als <w:delText> gespeichert und trägt den alten Wert weiter, obwohl er im Fenster nicht mehr zu sehen ist. In der Testdatei ist das die Zahl 138000 EUR, also dieselbe Zahl, die auch im Kommentar steht.

Blattzustände. In der Excel-Mappe steht in xl/workbook.xml zu jedem Blatt ein Zustand. Zwei Blätter der Testdatei sind ausgeblendet: Intern mit dem Zustand hidden und Kalkulation mit dem Zustand veryHidden. Das erste lässt sich über das Einblenden-Menü zurückholen, das zweite trägt den Zustand, der dort nicht auftaucht. Im Blatt Intern stehen Kundenname, Ansprechpartner und Telefonnummer.

Eigene Darstellung der vier Bestandteile. Das Bild zeigt keine Messergebnisse eines bestimmten Dienstes.

Verifikation: was das Auslesen ergeben hat

Das folgende Protokoll stammt aus einem Lauf gegen die beiden Testdateien:

Datei: beispiel-angebot.docx  (18 Teile im Archiv)
  docProps/core.xml      Ersteller: M. Keller
  docProps/core.xml      zuletzt geändert von: S. Brandt
  word/comments.xml      1 Kommentar(e), Autor: S. Brandt | Text: Betrag bitte gegen die Kalkulation prüfen, alter Wert war 13
  word/document.xml      2 überarbeitete Stellen (1 Einfügung, 1 Löschung, gelöscht: 138000 EUR)
Datei: beispiel-liste.xlsx  (14 Teile im Archiv)
  xl/workbook.xml        "Angebot" sichtbar | "Intern" verborgen | "Kalkulation" sehr verborgen
  xl/comments1.xml       1 Zellnotiz

Drei Beobachtungen daraus:

Der gelöschte Betrag 138000 EUR steht weiterhin in der Datei. Wer im Fenster nachsieht, findet ihn nicht.
Die Namen der Bearbeitenden sind Teil der Datei, obwohl sie niemand in den Text geschrieben hat.
Das ausgeblendete Blatt Intern enthält genau die Angaben, die bei einer Weitergabe niemand mitsenden wollte.

Eigene Darstellung des Vergleichs. Das Bild zeigt keine Messergebnisse eines bestimmten Dienstes.

Fehlersuche: vier Muster, die sich wiederholen

Nur den sichtbaren Text prüfen. Der Absatz im Fenster ist sauber. Das Archiv ist es nicht.

Änderungen weder annehmen noch verwerfen. Nachverfolgte Änderungen verschwinden nicht dadurch, dass man die Nachverfolgung ausschaltet. Erst das Annehmen oder Verwerfen entfernt Löschungen aus dem XML.

Den Kommentar übersehen, obwohl er den alten Wert trägt. Im Test steht die Zahl, die aus dem Text entfernt wurde, im Kommentar daneben.

Ausgeblendete Blätter für gelöscht halten. hidden und veryHidden sind Zustände, keine Löschung. Die Daten liegen weiter im Archiv.

Was ich nicht geprüft habe

Das Protokoll zeigt, was in den Dateien steht. Es zeigt nicht, was ein bestimmter Dienst davon liest, wie lange er es speichert und ob er es zum Verbessern von Modellen verwendet. Das sind drei getrennte Fragen, und für die letzten beiden ist dieses Protokoll kein Beleg.

Ungeprüft ist auch der Weg über einen PDF-Export. Ob dort ebenfalls Autorenangaben stehen bleiben, habe ich nicht gemessen und behaupte es deshalb nicht.

Und das Protokoll sagt nichts über das Modell selbst. Dass es sich die Datei nicht merkt, folgt daraus, wie es arbeitet, nicht aus diesem Lauf.

Was vor dem Senden hilft

Die Prüfung lässt sich in einen Satz fassen: Was im Fenster steht, ist nicht alles, was die Datei enthält. Wer mehrere Werkzeuge im Einsatz hat, findet die Einstellungen zu Reichweite und Endpunkt bei jedem Werkzeug an anderer Stelle; ein Beispiel für eine solche Einrichtung ist die Codex-CLI-Anleitung. Für den Aufruf selbst lässt sich ein einheitlicher Endpunkt setzen. Ich nutze dafür Crazyrouter, weil sich damit das Modell wechseln lässt, ohne die aufrufende Stelle anzufassen.

Wichtig bleibt der zweite Teil des Satzes: Ein Gateway liegt auf derselben Strecke und liest denselben Text. Crazyrouter steht dabei auf demselben Weg wie jede andere Zwischenstation. Es ändert die Bedingungen, unter denen Kopien entstehen, nicht die Tatsache, dass sie entstehen.

Austausch

Wer schon einmal eine Datei verschickt und erst danach gemerkt hat, dass ein Kommentar oder ein ausgeblendetes Blatt mitgegangen ist: An welcher Stelle prüft ihr das inzwischen?

Quellenstand: 22. Oktober 2026. Die Testdateien wurden an diesem Tag erzeugt und ausgelesen; das Protokoll oben ist die Ausgabe dieses Laufs. Speicherfristen und Trainingsbedingungen unterscheiden sich je Anbieter und sind dort zu prüfen, wo die Anfrage tatsächlich landet.

Claude Sonnet 5.5: Wofür es sich eignet und woran man die Kosten erkennt

boluo — Thu, 22 Oct 2026 08:26:05 +0000

Ein Modell antwortet in der halben Zeit, und die Rechnung für dieselbe Aufgabe wird trotzdem höher. Das ist kein Widerspruch, sondern eine Folge davon, wie Token abgerechnet werden: Der Preis pro Token ist nur die eine Hälfte, die andere Hälfte ist die Länge der Ausgabe. Claude Sonnet 5.5 ist am 28. September 2026 erschienen und ändert am Listenpreis nichts — die Kosten pro Aufgabe können sich trotzdem in beide Richtungen bewegen. Drei Aufgaben zeigen, woran das liegt und welche Einstellungen beim Aufruf dazugehören.

Was offiziell feststeht

Anthropic nennt für Sonnet 5.5 drei Angaben: über 30 Prozent schneller, bis zu 30 Prozent geringere Kosten pro Aufgabe, und einen unveränderten Preis von 2 US-Dollar pro Million Eingabe-Token und 10 US-Dollar pro Million Ausgabe-Token. Das Lesen aus dem Cache sinkt von 0,20 auf 0,10 US-Dollar pro Million Token, der Batch-Preis liegt bei 1 und 5 US-Dollar. In den Claude-Anwendungen ist „Medium" die Standardstufe für den Rechenaufwand.

Zwei Einschränkungen gehören dazu. Erstens bleibt Opus 5.5 nach Angaben des Anbieters bei komplexen, offen formulierten Aufgaben deutlich stärker. Zweitens ist claude-sonnet-5-5 ein eigenes Modell und keine Versionsnummer von claude-sonnet-5. Wer die Zeichenkette in der Konfiguration ändert, vollzieht eine Migration und kein Update.

Der Aufbau der Messung

Drei Aufgaben wurden je einmal über einen OpenAI-kompatiblen Endpunkt aufgerufen: dasselbe Modell, derselbe Aufgabentyp, keine Vorgabe einer Aufwandsstufe. Aufgezeichnet wurden die ausgegebenen Token, die Länge der Antwort, die Dauer und die daraus berechneten Kosten. Das Kontextfenster liegt bei einer Million Token, die Eingabe kann Text und Bilder enthalten.

Für die Einordnung ist wichtig, was hier nicht gemessen wurde: Es gab keine Wiederholung, keinen Vergleich unter kontrollierten Bedingungen und keine Bewertung der Antwortqualität. Die drei Zeilen sind ein Hinweis darauf, wo man im eigenen Projekt nachsehen sollte — keine belastbare Kennzahl.

Drei Aufgaben, drei Ergebnisse

Die erste Aufgabe war eng gefasst: aus sechs Zeilen eines Fehlerprotokolls ein JSON mit festem Schema. Sonnet 5.5 gab 410 Token aus, Sonnet 5 im gleichen Aufbau 682. Die Antworten waren mit 805 und 793 Zeichen nahezu gleich lang. Die Ersparnis entstand also nicht durch Weglassen, sondern durch früheres Aufhören.

Die zweite Aufgabe verlangte eine Markdown-Tabelle aus fünf Betriebsnotizen. Hier standen 628 Token gegen 911. Auch hier war das Ergebnis vollständig, nur der Weg dorthin kürzer.

Die dritte Aufgabe kippte das Bild. Es ging um das Umschreiben einer Zahlungs-Retry-Routine, und im Prompt stand „nichts weglassen". Sonnet 5.5 gab 5.753 Token aus, Sonnet 5 nur 4.012 — rund 43 Prozent mehr. Die Antwort war mit 6.924 Zeichen auch sichtbar länger, die Rechnung stieg von 0,0405 auf 0,0579 US-Dollar.

Woran das Modell erkennt, dass es fertig ist

Der Unterschied zwischen den drei Fällen liegt nicht in der Qualität, sondern in der Abbruchbedingung. Bei der JSON-Aufgabe gibt es ein eindeutiges Ende: die schließende Klammer. Das Modell kann aufhören, sobald die Struktur steht, und die erste Antwort war entsprechend kurz.

Bei der Tabelle gibt es ebenfalls ein sichtbares Ziel — die letzte Zeile. Auch dort endet die Ausgabe früh.

Bei der Code-Aufgabe gibt es kein solches Signal. „Nichts weglassen" lässt sich nicht überprüfen, und ein Modell, das eine Anweisung wörtlich nimmt, produziert mehr Text statt weniger. Genau dort entsteht die längere Ausgabe, und mit ihr die höhere Rechnung.

Praktisch heißt das: Die Kosten pro Aufgabe hängen davon ab, ob die Aufgabe eine prüfbare Abbruchbedingung hat. Aufgaben mit festem Ziel werden kürzer beantwortet, offene Aufgaben nicht zwangsläufig.

Beim Aufruf festlegen, was festlegbar ist

Weil die Ausgabelänge den Ausschlag gibt, sollte der Aufruf sie begrenzen, statt sich auf eine Voreinstellung zu verlassen. Ein Aufruf über den OpenAI-kompatiblen Pfad sieht so aus:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["API_KEY"],
    base_url=os.environ["API_BASE_URL"],
)

antwort = client.chat.completions.create(
    model="claude-sonnet-5-5",          # eigenes Modell, nicht claude-sonnet-5
    max_tokens=2000,                     # Obergrenze für die Ausgabe
    temperature=0,
    messages=[{"role": "user", "content": aufgabe}],
)

print(antwort.usage.completion_tokens)   # die Zahl, die die Rechnung bestimmt

Drei Punkte gehören in jede Umstellung. Erstens die Modellkennung: claude-sonnet-5-5, claude-sonnet-5 und claude-sonnet-4-6 sind drei getrennte Modelle. Zweitens eine eigene Obergrenze für die Ausgabe, damit eine offene Formulierung die Rechnung nicht nach oben zieht. Drittens die Stufe für den Rechenaufwand, sofern sie im eigenen Aufruf gesetzt wird — offizielle Dokumentation nennt „Medium" nur als Vorgabe der Anwendungen; ob und wie sich die Stufe auf der API-Seite abschalten lässt, geht daraus nicht hervor.

Modellkennung, Kontextlänge und der aktuelle Preis pro Million Token lassen sich vor der Umstellung auf der Crazyrouter-Modellseite zu Claude Sonnet 5.5 abgleichen. Bei einem Anbieter mit Gruppenrabatt weichen die effektiven Sätze vom Listenpreis ab; maßgeblich bleibt die eigene Abrechnung.

Offizielle Werte und ihre Grenzen

Die vom Anbieter veröffentlichten Werte zeigen das erwartete Bild: Sonnet 5.5 liegt in der Nähe von Opus 5.5 und deutlich über Sonnet 5. Beim Terminal-Bench 4.0 stehen 70,6 Prozent gegen 10,3 Prozent, beim FrontierCode 1.1 (Main) 46,2 gegen 54,4 Prozent, beim GDPval-AA v2.1 1844 gegen 1846 Punkte. Diese Zahlen sind Herstellerangaben und wurden hier nicht unabhängig reproduziert.

Bemerkenswerter als die Spitzenwerte ist der Spalt zwischen Sonnet 5.5 und Opus 5.5 im lang laufenden Coding — dort bleibt der Unterschied bestehen. Für die Auswahl heißt das: Wo eine Aufgabe eine klare Abbruchbedingung hat, ist Sonnet 5.5 die günstigere Wahl. Wo eine Aufgabe offen formuliert ist und über längere Strecken korrekt bleiben muss, bleibt Opus 5.5 die sicherere Wahl.

Wann der Wechsel trägt

Ein Wechsel lohnt sich, wenn die eigenen Aufgaben eine prüfbare Abbruchbedingung haben — strukturierte Ausgabe, feste Felder, klar umrissene Umformungen. Dort sinken Ausgabelänge und Dauer, ohne dass die Antwort dünner wird.

Ein Wechsel trägt nicht, wenn die Aufgabe offen formuliert ist und die Vollständigkeit der Antwort im Vordergrund steht. Dort kann die neue Version mehr Text produzieren als die alte, und die Rechnung folgt der Ausgabe.

Wer umstellt, sollte zuerst die eigene Aufgabe messen, nicht den Preis pro Token. Die Zahl, die zählt, steht in usage.completion_tokens.

Quellen: Ankündigung und Modellseite zu Claude Sonnet 5.5 (Anthropic, veröffentlicht am 28. September 2026), geprüft am 22. Oktober 2026. Token-, Kosten-, Zeit- und Zeichenangaben stammen aus je einem Aufruf pro Aufgabe am 22. Oktober 2026 über einen OpenAI-kompatiblen Endpunkt. Vier Angaben ließen sich aus der öffentlichen Dokumentation nicht bestätigen und werden hier nicht als Tatsache verwendet: die Obergrenze der Ausgabe-Token, das Datum des Wissensstands, die Frage, ob sich erweitertes Denken abschalten lässt, und die Standardstufe für den Rechenaufwand auf der API-Seite.

Vier Modelle, ein Endpunkt: erst messen, dann vergleichen

boluo — Wed, 21 Oct 2026 09:34:09 +0000

Vier Modelle, ein Endpunkt: erst messen, dann vergleichen

Was ich protokolliere, bevor ich überhaupt über Modellwahl rede — und warum die Reihenfolge den Unterschied macht.

Ein Monat lang habe ich dieselben Aufgaben abwechselnd an vier Modelle gegeben: DeepSeek V4-Pro, Qwen3.8 Max, GLM-5 und Gemini 3.8 Flash. Alle vier hängen an demselben OpenAI-kompatiblen Endpunkt, der Wechsel ist ein String.

Am Anfang wollte ich eine Rangliste. Am Ende hatte ich eine Liste von Messgrößen — und die war deutlich nützlicher. Dieser Text beschreibt die Messgrößen, nicht die Rangliste.

Das Problem

Wenn man Modelle nach Gefühl vergleicht, passiert Folgendes: Man merkt sich den einen Fall, der hängen geblieben ist, und hält ihn für ein Muster.

Bei mir war das ein Modell, das „langsam" wirkte. Nach zwei Wochen mit Protokoll stellte sich heraus, dass es pro Antwort nicht langsamer war — es brauchte nur mehr Runden pro Aufgabe. Und jede Runde schickt den bisherigen Gesprächsverlauf erneut mit. Die gefühlte Langsamkeit war in Wahrheit eine Multiplikation.

Ohne Protokoll hätte ich weiter das falsche Modell beschuldigt.

Die Umgebung

Punkt	Wert
Modelle	DeepSeek V4-Pro, Qwen3.8 Max, GLM-5, Gemini 3.8 Flash
Zugriff	Ein OpenAI-kompatibler Endpunkt, Modellwechsel über den Namen
Zeitraum	Oktober 2026
Preise	Öffentliche, nutzungsbasierte Preise pro 1 Mio. Token

Die Preise sind der einzige Teil, der sauber vergleichbar ist, weil ihn alle Anbieter veröffentlichen.

DeepSeek V4-Pro: $0.67 Eingabe / $2.00 Ausgabe
GLM-5: $1.00 / $3.20
Gemini 3.8 Flash: $0.75 / $3.75
Qwen3.8 Max: $2.00 / $6.00

Die Ausgabe kostet bei allen vier Modellen das Drei- bis Vierfache der Eingabe. Wer Token zu einer Summe addiert, versteckt genau den Anteil, der die Rechnung bestimmt.

Zwei Dinge fallen auf. Erstens: die Ausgabe ist drei- bis viermal so teuer wie die Eingabe — bei jedem der vier. Zweitens: der teuerste Ausgabepreis liegt beim Dreifachen des günstigsten. Das klingt viel, ist aber weniger, als die eigene Rundenzahl bewegen kann.

Bei wiederholten Fragen zum selben langen Dokument entscheidet der Cache-Treffer mehr als die Modellwahl.

Gecachte Eingabe liegt bei Gemini 3.8 Flash bei $0.075, also einem Zehntel. Bei Qwen3.8 Max kostet das Cache-Lesen $0.25. Wer dasselbe lange Dokument mehrfach befragt, für den ist die Cache-Trefferquote wichtiger als die Wahl zwischen diesen vier. Die aktuellen Sätze stehen in der Preisübersicht.

Die Schritte

Schritt 1: vier Felder protokollieren. Mehr braucht es nicht, um die meisten Fehlurteile zu vermeiden:

Anzahl der Runden pro Aufgabe
tatsächliche Zeichenzahl der sichtbaren Antwort
Finish-Grund
Anzahl der Reasoning-Token

Diese vier Spalten haben alles ergeben, was in diesem Text steht.

Schritt 2: die Einheit festlegen. Nicht „eine Antwort", sondern „eine abgeschlossene Aufgabe". Sonst vergleicht man Antworten, die unterschiedlich viel Arbeit enthalten.

Schritt 3: dieselbe echte Aufgabe mehrfach laufen lassen. Nicht eine Aufgabe, sondern mehrere Durchläufe. Eine einzelne Aufgabe liefert das Glück dieser einen Aufgabe.

Schritt 4: Geld pro abgeschlossener Aufgabe vergleichen. Nicht Token, nicht Tokenpreis.

Schritt 5: den Leerfall getrennt zählen. Eine Antwort mit Erfolgsstatus und Länge null gehört in eine eigene Zählung. In der allgemeinen Fehlerquote verschwindet sie zwischen echten Fehlern und echten Erfolgen — und genau dort ist sie unsichtbar.

Das klingt nach fünf Schritten, ist aber eine Stunde Arbeit. Der Aufwand liegt nicht im Messen, sondern darin, sich vorher zu einigen, was „abgeschlossen" bedeutet.

Die Verifikation

Was dabei herauskam, in der Reihenfolge, in der es mich überrascht hat.

Die Rundenzahl multipliziert. Ein Modell brauchte im Schnitt 4,1 Runden pro Aufgabe, ein anderes 2,9. Bei ähnlicher Pro-Antwort-Zeit ergibt das fast den Faktor 1,8 — und die Gesamtzeit wuchs um den Faktor 2,49. Die Runden sind der Hebel, nicht die Latenz einer Antwort.

Die Kostenlücke war kleiner als gedacht. Aus einer einzelnen Aufgabe hatte ich einmal „zehnmal teurer" abgeleitet. Über einen echten Stapel gemessen blieb ein Unterschied von 21 Prozent. Eine einzelne Messung ergibt keinen Multiplikator.

Ein stiller Ausfall. Eine Aufgabe verlangte, eine Zeile in einem 400-Zeilen-Log zu finden. Ein Modell lief sechs Runden, verbrauchte 42.766 Eingabe-Token und gab einen leeren String zurück. Die API meldete normalen Abschluss. Kein Fehler, keine Ausnahme, kein Retry, kein Alarm — nur die Rechnung.

Eine falsche Antwort erzeugt ein Ereignis, das jemand liest. Ein leerer Erfolg erzeugt eine Rechnung. Deshalb gehört „Erfolg mit Antwortlänge null" in eine eigene Alarmkategorie und nicht in die Fehlerquote, wo er weggemittelt wird.

Die Fehlersuche

Der Parser, der still kaputtgeht. Mein erster Filter nahm den Text zwischen schließendem und öffnendem Marker. Das liest sich richtig und versagt leise: Bei einer Antwort, die einen Block öffnet und nie schließt, behandelt der Parser die gesamte Antwort als Fließtext. Begründung und Antwort verschmelzen — schlechter als gar kein Filter.

Meiner tat das monatelang und schrieb irgendwann einen kompletten Begründungsblock in eine Datenbankspalte, die eine Antwort hätte enthalten sollen. Gefunden habe ich es durch Zufall.

Die Regel daraus: Ein nicht terminierter Marker muss einen lauten Fehler auslösen, niemals einen Fallback.

Der Fehler, der wie ein Ergebnis aussieht. Eine leere Antwort mit Erfolgsstatus sieht in jedem Dashboard wie eine schnelle, günstige Anfrage aus. Sie ist weder schnell noch günstig; sie hat nur nichts geliefert.

Die Diskussion

Was ich heute mache: erst prüfen, ob der eigene Code die Ausgabe überhaupt lesen kann, dann die Rundenzahl auf der eigenen Aufgabe messen, dann den Fehlerfall ansehen — und erst danach über Fähigkeiten reden.

Der wichtigste Effekt war übrigens nicht die Zahl, sondern die Reihenfolge. Solange ich mit einer Rangliste angefangen habe, habe ich jede Abweichung als Eigenschaft des Modells gelesen. Mit Protokoll wurde daraus eine Frage an meinen eigenen Aufruf: Warum sechs Runden statt zwei? Warum kein Abbruch bei leerer Antwort? Diese Fragen waren beantwortbar. „Welches Modell ist besser" war es nicht.

Was dieser Text nicht ist: eine Rangliste.

Von den vier Modellen lief nur eines in einem wiederholten, kontrollierten Durchlauf auf meiner Seite. Der Fall mit den sechs Runden und der leeren Antwort stammt aus diesem Lauf und ist eine echte Beobachtung. Alles andere ist, was mir im Alltag mit allen vier aufgefallen ist — schwächere Evidenz, und ich benenne sie als solche.

Die vier Protokollfelder übertragen sich unabhängig vom Modell. Sie sind billiger als jede Vergleichsstudie und liefern genau die Zahlen, die eine Modellentscheidung tatsächlich braucht. Die Frage, die vorher zu beantworten ist, lautet nicht „welches Modell ist besser", sondern „was messe ich eigentlich".

Vier Modelle, ein Endpunkt: erst messen, dann vergleichen

boluo — Wed, 21 Oct 2026 08:40:46 +0000

Was ich protokolliere, bevor ich überhaupt über Modellwahl rede — und warum die Reihenfolge den Unterschied macht.

Am Anfang wollte ich eine Rangliste. Am Ende hatte ich eine Liste von Messgrößen — und die war deutlich nützlicher. Dieser Text beschreibt die Messgrößen, nicht die Rangliste.

Das Problem

Wenn man Modelle nach Gefühl vergleicht, passiert Folgendes: Man merkt sich den einen Fall, der hängen geblieben ist, und hält ihn für ein Muster.

Ohne Protokoll hätte ich weiter das falsche Modell beschuldigt.

Die Umgebung

Punkt	Wert
Modelle	DeepSeek V4-Pro, Qwen3.8 Max, GLM-5, Gemini 3.8 Flash
Zugriff	Ein OpenAI-kompatibler Endpunkt, Modellwechsel über den Namen
Zeitraum	Oktober 2026
Preise	Öffentliche, nutzungsbasierte Preise pro 1 Mio. Token

Die Preise sind der einzige Teil, der sauber vergleichbar ist, weil ihn alle Anbieter veröffentlichen.

DeepSeek V4-Pro: $0.67 Eingabe / $2.00 Ausgabe
GLM-5: $1.00 / $3.20
Gemini 3.8 Flash: $0.75 / $3.75
Qwen3.8 Max: $2.00 / $6.00

Die Ausgabe kostet bei allen vier Modellen das Drei- bis Vierfache der Eingabe. Wer Token zu einer Summe addiert, versteckt genau den Anteil, der die Rechnung bestimmt.

Bei wiederholten Fragen zum selben langen Dokument entscheidet der Cache-Treffer mehr als die Modellwahl.

Die Schritte

Schritt 1: vier Felder protokollieren. Mehr braucht es nicht, um die meisten Fehlurteile zu vermeiden:

Anzahl der Runden pro Aufgabe
tatsächliche Zeichenzahl der sichtbaren Antwort
Finish-Grund
Anzahl der Reasoning-Token

Diese vier Spalten haben alles ergeben, was in diesem Text steht.

Schritt 2: die Einheit festlegen. Nicht „eine Antwort", sondern „eine abgeschlossene Aufgabe". Sonst vergleicht man Antworten, die unterschiedlich viel Arbeit enthalten.

Schritt 3: dieselbe echte Aufgabe mehrfach laufen lassen. Nicht eine Aufgabe, sondern mehrere Durchläufe. Eine einzelne Aufgabe liefert das Glück dieser einen Aufgabe.

Schritt 4: Geld pro abgeschlossener Aufgabe vergleichen. Nicht Token, nicht Tokenpreis.

Das klingt nach fünf Schritten, ist aber eine Stunde Arbeit. Der Aufwand liegt nicht im Messen, sondern darin, sich vorher zu einigen, was „abgeschlossen" bedeutet.

Die Verifikation

Was dabei herauskam, in der Reihenfolge, in der es mich überrascht hat.

Die Fehlersuche

Meiner tat das monatelang und schrieb irgendwann einen kompletten Begründungsblock in eine Datenbankspalte, die eine Antwort hätte enthalten sollen. Gefunden habe ich es durch Zufall.

Die Regel daraus: Ein nicht terminierter Marker muss einen lauten Fehler auslösen, niemals einen Fallback.

Die Diskussion

Was dieser Text nicht ist: eine Rangliste.

KI-Desktop-Apps: 16 offizielle Download-Seiten geprüft

boluo — Wed, 21 Oct 2026 06:52:42 +0000

Wer nach „KI-App für den PC herunterladen" sucht, landet selten auf der Seite des Herstellers. Die ersten Treffer sind meist Sammlungen, die den Installer mit einer Browser-Erweiterung bündeln. In einigen Fällen ist es nicht das gesuchte Produkt, in anderen überhaupt kein Produkt.

Deshalb habe ich die offiziellen Download-Seiten direkt geöffnet: 13 chinesische Anbieter plus Claude und Codex von Anthropic und OpenAI. 16 Einträge, ein Nachmittag. Das Ergebnis ist eine Liste – und ein Hinweis darauf, wann ein einzelner API-Endpunkt sinnvoller ist als eine weitere Installation.

Umgebung

Punkt	Wert
Betriebssystem	Windows 11 (macOS nur anhand der Herstellerangaben)
Node.js	v24.21.0
Claude Code	2.1.306 (npm)
Codex CLI	0.163.0 (npm)
Prüfdatum	21. Oktober 2026
Methode	jede offizielle Download-Seite direkt geöffnet, Angaben notiert

Das Problem

Jeder Hersteller macht den ersten Schritt leicht. Doubao zeigt einen einzelnen Knopf „Download Doubao Desktop". Wenxin stellt die Schaltflächen für macOS und Windows nebeneinander in den ersten Bildschirm. DeepSeek liefert direkte Binaries.

Der zweite Schritt – die Arbeit auf ein anderes Modell zu verlagern – hat keinen Knopf. Die Modellwahl steckt im Client. Wer eine andere Antwort will, installiert eine andere Anwendung und akzeptiert einen anderen Verlauf, eine andere Dateigrenze und eine andere Abrechnung.

Das heißt nicht, dass die Clients schlecht sind. Sie sind dafür gebaut, benutzt zu werden. Die Reibung entsteht erst, wenn man das Modell wechseln will und nicht die Oberfläche.

Schritt 1: die offiziellen Seiten

„Ja" bedeutet: auf der offiziellen Seite steht ein Download-Einstieg oder eine Angabe zum Betriebssystem. „Unbestätigt" bedeutet: am Prüftag stand dort nichts Lesbares – nicht, dass das Produkt nicht existiert.

Produkt	Anbieter	Form	Windows	macOS	Einstieg
Doubao	ByteDance	Chat	Ja	Ja	doubao.com/download
Qwen	Alibaba	Chat	Ja	Ja	qianwen.com/download
Wenxin (Wenxiaoyan)	Baidu	Chat, Dokumente	Ja	Ja	wenxiaoyan.com/pc
Tencent Yuanbao	Tencent	Chat	Ja	Unbestätigt	yuanbao.tencent.com/download
Quark	Alibaba	Browser	Ja	Ja	quark.cn
DeepSeek Harness	DeepSeek	Coding-Agent	Ja	Ja (Apple Silicon, macOS 13+)	deepseek.com/download
Kimi Code	Moonshot AI	Coding-Agent (Desktop + CLI + IDE)	Ja	Ja	kimi.com/code
MiniMax Code	MiniMax	Coding- und Office-Agent	Ja	Ja	agent.minimax.cn/download
StepFun	StepFun	Desktop-Assistent	Ja	Ja	stepfun.com/download
Tencent ima	Tencent	Wissensdatenbank	Ja	Unbestätigt	ima.qq.com
WPS AI	Kingsoft	in der Office-Suite	mit WPS	Unbestätigt	ai.wps.cn
Tiangong	Kunlun	Skywork Desktop	Ja	Unbestätigt	tiangong.cn
ChatGLM	Zhipu	Chat	Unbestätigt	Unbestätigt	chatglm.cn
Claude Desktop	Anthropic	Chat mit Datei- und Desktop-Funktionen	Ja	Ja	claude.com/download
Claude Code	Anthropic	Terminal-Tool	plattformübergreifend	plattformübergreifend	npm: @anthropic-ai/claude-code
Codex CLI	OpenAI	Terminal-Tool	plattformübergreifend	plattformübergreifend	npm: @openai/codex

Von den 13 chinesischen Produkten nennen 8 beide Systeme, 4 nur Windows, 1 keines von beiden.

Schritt 2: die beiden Terminal-Tools

Claude Code und Codex CLI sind keine Desktop-Anwendungen, sondern npm-Pakete. Node.js zuerst installieren, dann:

npm install -g @anthropic-ai/claude-code   # 2.1.306
npm install -g @openai/codex               # 0.163.0

Danach im Projektordner claude oder codex starten. Es gibt keine GUI; die Ausgabe besteht aus Datei-Diffs und Kommandoergebnissen.

Schritt 3: Modellliste über einen Endpunkt

Wenn das Modell ein Konfigurationswert sein soll statt einer Installationsentscheidung, reicht ein OpenAI-kompatibler Endpunkt.

curl https://api.crazyrouter.com/v1/models \
  -H "Authorization: Bearer $CRAZYROUTER_API_KEY"

Die Antwort enthielt 169 Modelle unter einer Basis-URL. Anschließend habe ich genau drei davon mit demselben Prompt aufgerufen:

Modell	HTTP	Antwortzeit	finish_reason
deepseek-v4.1-flash	200	1942 ms	stop
gemini-3.1-flash-lite	200	2534 ms	stop
glm-5.3-flash	200	5978 ms	stop

Die übrigen 166 Modelle wurden nicht aufgerufen, die Bild-, Video- und Audio-Endpunkte nicht getestet. Eine lange Liste belegt die Abdeckung, nicht die Funktion jedes Eintrags.

Verifikation

16 Einträge auf den offiziellen Seiten gefunden, keine Sammlung, kein Mirror
8 Produkte mit beiden Systemen, 4 mit Windows, 1 ohne Angabe
3 von 169 Modellen tatsächlich aufgerufen, alle HTTP 200
Versionen aus der npm-Registry, nicht aus der Erinnerung
Preise: nicht geprüft, daher kein Preisvergleich

Typische Fehler

DeepSeek sind zwei Produkte. Auf der Seite „DeepSeek クライアント" stehen nur iOS und Android. Die Desktop-Variante heißt Harness. Eine Suchanfrage unterscheidet das nicht.

WPS AI hat keinen eigenen Installer. Die Funktionen liegen in WPS Office; erst WPS installieren.

„Unbestätigt" ist keine Absage. Bei Zhipu war der Seitentext an zwei Versuchen nicht lesbar. Deshalb steht dort „unbestätigt" und nicht „nein".

Gleicher Anbieter, anderes Produkt. Tencent Yuanbao ist ein Chat-Client, Tencent ima eine Wissensdatenbank über eigene Dateien.

Eine Messung ist keine Stabilitätsaussage. Beim Abruf der Modellliste antwortete der China-Endpunkt in 337 ms, der internationale in 526 ms. Das ist eine einzelne Beobachtung; Latenz beim Auflisten sagt nichts über die Generierung.

Was hier fehlt

Kein Preisvergleich: Preise wurden nicht geprüft, eine Kostenaussage wäre erfunden. Keine Rangliste nach Bedienkomfort: dafür müsste man jede Anwendung wochenlang benutzen und nicht einen Nachmittag lang Download-Seiten lesen. Und keine Aussage über die Qualität der Modelle, weil dieselbe Frage mit anderem Prompt zu einem anderen Ergebnis führt. Was bleibt, ist der Teil, der heute überprüfbar ist: sechzehn offizielle Einstiege, die jeweils genannten Systeme und die Versionsnummern aus der npm-Registry.

Zusammenfassung

Für Chat und Dokumente reicht ein Client. Für Arbeit im lokalen Projekt sind die Terminal-Tools zuständig. Wenn das Modell selbst die Variable ist, wird der Endpunkt zur Konfiguration statt zur Installation – dafür ist ein Gateway wie Crazyrouter gedacht. Wer vorher sehen will, was abgedeckt ist, kann Cursor-Anbindung und AI-Coding-Modelle ohne Konto öffnen.

Alle Einträge, Systemangaben und Versionen wurden am 21. Oktober 2026 geprüft. Herstellerseiten ändern sich; vor der Installation erneut nachsehen. Der Entwurf entstand mit KI-Unterstützung, die genannten Fakten wurden jedoch wie beschrieben direkt überprüft.

Gemini 2.5 Flash-Lite für die Lokalisierung einer App einordnen

boluo — Tue, 20 Oct 2026 14:35:26 +0000

Gemini 2.5 Flash-Lite für die Lokalisierung einer App einordnen

Ein Hinweis in einer App kann sprachlich korrekt sein und trotzdem das Falsche versprechen. Aus einer Möglichkeit wird eine Zusage. Eine Einschränkung verschwindet. Oder der Text klingt natürlich, passt aber nicht mehr auf den Bildschirm.

Wenn ich Gemini 2.5 Flash-Lite für eine mehrsprachige App einordne, interessiert mich deshalb die Arbeit zwischen Ausgangstext und Veröffentlichung. Wo hilft ein Textentwurf? Was muss die Redaktion entscheiden? Und welche Informationen darf eine neue Sprachfassung keinesfalls verändern?

Meine Überlegungen beruhen auf der dokumentierten Modellfunktion. Eine eigene Untersuchung seiner Übersetzungsqualität in verschiedenen Sprachen liegt diesem Artikel nicht zugrunde. Ich beschreibe eine mögliche Aufgabenverteilung für Produktteams, die ihre Texte vor der Freigabe prüfen können.

Welche Rolle das Modell übernehmen könnte

Gemini 2.5 Flash-Lite ist ein Google-Modell mit Schwerpunkt auf Kosteneffizienz. Über eine API, also eine Schnittstelle für andere Programme, lässt es sich in eine Anwendung einbinden. Das Modell ist dabei eine Komponente. Die Oberfläche, die Auswahl der Texte und die Freigabe müssen aus der umgebenden Anwendung kommen.

Als Kandidaten sehe ich kurze Hilfetexte, Produktbeschreibungen und Hinweise zu bekannten Funktionen. Das Modell könnte vorhandene Aussagen umformulieren, kürzen oder einen Entwurf für eine weitere Sprache vorschlagen. Ob diese Entwürfe für die benötigte Sprache gut genug sind, bleibt eine offene Qualitätsfrage.

Die offizielle Modellbeschreibung nennt Text, Bilder, Audio, Video und PDF als Eingaben. Die Ausgabe ist Text. Für die Lokalisierung würde ich zunächst mit einem freigegebenen Ausgangstext arbeiten. Ein Bildschirmbild kann zusätzlichen Kontext liefern, ersetzt aber keine eindeutige Beschreibung der Funktion.

Der Kontext gehört vor den Entwurf

Unter Lokalisierung verstehe ich mehr als das Austauschen einzelner Wörter. Ein Text muss für die Menschen passen, die ihn in einer bestimmten Situation lesen. Eine Fehlermeldung braucht andere Formulierungen als die Beschreibung einer neuen Funktion.

Ich würde deshalb vorab festhalten, wo der Text erscheint und welche Handlung er erklärt. Dazu gehören die Zielsprache, die gewünschte Anrede und der Ton. Auch die Information, ob sich der Hinweis an neue oder erfahrene Nutzer richtet, kann die Formulierung beeinflussen.

Ein kleines, verbindliches Begriffsverzeichnis wäre für mich Teil dieser Vorbereitung. Darin steht etwa, wie eine Funktion in der jeweiligen Sprache heißt. Die Vorgabe hilft, verschiedene Bezeichnungen für dieselbe Funktion zu vermeiden. Dass das Modell sie zuverlässig einhält, würde ich daraus allerdings noch nicht ableiten.

Eigene Darstellung eines möglichen Arbeitsablaufs; keine gemessene Übersetzungsleistung.

Für wiederkehrende Hinweise würde ich bereits freigegebene Übersetzungen weiterverwenden. Ein neuer Entwurf ist vor allem dann interessant, wenn neuer Inhalt entsteht oder eine Formulierung überarbeitet werden muss. Sonst schafft die ständige Neugenerierung zusätzliche Varianten, die jemand vergleichen und pflegen muss.

Welche Informationen unverändert bleiben müssen

Die wichtigste Grenze verläuft für mich zwischen sprachlicher Anpassung und sachlicher Änderung. Satzbau und Anrede dürfen zur Zielsprache passen. Funktionsumfang, Preise, Fristen und Bedingungen müssen zur freigegebenen Quelle passen.

Besonders aufmerksam wäre ich bei Aussagen über Verfügbarkeit und Verbindlichkeit. Ein möglicher Liefertermin darf in der Sprachfassung nicht wie eine Garantie klingen. Eine optionale Funktion darf nicht als fester Bestandteil jedes Angebots erscheinen. Das sind Prüfaufgaben für die Redaktion, keine beobachteten Fehler dieses Modells.

Solche Unterschiede lassen sich nicht allein daran erkennen, ob ein Text flüssig klingt. Ich würde den Entwurf direkt neben den Ausgangstext legen und sachliche Aussagen einzeln abgleichen. Fehlt dort eine Information, sollte die Sprachfassung sie nicht ergänzen, um vollständiger zu wirken.

Eigene Darstellung der redaktionellen Trennung zwischen Inhalt und Formulierung.

Für rechtlich verbindliche Bedingungen würde ich einen eigenen Freigabeweg vorsehen. Wer diese Verantwortung trägt, muss den Inhalt beurteilen können. Eine günstige Textausgabe liefert dafür keine zusätzliche fachliche Absicherung.

Die Sprachprüfung braucht auch den Bildschirm

Eine sprachkundige Person sollte prüfen, ob die Formulierung die Bedeutung erhält und in der Zielsprache natürlich wirkt. Ich würde ihr den Verwendungszweck mitgeben. Ohne diesen Kontext kann selbst eine sorgfältige Korrektur den Ton der Anwendung verfehlen.

Danach würde ich die Fassung an der vorgesehenen Stelle ansehen. Zeilenumbrüche, verfügbare Breite und die Nähe zu anderen Bedienelementen beeinflussen die Verständlichkeit. Die Lesbarkeit in einem Dokument sagt wenig darüber aus, ob ein Hinweis in einer schmalen mobilen Ansicht funktioniert.

Wenn der Text gekürzt werden muss, würde ich benennen, welche Aussage erhalten bleiben soll. Eine bloße Aufforderung zu mehr Kürze kann genau die Bedingung verdrängen, die der Nutzer kennen muss. Die endgültige Fassung gehört anschließend wieder in dieselbe redaktionelle Prüfung.

Mit Produktänderungen muss die Sprachfassung mitziehen

Eine veröffentlichte Sprachfassung sollte einer bestimmten Version des Ausgangstextes zugeordnet bleiben. Ändert sich das Produktversprechen, müssen die betroffenen Übersetzungen erneut geprüft werden. Das ist eine Aufgabe der Textverwaltung rund um das Modell.

Ich würde kenntlich machen, ob ein Text neu, redaktionell freigegeben oder durch eine Änderung überholt ist. Eine frühere Freigabe gilt für einen bestimmten Inhalt. Sie sollte nicht automatisch auf den nächsten Entwurf übertragen werden, nur weil die meisten Wörter gleich geblieben sind.

Auch ein geänderter Funktionsname kann mehrere Stellen betreffen. Deshalb würde ich bei einer Überarbeitung das Begriffsverzeichnis und die betroffenen Ansichten zusammen betrachten. Sonst ist die einzelne Übersetzung verständlich, während die App dieselbe Funktion an anderer Stelle anders nennt.

Für die nächste Überarbeitung würde ich die zuletzt freigegebene Fassung erhalten. Damit kann die Redaktion erkennen, welche Änderung aus dem Produkt kommt und welche nur die Formulierung betrifft. Der Modellvorschlag bekommt so einen nachvollziehbaren Platz in der Textpflege.

Was ich bei Kosten und Zugang vergleichen würde

Am 20. Oktober 2026 nennt Googles Preisliste für die reguläre kostenpflichtige API 0,10 US-Dollar je Million Eingabetokens für Text, Bilder und Video. Textausgaben kosten 0,40 US-Dollar je Million Tokens, einschließlich der Tokens für Denkprozesse. Tokens sind die Einheiten, in denen das Modell Inhalte verarbeitet; sie entsprechen nicht einfach einer festen Zahl von Wörtern.

Für eine Textfunktion würde ich neben dieser Abrechnung den Aufwand der Redaktion betrachten. Ein Entwurf spart nur dann Arbeit, wenn Prüfung und Korrektur im Verhältnis dazu überschaubar bleiben. Aus dem niedrigen Tokenpreis allein lässt sich dieser Nutzen nicht berechnen.

Als weiteren Zugang kann man einen Dienst wie Crazyrouter betrachten. Dessen Preisübersicht für Gemini 2.5 Flash-Lite ist eine Anlaufstelle für den Vergleich. Abrechnung und unterstützte Funktionen würde ich beim tatsächlich gewählten Anbieter kontrollieren. Googles Grundpreis ist keine Zusage über die Rechnung eines anderen Dienstes.

Für welche Teams ich den Einsatz erwägen würde

Ich würde Flash-Lite für kleine Produktteams prüfen, die regelmäßig kurze Texte für mehrere Sprachen vorbereiten. Dazu passen Entwickler interner Textwerkzeuge und Redaktionen, die freigegebene Quellen sowie sprachkundige Prüfer haben. Der mögliche Nutzen liegt im Entwurf und in der Überarbeitung wiederkehrender Texte.

Wer eine neue Sprache ohne jede fachkundige Kontrolle veröffentlichen möchte, hat damit die entscheidende Lücke noch nicht geschlossen. Auch sensible Bedingungen oder zentrale Produktzusagen brauchen einen passenden Freigabeprozess.

Meine Empfehlung wäre deshalb, die Zuständigkeiten vor der Integration festzulegen: Das Modell schlägt eine Formulierung vor, die Redaktion verantwortet Bedeutung und Ton, das Produktteam prüft die Anzeige. Für Teams mit dieser Aufteilung ist Gemini 2.5 Flash-Lite ein plausibler Kandidat. Seine Eignung für die konkreten Zielsprachen bleibt gesondert zu beurteilen.

Quellenstand: 20. Oktober 2026. Modellfunktionen und Grundpreise stammen aus der Google-Dokumentation. Die grundlegenden Modelldaten wurden zusätzlich mit den öffentlichen Daten von models.dev und OpenRouter abgeglichen.

Zwei Arten zu scheitern: Der eine meldet einen Fehler, der andere schweigt

boluo — Tue, 20 Oct 2026 14:20:00 +0000

Titelbild zur Veranschaulichung, kein Screenshot einer Produktoberfläche.

Jede Benchmark-Tabelle der Welt zählt dasselbe: richtig oder falsch. Das ist die falsche Achse.

Denn wie ein Modell scheitert, ist praktisch wichtiger als wie oft. Ein Fehler, der eine Ausnahme wirft, kostet dich eine Stunde. Ein Fehler, der still bleibt, kostet dich einen Monat – weil du nicht weißt, dass du einen hast.

Ich habe zwei Modelle durch 19 Aufgaben geschickt und dabei beide Sorten gesehen. Dieser Beitrag handelt nicht davon, welches besser ist. Er handelt davon, wie unterschiedlich sie kaputtgehen.

Vier Arten zu scheitern

Nicht jede Niete ist gleich. Nach diesem Durchlauf sortiere ich so:

1. Falsch geantwortet. Das Modell liefert eine Antwort, sie ist inhaltlich daneben. Unangenehm, aber sichtbar. Test rot, Mensch schaut drauf, fertig.

2. Richtig geantwortet, unbrauchbar formatiert. Die Antwort stimmt, der Parser kommt trotzdem nicht dran. Ebenfalls sichtbar: Die Verarbeitung wirft einen Fehler, irgendwo leuchtet etwas rot. Kostet Bereinigungscode, aber kein Vertrauen.

3. Abgeschnitten. Die Ausgabe endet mitten im Satz, weil das Token-Limit greift. Sichtbar, weil der Abbruchgrund mitgeliefert wird – sofern man ihn liest.

4. Kein finaler Antworttext. Das Modell verbraucht Ressourcen, ruft weiter Werkzeuge auf und erreicht das Rundenlimit, ohne eine lesbare Antwort zu liefern. In den API-Daten steht dabei tool_calls, kein API-Fehler. Wer nur den äußeren Jobstatus prüft, kann den fehlenden Antworttext trotzdem übersehen.

Die vierte Sorte ist die gefährliche.

19 Aufgaben, je ein Durchlauf, 20. Oktober 2026.

Warum die vierte Sorte gefährlich ist

In meinem Durchlauf hat genau das ein Modell getan. Aufgabe: In einem 400-Zeilen-Protokoll steht ein Schlüssel in Zeile 288.

Das eine Modell fand ihn und gab den Wert zurück. Das andere verbrauchte sechs Runden ausschließlich mit Dateizugriffen, las 42766 Eingabe-Token und gab am Ende keine einzige Zeile aus.

Betrachte die Rechnung:

Die sechs Runden endeten mit tool_calls
Die Ausführung erreichte das Rundenlimit
Es gab keinen API-Fehler, aber auch keinen finalen Antworttext
Ohne Prüfung von Stop-Grund und Rundenlimit kann der äußere Job trotzdem als beendet erscheinen
Verbraucht wurden 42766 Eingabe-Token

Bezahlt und nicht geliefert: 42766 Eingabe-Token gegen null Zeichen Ausgabe.

Wenn deine Überwachung nur den äußeren Jobstatus betrachtet, kann der Abbruch unauffällig bleiben. Für deine Nutzer ist die Funktion trotzdem kaputt.

Und in jeder Benchmark-Tabelle steht dafür: eine Aufgabe nicht bestanden. Genau eine Zeile, gleichwertig mit „falsch geraten". Die Tabelle unterscheidet nicht zwischen „hat falsch geantwortet" und „hat aufgehört zu existieren".

Der laute Fehler auf der anderen Seite

Die Formatfehler waren eine andere Sorte als der stille Abbruch. Bei M3 enthielt content Denktext vor der verlangten Ausgabe; dadurch scheiterten alle drei Aufgaben mit striktem Format an der ursprünglichen Prüfung. Bei der nachträglichen Sichtung waren die Inhalte von zwei Antworten passend, aber die dritte Antwort blieb in einem nicht geschlossenen Denkblock und lässt sich nicht verlässlich als Antwort werten.

Ein Parserfehler ist immerhin sichtbar: Er landet im Log und lässt sich gezielt untersuchen. V4-Pro zeigte in der langen Log-Aufgabe das Gegenstück: sechs Runden Dateizugriffe und am Ende keine Antwortzeile. Das sind unterschiedliche beobachtete Fehlerbilder, aber aus je einem kleinen Ausschnitt folgt keine allgemeine Rangfolge der Fehlerrisiken.

Die gewichteten Werte von 0,850 und 0,950 fassen die ursprünglichen Prüfergebnisse dieser 19 Aufgaben zusammen. Sie zeigen weder, dass eine der drei Formatantworten nach Bereinigung sicher bestanden hätte, noch, welches Modell insgesamt zuverlässiger ist.

Dabei wäre der Aufwand gering. Für eine Fehlerarten-Statistik braucht man genau zwei zusätzliche Felder pro Datensatz: den Abbruchgrund und die Anzahl der tatsächlich gelieferten Zeichen. Beides steht in jeder API-Antwort, ohne Zusatzaufruf. Dass es in praktisch keiner Vergleichstabelle auftaucht, liegt nicht daran, dass es schwierig wäre, sondern daran, dass die Tabelle nach Trefferquote sortiert ist.

Wie man stille Ausfälle sichtbar macht

Ein stiller Ausfall ist kein Modellproblem, das man wegkonfigurieren kann. Es ist ein Überwachungsproblem. Drei Dinge reichen.

Erstens: Leere Antworten separat zählen. Nicht als Fehlschlag, sondern als eigene Kategorie. Ein Fehlschlag sagt „hat nicht geklappt". Ein leerer Erfolg sagt „ist durchgelaufen und hat nichts produziert" – das ist ein anderer Alarm.

Zweitens: Rundenlimit und Stop-Grund gemeinsam protokollieren. Ein Turn-Limit schützt vor endlosen Schleifen und zeigt, wenn ein Modell innerhalb des Budgets nicht fertig wurde. Logge finish_reason wie tool_calls zusammen mit dem Erreichen der Grenze, getrennt von einer falschen Antwort.

Drittens: Die Rechnung als Signal nutzen. Wenn eine Aufgabe ein Mehrfaches des üblichen Token-Verbrauchs kostet und trotzdem kein Ergebnis liefert, ist das ein Muster, kein Zufall. Ein Verhältnis aus Ausgabe-Token zu verbrauchten Token, das gegen null geht, ist ein messbarer stiller Ausfall.

Was das für die Auswahl heißt

Wenn du ein Team für API-Betrieb oder SRE leitest, sagt dieser Test nicht, welches Modell insgesamt zuverlässiger ist. Er zeigt aber, welche Prüfungen in deinen Produktionspfad gehören: leere Antworten zählen, stop-Grund und Turn-Limit loggen und eine Ausführung mit tool_calls am Rundenlimit nicht als fertige Antwort behandeln.

Für ein Produkt, das strikte JSON-Ausgaben braucht, ist V4-Pro der bessere Kandidat für einen ersten Pilot: Es bestand hier alle drei Formatprüfungen. Für nächtliche Batch-Verarbeitung mit engem Budget ist M3 einen eigenen Kostentest wert; in diesem Lauf lag die Gesamtrechnung rund 17,6 Prozent niedriger. Beide Hinweise stammen aus 19 einmalig ausgeführten Aufgaben und sind keine allgemeine Rangliste.

Für lange Logs und Dokumente gibt es hier keinen Sieger. Beide Modelle bestanden jeweils eine von zwei Aufgaben, und zwar unterschiedliche. Wer solche Dokumente verarbeitet, sollte ein eigenes Set typischer Fälle mehrfach testen und Kosten pro verwertbarem Ergebnis vergleichen.

Drei Felder, die ich ab jetzt mitschreibe

Der Aufwand dafür ist minimal, der Unterschied groß:

Den Abbruchgrund jeder Antwort – nicht nur „hat geklappt" oder „hat nicht geklappt"
Die Anzahl gelieferter Zeichen – auch dann, wenn die Antwort als erfolgreich gilt
Ob das Rundenlimit erreicht wurde – getrennt von einem inhaltlichen Fehlschlag

Diese drei Felder kosten keinen zusätzlichen Aufruf. Zusammen machen sie sichtbar, ob eine Ausführung eine Antwort geliefert, das Rundenlimit erreicht oder nur weitere Werkzeuge angefordert hat.

Die Trefferquote sagt dir, wie gut ein Modell ist. Sie sagt dir nicht, ob du es merkst, wenn es aufhört zu funktionieren.

Hinweis: Zahlen aus einem Durchlauf am 20. Oktober 2026 mit 19 Aufgaben und zwei Modellen. Der Beitrag vergleicht keine Trefferquoten, sondern Fehlermodi.

DeepSeek Harness: API-Protokoll für externe Modelle wählen und Fehler eingrenzen

boluo — Tue, 20 Oct 2026 08:59:29 +0000

Das Problem

Beim Einrichten eines externen Modells in DeepSeek Harness füllt man die API-Adresse aus, fügt den Schlüssel ein, prüft die Modell-ID — und steht dann vor einem Dropdown ohne jede Erklärung: OpenAI Chat Completions, OpenAI Responses, Anthropic Messages.

Wählt man die falsche Option, kommt ein Fehler, der nicht verrät, welche der drei gemeint war. Ein 401 sieht aus wie ein falscher Schlüssel, ein 404 wie eine falsche Adresse, und ein 400 wie ein Tippfehler im Feldnamen.

Dieser Beitrag zeigt, was sich hinter den drei Optionen tatsächlich unterscheidet, wie man sie in drei Schritten auseinanderhält und was bei einem Test am 20. Oktober 2026 herauskam.

Kurzfassung

Unklar? OpenAI Chat Completions wählen. Die meisten Anbieter implementieren dieses Format.
Der Anbieter bietet nur /v1/messages an, oder es wird ein Claude-natives Werkzeug angebunden: Anthropic Messages.
Responses nur dann, wenn nachweislich serverseitige Funktionen wie Kontextspeicherung oder eingebaute Werkzeuge vorhanden sind.

Umgebung

Punkt	Wert
Betriebssystem	Windows 10 / 11
Client	DeepSeek Harness Desktop, Oberfläche Stand Oktober 2026
Gegenstelle	beliebiger OpenAI- oder Anthropic-kompatibler Dienst (hier als Beispiel: Crazyrouter)
Basis-URL	`https://api.crazyrouter.com/v1` — nur bis `/v1`, den Rest ergänzt der Client
Testdatum	20.10.2026
Modelle	`deepseek-v4-pro`, `claude-opus-4-5`
Authentifizierung	`Authorization: Bearer`, Schlüssel aus der Umgebungsvariable `CRAZYROUTER_API_KEY`

Was sich wirklich unterscheidet

Die drei Optionen sind keine Stufen („einfach“, „fortgeschritten“, „profi“), sondern drei parallele Nachrichtenformate. Vier Dinge ändern sich:

Wer den Kontext hält: Chat Completions und Messages sind zustandslos, der Client sendet den Verlauf bei jeder Anfrage erneut. Responses kann ihn serverseitig speichern.
Wo die Systemanweisung liegt: im ersten Element von messages, im Feld instructions oder im Feld system auf oberster Ebene.
Wie Werkzeugaufrufe zurückkommen: tool_calls, function_call oder tool_use.
Wo der Text steht: in choices, in output oder in einem content-Array.

Wichtig: „OpenAI“ im Namen bezeichnet das Format, nicht die Modellmarke. Welches Modell antwortet, entscheidet die Modell-ID im Feld darüber.

Schritte

1. Felder ausfüllen

„Einstellungen → Modelle → Modellanbieter hinzufügen“, dann „Benutzerdefinierte Modell-API“
Provider-ID: freier Kleinbuchstabe, nicht mit anderen Einträgen doppelt (Beispiel: crazyrouter)
Anzeigename: nur zur eigenen Orientierung im Menü
API-Adresse: die Basis-URL des Dienstes, nur bis /v1 — nicht den vollständigen Pfad eintragen
API-Protokoll: im Zweifel OpenAI Chat Completions
API-Schlüssel: der Schlüssel desselben Dienstes
Modellkatalog: „Verfügbare Modelle abrufen“ oder Modell-ID manuell eintragen
Speichern, neue Sitzung öffnen, Modell auswählen

2. Prüfskript in drei Schritten

$base    = "https://api.crazyrouter.com/v1"   # Beispiel: Crazyrouter
$headers = @{ Authorization = "Bearer $env:CRAZYROUTER_API_KEY" }

# Schritt 1: Modellliste — prüft nur Adresse und Schlüssel
Invoke-RestMethod -Uri "$base/models" -Headers $headers |
  Select-Object -ExpandProperty data | Select-Object -First 5 -Property id

# Schritt 2: alle drei Endpunkte abklopfen, nur den Statuscode lesen
foreach ($p in @("/chat/completions", "/responses", "/messages")) {
  $r = Invoke-WebRequest -Uri "$base$p" -Method Post -Headers $headers `
       -ContentType "application/json" -Body "{}" -SkipHttpErrorCheck
  Write-Output ("{0,-20} {1}" -f $p, $r.StatusCode)
}

# Schritt 3: kleinste mögliche Anfrage
$body = @{
  model    = "deepseek-v4-pro"
  messages = @(@{ role = "user"; content = "Antworte nur mit OK" })
} | ConvertTo-Json -Depth 5

Invoke-RestMethod -Uri "$base/chat/completions" -Method Post `
  -Headers $headers -ContentType "application/json" -Body $body |
  Select-Object -ExpandProperty choices

Schritt 2 funktioniert auch ohne Schlüssel: $headers weglassen und einen leeren Body senden. Ein 401 heißt, die Route existiert; ein 404 heißt, sie existiert nicht.

Verifikation: Ergebnisse vom 20.10.2026

Ohne Schlüssel lässt sich die Existenz der Route prüfen. Alle vier echten Pfade antworteten mit 401 und dem Text 未提供令牌 („kein Token angegeben“); ein absichtlich falscher Pfad antwortete mit 404 und Invalid endpoint path. Der Dienst prüft die Route vor dem Token — deshalb funktioniert dieser Test auch vor der Einrichtung.

Alle drei Endpunkte antworteten mit 200. Die Antwortzeit lag zwischen zwei und vier Sekunden. Der Unterschied liegt in der Position des Textes:

Endpunkt	Modell	Status	Felder auf oberster Ebene
`/chat/completions`	deepseek-v4-pro	200	`choices,id,model,object,usage`
`/responses`	deepseek-v4-pro	200	`output,output_text,status,object`
`/messages`	claude-opus-4-5	200	`content,stop_reason,type,role,usage`

404 hat zwei Bedeutungen. Eine falsche Modell-ID ergibt ebenfalls 404, aber im Body steht model_not_found samt Modellnamen. Nur der Body unterscheidet „falscher Pfad“ von „falsches Modell“.

Der Dienst ist großzügiger als die Spezifikation. Anthropic verlangt max_tokens; hier wurde auch ohne dieses Feld 200 zurückgegeben. x-api-key und Authorization: Bearer wurden beide akzeptiert. Die OpenAI-kompatiblen Endpunkte akzeptierten dagegen nur Bearer — mit x-api-key kam 401. Regeln lassen sich also nicht ungeprüft von einem Anbieter auf einen anderen übertragen.

Werkzeugaufrufe funktionieren in allen drei Formaten, aber unterschiedlich:

Protokoll	Anfrage	Antwort
Chat Completions	`tools[].function.parameters`	`message.tool_calls[]`, `finish_reason=tool_calls`
Messages	`tools[].input_schema`	`content[0].type=tool_use`, `stop_reason=tool_use`
Responses	`tools[].type=function`	`function_call` innerhalb von `output[]`

Responses: Die Websuche funktioniert, die Kontextfortsetzung nicht. Mit tools=[{"type":"web_search"}] erschienen fünf web_search_call-Einträge mit echten Suchergebnissen; instructions wurde ebenfalls beachtet. Im zweiseitigen Test mit previous_response_id erinnerte sich das Modell jedoch nicht an die erste Nachricht — die Antwort war von einem Kontrolllauf ohne diesen Parameter nicht zu unterscheiden. Ein akzeptiertes Feld ist kein Beweis für eine implementierte Funktion.

Fehlersuche

401 — Schlüssel falsch oder am falschen Ort. OpenAI-Format: Authorization: Bearer. Messages: x-api-key (manche Dienste akzeptieren auch Bearer).
404 — Route fehlt (Invalid endpoint path) oder Modell-ID falsch (model_not_found). Immer den Body lesen.
400 / 422 — Route vorhanden, Anfrage nicht konform. Fehlt model, kommt Model name is required.
200, aber wirkungslos — eine system-Anweisung im Anthropic-Stil an einen Chat-Completions-Endpunkt ergibt 200, wird aber ignoriert. Kein Fehler bedeutet nicht, dass die Anweisung greift.

Die Reihenfolge lautet: Adresse → Schlüssel → Route → Felder. Wer alle vier gleichzeitig ändert und dann einen Fehler bekommt, hat nichts gelernt.

Austausch

Mich würde interessieren, wie andere Anbieter sich hier verhalten: Akzeptiert euer Dienst ebenfalls beide Authentifizierungs-Header, und funktioniert die Kontextfortsetzung über previous_response_id tatsächlich? Genau das ist der Punkt, an dem sich Anbieter am stärksten unterscheiden, und der sich nur durch einen eigenen Test klären lässt.

Für diese Tests nutze ich Crazyrouter: ein Schlüssel für Modelle mehrerer Anbieter, mit getrennten OpenAI- und Anthropic-kompatiblen Einstiegspunkten — praktisch, um die drei Schritte oben im selben Konto zu vergleichen.

Quellen

OpenAI API-Dokumentation — Felddefinitionen für Chat Completions und Responses
Anthropic Messages API — Anfrage-Header, system-Feld und Werkzeugblöcke
DeepSeek Harness — Client-Download und Modelleinrichtung
Crazyrouter-Dokumentation — OpenAI- und Anthropic-kompatible Zugänge

Claudecode-Desktop-Update: Was sich bei parallelen Aufgaben ändert

boluo — Mon, 19 Oct 2026 10:46:22 +0000

Eine Funktion ist implementiert, aber der Regressionstest fehlt. Gleichzeitig müsste jemand die Dokumentation prüfen. Beides lässt sich auslagern — solange klar bleibt, welche Dateien bearbeitet werden und wo die Ergebnisse wieder zusammenkommen.

Genau dafür ist das jüngste Claudecode-Desktop-Update interessant. Die Ankündigung vom 14. Oktober 2026 UTC, in Peking bereits der 15. Oktober, verbindet verschachtelte Sitzungen, Vorschläge für Folgeaufgaben und sichtbarere Fortschritte. Hinzu kommen bequemere Projekteinstiege und gespeicherte Umgebungen.

Ein Teammitglied beschrieb das als „fast v2“. Ich würde daraus zunächst keine Geschwindigkeitszusage ableiten. Für die Entwicklung ist die konkretere Frage: Welche Teile einer Aufgabe lassen sich jetzt besser verteilen und anschließend prüfen?

Mit image2 erstellte Konzeptillustration, kein Screenshot der Anwendung.

1. Folgeaufgaben und verschachtelte Sitzungen unterscheiden

Die neue Oberfläche zeigt Vorschläge für Arbeiten, die sich aus einer laufenden Aufgabe ergeben. Ein solcher Vorschlag kann eine eigene Sitzung starten. Das ist beispielsweise sinnvoll, wenn bei einem Bugfix auffällt, dass eine Erklärung in der Dokumentation veraltet ist.

Eine verschachtelte Sitzung hat eine andere Rolle. Wenn Claude mehrere Aufgaben parallel bearbeiten soll, kann es solche Sitzungen anlegen und deren Ergebnisse an die Hauptunterhaltung zurückmelden lassen.

Ein Vorschlag kann zusätzliche Arbeit aus der aktuellen Unterhaltung herauslösen.

Der Unterschied ist praktisch relevant: Eine Folgeaufgabe ist zunächst eine Entscheidung über weiteren Arbeitsumfang. Verschachtelte Sitzungen helfen dagegen, bereits verteilte Arbeit wieder in der Hauptunterhaltung zusammenzuführen.

Ich würde deshalb nicht jede vorgeschlagene Verbesserung sofort starten. Für einen kleinen Fix kann ein zusätzlicher Umbau schlicht außerhalb des Auftrags liegen. Die Oberfläche erleichtert den Start; sie entscheidet nicht, was zum aktuellen Änderungsumfang gehört.

2. Vor dem Aufteilen die gemeinsame Schnittstelle festlegen

Nehmen wir als Beispiel eine Funktion, die einen Ladefehler im Frontend verständlicher anzeigen soll. Die gewünschte Fehlermeldung und das Format der Fehlerantwort sind bereits festgelegt.

Dann lassen sich zwei Prüfaufgaben gut voneinander abgrenzen: Eine Sitzung sucht fehlende Testfälle, eine andere prüft die angezeigten Texte und die Hilfe. Beide können Ergebnisse liefern, ohne die gemeinsame Schnittstelle neu zu entwerfen.

Ein möglicher Arbeitsauftrag wäre:

Prüfe die Testabdeckung und die Hilfetexte in getrennten Aufgaben. Verändere das vereinbarte Fehlerformat nicht. Melde die gefundenen Lücken und die betroffenen Dateien an diese Unterhaltung zurück.

Das ist ein Formulierungsbeispiel, kein dokumentierter Testlauf. Der wichtige Teil ist die Grenze des Auftrags: Was darf geändert werden, was steht bereits fest und welches Ergebnis soll zurückkommen?

Wenn dagegen beide Sitzungen das Fehlerformat ändern sollen, ist die gemeinsame Entscheidung noch offen. Mehr Parallelität löst diese Abhängigkeit nicht. In diesem Fall würde ich zuerst die Schnittstelle klären und erst danach unabhängige Arbeiten vergeben.

3. Separate Unterhaltungen brauchen passende Arbeitsverzeichnisse

Die aktualisierte Startansicht macht kürzlich verwendete Ordner leichter erreichbar. Häufig benötigte Umgebungen lassen sich speichern, darunter Ordnerkombinationen, SSH-Ziele und Cloud-Umgebungen. Das ist besonders beim Wechsel zwischen mehreren Projekten hilfreich.

Für Git-Projekte stehen Worktrees als getrennte Arbeitsverzeichnisse zur Verfügung. Damit können Sitzungen ihre Dateien bearbeiten, ohne direkt in dieselbe Arbeitskopie zu schreiben. Eine getrennte Unterhaltung allein ist noch keine Aussage darüber, wo ihre Änderungen landen. Vor parallelen Schreibaufgaben lohnt sich deshalb der Blick auf die ausgewählte Umgebung.

Auch bei sauber getrennten Verzeichnissen bleibt die Integration offen: Zwei Änderungen können sich auf unterschiedliche Annahmen über dieselbe Funktion stützen. Ein konfliktfreier Merge beweist noch nicht, dass das kombinierte Verhalten stimmt.

Daneben steht die Verbrauchsfrage. Wer Claudecode über einen API-Zugang abrechnet, sollte bei zusätzlichen Aufgaben auch den tatsächlichen Verbrauch prüfen; Crazyrouter erklärt die Claude-API-Abrechnung und Nutzungskontrolle. Diese API-Abrechnung ist von einem Desktop-Abonnement zu unterscheiden. Die neue Aufgabenansicht belegt für sich genommen weder geringere Kosten noch einen niedrigeren Tokenverbrauch.

4. Fortschritt lesen, dann Änderungen prüfen

Die Seitenleiste macht deutlicher, welche Sitzungen noch arbeiten, welche Aufmerksamkeit benötigen und welche fertig sind. Innerhalb einer Sitzung zeigen laufende Aufgabenlisten den Fortschritt. Rückblickkarten fassen zusammen, was in der Zwischenzeit passiert ist; die Seitenansicht bietet Informationen zu Umgebung, Kontext und Änderungen.

Die Statusanzeige hilft bei der Auswahl der nächsten Sitzung, die geprüft werden sollte.

Nach einer Unterbrechung würde ich zuerst eine Sitzung mit offenem Entscheidungsbedarf öffnen. Anschließend lässt sich die Zusammenfassung mit dem tatsächlichen Diff abgleichen: Welche Dateien wurden geändert? Wurde die vereinbarte Grenze eingehalten? Welche Prüfung stützt die Aussage, dass die Aufgabe erledigt ist?

Diese Reihenfolge hält die Statusanzeige nützlich, ohne sie mit einer technischen Abnahme zu verwechseln. Eine Karte kann den Einstieg in eine Prüfung verkürzen. Sie ersetzt weder die Prüfung der Anforderungen noch das Lesen relevanter Änderungen.

5. Rückfragen mit `/btw` von neuen Anforderungen trennen

Während die Hauptaufgabe läuft, lässt sich mit /btw eine Nebenunterhaltung öffnen. Unter macOS geht das auch mit Cmd + ;, unter Windows mit Ctrl + ;.

Eine kurze Verständnisfrage muss nicht die Hauptunterhaltung verlängern.

Die Funktion gab es bereits vor diesem Update. Sie wird hier im Zusammenhang mit dem überarbeiteten Arbeitsablauf gezeigt und sollte nicht als erstmals im Oktober eingeführte Funktion beschrieben werden.

Für den Einsatz ist die Richtung des Kontexts entscheidend: Die Nebenunterhaltung kennt die Hauptunterhaltung bis zu diesem Zeitpunkt. Ihre Antworten werden jedoch nicht in den Hauptverlauf zurückgeschrieben.

„Warum wird hier erneut versucht?“ passt deshalb gut in die Nebenunterhaltung. „Verzichte auf den erneuten Versuch und ändere die Implementierung“ muss als neue Anforderung in die Hauptunterhaltung. Außerdem werden Nebenunterhaltungen nicht auf der Festplatte gespeichert; nach dem Schließen der App lassen sie sich nicht wiederherstellen.

Was ich beim Update zuerst prüfen würde

Die Desktop-App wird unabhängig von einer separat installierten CLI aktualisiert. Für die Neuerungen also die App aktualisieren und eine neue Sitzung beginnen. In einer lokalen Desktop-Sitzung zeigt /status die dort verwendete Claudecode-Version.

Danach reicht ein begrenzter Auftrag mit zwei unabhängig prüfbaren Teilaufgaben. Entscheidend wäre für mich, ob deren Ergebnisse nachvollziehbar zurückkommen und ob sich offene Entscheidungen schneller finden lassen. Ein komplexer Umbau mit mehreren gemeinsam geänderten Schnittstellen wäre dafür ein unnötig unübersichtlicher erster Versuch.

Das Update verändert vor allem die Organisation der Arbeit. Sein Nutzen lässt sich daran prüfen, ob Aufgaben, Dateien und Rückmeldungen zusammenpassen — und ob am Ende noch klar ist, welche Änderung tatsächlich freigegeben werden kann.

Claude in eine App integrieren: offizielle API oder Gateway?

boluo — Mon, 19 Oct 2026 09:55:36 +0000

Wie ich Funktionen, Abrechnung und Zuständigkeiten vergleichen würde, bevor ich mich für einen Anbieter entscheide.

Mit GPT Image 2 erzeugte konzeptionelle Illustration, keine Aufnahme einer Produktoberfläche.

Wenn ich Claude in einer Anwendung verwenden möchte, beginnt meine Entscheidung bei dieser Anwendung. Welche Aufgabe soll sie erledigen? Welche Verbindung unterstützt sie? Erst danach würde ich zwischen der offiziellen API und einem externen Gateway wählen. Ein günstiger Tarif hilft wenig, wenn die Verbindung zwar Text überträgt, aber eine benötigte Funktion fehlt.

Als Beispiel nehme ich eine gedachte Anwendung, die öffentliche Dokumente zusammenfasst. Sie soll einen Text an Claude schicken und das Ergebnis im eigenen Fenster anzeigen. An diesem einfachen Fall lässt sich erklären, was sich mit dem Anbieterwechsel verändert, ohne gleich eine Konfigurationsdatei öffnen zu müssen.

Zunächst trenne ich Chat und API

Für eine gelegentliche Frage zu einem Dokument kann die Claude-Website bereits ausreichen. Dort nutze ich ein fertiges Produkt mit seiner Oberfläche, seinen Funktionen und den Grenzen des jeweiligen Plans. Ich würde keine zusätzliche API-Verbindung einrichten, solange mir dadurch kein konkreter Vorteil entsteht.

Meine Beispielanwendung soll allerdings selbst Anfragen senden. Dafür braucht sie einen unterstützten Zugang und die passende Berechtigung, häufig einen API-Schlüssel. Dieser Schlüssel ist kein Passwort für die Chat-Website. Er gehört zu dem Dienst, der ihn ausstellt, und seine Nutzung wird nach dessen Regeln abgerechnet.

Ein Guthaben bei einem Drittanbieter schaltet deshalb nicht automatisch einen kostenpflichtigen Claude-Chatplan frei. Ebenso wenig würde ich davon ausgehen, dass ein Chat-Abonnement sämtliche Anfragen einer fremden Anwendung bezahlt.

Eigene erklärende Grafik mit chinesischen Beschriftungen: links das Chat-Abonnement, in der Mitte die offizielle API, rechts der Drittanbieter. Konten, Schlüssel und Guthaben sind nicht automatisch austauschbar. Keine Produktaufnahme.

Meine Anforderungen kommen vor der Preisliste

Bei der Dokumenten-App würde ich zunächst festhalten, welche Inhalte sie verarbeiten soll. Reicht normaler Text? Enthalten die Unterlagen Bilder? Wie umfangreich sind sie? Die Antworten betreffen sowohl die Anwendung als auch den gewählten Dienst.

Eine Modellbezeichnung in einer Liste beantwortet diese Fragen noch nicht. Die App muss die benötigten Daten übertragen können; die konkrete Schnittstelle des Anbieters muss sie unterstützen. Auch die angebotenen Grenzen und die tatsächlich verfügbaren Funktionen können für die Entscheidung relevant sein.

Ich würde daher zuerst die Verbindungsbeschreibung der App lesen. Akzeptiert sie die offizielle Claude-API? Lässt sich ein anderer Anbieter eintragen? Oder bezahlt man bereits einen integrierten Zugang beim App-Anbieter? Erst mit dieser Information wird ein Preisvergleich sinnvoll.

Direktzugang und Gateway ändern die Zuständigkeiten

Bei der offiziellen API würde ich die Spezifikation beim Modellanbieter nachlesen und Verbrauch sowie Abrechnung in dessen Verwaltung prüfen. Für Rückfragen hätte ich die offizielle Unterstützung als Anlaufstelle. Das ist für mich ein Argument, wenn ich eine Anwendung dauerhaft betreiben und Änderungen anhand der ursprünglichen Dokumentation nachvollziehen möchte.

Diese Klarheit ist keine Verfügbarkeitsgarantie. Auch direkt muss ich prüfen, ob mein Konto die Voraussetzungen erfüllt, welche Modelle freigegeben sind und welche Nutzungsgrenzen gelten. Offizieller Zugang bedeutet nicht unbegrenzten Zugang.

Ein Gateway nimmt dagegen die Anfrage meiner App entgegen und leitet sie an einen vorgelagerten Modelldienst weiter. Manche Anbieter bündeln Modelle mehrerer Hersteller. Das kann die Verwaltung vereinfachen, wenn ich diese Auswahl tatsächlich benötige: weniger getrennte Konten, eine gemeinsame Abrechnung oder eine passende Zahlungsoption.

Zum Beispiel zeigt Crazyrouter eine Übersicht der Claude-Modelle und Preise. Ich würde sie zum Eingrenzen der Auswahl verwenden und anschließend die benötigten Funktionen sowie die Abrechnungsbedingungen prüfen. Die Übersicht beschreibt das Angebot des Anbieters; sie belegt weder jede Eigenschaft des Dienstes noch die vollständige Funktionsgleichheit mit dem Claude-Chatprodukt.

Eigene schematische Darstellung auf Chinesisch. Links sendet die Anwendung direkt an die offizielle API, rechts zunächst an einen Vermittler und anschließend an den vorgelagerten Dienst. Die Grafik enthält keine Messwerte zu Geschwindigkeit oder Zuverlässigkeit.

Mit dem Gateway bekomme ich auch eine zusätzliche Geschäftsbeziehung. Schlüssel, Guthaben, Rückerstattung und Kundenunterstützung liegen zunächst bei diesem Anbieter. Ich möchte wissen, welche Aufzeichnungen er bei einer fehlgeschlagenen Anfrage bereitstellt und wie er eine unklare Abbuchung erklärt.

Bei Kundendokumenten kommt eine weitere Prüfung dazu: Welche Daten verarbeitet oder speichert die App, welche das Gateway und welche der Modelldienst? Ich würde die Vorgaben des Auftraggebers vor der Nutzung klären. Der Name des Modells allein beschreibt nicht den vollständigen Weg der Daten.

Bereits vorhandene API-Gutschriften würde ich zuerst prüfen

Eine pauschale Aussage wie „Ein Claude-Abo hat niemals etwas mit API-Guthaben zu tun“ wäre zu grob. Nach der am 15. Oktober 2026 geprüften offiziellen Erläuterung zu monatlichen API-Gutschriften können berechtigte Max- und Team-Abonnenten solche Gutschriften erhalten. Free, Pro und Enterprise fallen nicht unter dieses konkrete Angebot.

Dafür wird eine Claude-Console-Organisation verknüpft. Es gelten Bedingungen für den Vertragsstatus und die erforderlichen Rollen; neue Abonnenten müssen sieben Tage in einem berechtigten Plan gewesen sein. Unverbrauchte Gutschriften verfallen zum Ende des Abrechnungszeitraums. Sie erhöhen die Chat-Nutzungsgrenzen nicht und gelten nicht für interaktive Claude-Code-Sitzungen.

Echter Screenshot der offiziellen Hilfeseite vom 15. Oktober 2026, aufgenommen in der chinesischen Sprachversion. Er zeigt die berechtigten Pläne. Die verlinkte englische Seite erläutert Bedingungen und Geltungsbereich.

Für meine App würde ich deshalb prüfen, ob ein vorhandenes Guthaben ihre konkrete Nutzung abdeckt und in welcher Organisation es liegt. Ein Bonus kann eine zusätzliche Einzahlung zunächst unnötig machen. Er ersetzt aber nicht die Prüfung der Verbindung und des Verwendungszwecks.

Ich rechne pro Aufgabe, nicht pro Klick

Ein Klick auf „Zusammenfassen“ verrät wenig über den Verbrauch. Die App könnte das gesamte Dokument mitsenden, Rückfragen stellen oder mehrere Verarbeitungsschritte ausführen. Für die API-Abrechnung zählen je nach Modell und Tarif unter anderem Eingabe, Ausgabe und gegebenenfalls die Nutzung eines Caches.

Token sind dabei Verarbeitungseinheiten, keine feste Anzahl deutscher Wörter. Ich würde die angezeigte Wortzahl eines Dokuments daher nicht einfach als abrechenbare Tokenzahl übernehmen. Ebenso wenig lässt sich aus einem günstigen Eingabepreis bereits der Gesamtpreis einer langen Antwort ableiten.

Mein Vergleich würde dieselbe Aufgabe mit dem passenden Modell zugrunde legen. Ein Rabatt wäre dann interessant, wenn er sich auf die dafür relevanten Kosten auswirkt. Eine vom Anbieter veröffentlichte Gegenüberstellung würde ich mit den aktuellen offiziellen Konditionen abgleichen, bevor ich daraus eine Ersparnis ableite.

So würde ich die Entscheidung festhalten

Frage an meine Anwendung	Bedeutung für die Auswahl
Unterstützt sie den gewünschten Anbieter?	Ohne passende Verbindung ist der Tarif kein nutzbares Angebot.
Sind alle benötigten Funktionen verfügbar?	Modellname und tatsächlicher Funktionsumfang müssen getrennt geprüft werden.
Kann ich Verbrauch und Fehler zuordnen?	Ich brauche eine nachvollziehbare Abrechnung und einen klaren Ansprechpartner.
Passt der Datenweg zum Auftrag?	Auch Anwendung und Vermittler gehören in die Prüfung.

Wenn ich vor allem eine direkte Beziehung zum Modellanbieter und dessen Dokumentation benötige, würde ich die offizielle API bevorzugt prüfen. Wenn mehrere Modellfamilien und eine gebündelte Verwaltung echte Arbeit sparen, gehört ein Gateway in die engere Auswahl. Für reine Gespräche im fertigen Chatprodukt würde ich beide API-Varianten zunächst zurückstellen.

Ich würde mit einer überschaubaren Aufgabe, nicht vertraulichen Daten und einem begrenzten Budget beginnen. Ziel wäre, eine brauchbare Ausgabe und eine verständliche Verbrauchsaufzeichnung zu erhalten. Ein Anbieterwechsel garantiert weder Schutz vor Kontobeschränkungen noch störungsfreien Betrieb.

Für mich ist die Auswahl gelungen, wenn ich erklären kann, warum diese Verbindung zu dieser Anwendung passt. Genau diese Begründung bleibt auch dann hilfreich, wenn sich später Preise, Modelle oder Anforderungen ändern.

Einstieg in DeepSeek Harness: Desktop-App installieren und eine externe API anbinden

boluo — Mon, 19 Oct 2026 07:58:11 +0000

Vom Download zur Modellauswahl: So würde ich einen Anbieter auswählen, den API-Schlüssel vorbereiten und die Verbindung in der Oberfläche einrichten.

Bei einem neuen KI-Werkzeug möchte ich zuerst wissen, welche Entscheidungen überhaupt nötig sind. Muss ich ein bestimmtes Konto verwenden? Kann ich einen vorhandenen API-Zugang eintragen? Und an welcher Stelle wähle ich das eigentliche Modell?

Für DeepSeek Harness würde ich diese Fragen entlang der Einrichtung beantworten. Zuerst kommt die Desktop-App. Danach entscheide ich mich für einen bereits aufgeführten Anbieter oder eine eigene API-Adresse. Erst mit dieser Entscheidung stehen die Angaben fest, die in die Formularfelder gehören.

Mit der Desktop-Version anfangen

Der Download steht auf der offiziellen Harness-Website. Unter Windows lade ich das Windows-Installationspaket herunter, öffne es und folge dem Installationsdialog. Anschließend lässt sich die Anwendung starten. Wer macOS nutzt, sollte auf die unterstützte Architektur achten: Der derzeit angebotene Mac-Download ist für Apple Silicon vorgesehen.

Die hier gezeigte Oberfläche stammt von der Windows-Desktop-Version im Oktober 2026. Das Produkt wird noch als Vorschau angeboten; Beschriftungen und Positionen können sich deshalb ändern. Für diesen Weg bleibe ich beim Installationspaket und der grafischen Oberfläche.

Beim ersten Start kann Harness nach einem offiziellen DeepSeek-API-Schlüssel fragen. Für diese Anleitung wähle ich die Möglichkeit, die Einrichtung später fortzusetzen. Beide Verbindungswege beginnen anschließend in den Modelleinstellungen.

Die erste Entscheidung betrifft den Anbieter

Über das Kontomenü unten links geht es zu den Einstellungen und zum Bereich für Modelle. Dort öffne ich die Funktion zum Hinzufügen eines Modellanbieters. Zur Auswahl stehen vorkonfigurierte Anbieter und eine benutzerdefinierte Modell-API.

Wenn mein Dienst bereits aufgeführt ist, würde ich diesen Eintrag verwenden. Harness bringt dann die Verbindungskonfiguration und den Modellkatalog mit. Je nach Dienst wird ein API-Schlüssel oder eine Anmeldung beim Anbieter benötigt. Bei mehreren Varianten eines Anbieters orientiere ich mich an der Region und dem Zugang, die zu meinem Konto gehören.

Eine benutzerdefinierte API ist sinnvoll, wenn ich eine bestimmte Basisadresse selbst angeben möchte. Das kann ein kompatibler API-Dienst oder ein Zugang der eigenen Organisation sein. Dafür trage ich Adresse, Protokoll, Schlüssel und Modell selbst ein.

Für mich liegt der Unterschied also im Umfang der vorbereiteten Einstellungen. Mehr Felder bedeuten mehr Kontrolle über die Verbindung, aber nicht automatisch ein passenderes Modell. Ich würde die Variante danach auswählen, welche Angaben mein Dienst bereitstellt.

Einen vorhandenen Anbieter einrichten: DeepSeek als Beispiel

Auf der DeepSeek-Plattform registriere ich mich beziehungsweise melde mich an. Unter API keys lässt sich ein Schlüssel erstellen. Diesen kopiere ich vollständig, wechsle zurück zu Harness und öffne Einstellungen → Modelle. Dort trage ich ihn in den DeepSeek-Eintrag ein.

Nach dem Speichern wähle ich in einer neuen Unterhaltung ein Modell aus dieser Anbietergruppe. Zusätzlich gehört für mich ein Blick auf das verfügbare API-Guthaben dazu. Der Schlüssel stellt den Zugang her; die Nutzungsbedingungen und das Guthaben gehören zum API-Konto.

Bei einem anderen vorhandenen Anbieter wähle ich dessen Eintrag über „Modellanbieter hinzufügen“, trage den zugehörigen Schlüssel ein oder schließe die Anmeldung ab und speichere. Anschließend wähle ich in einer neuen Unterhaltung ein Modell dieses Anbieters.

Damit ist der Weg über einen vorhandenen Anbieter abgeschlossen. Der folgende Abschnitt einschließlich Modellauswahl gehört ausschließlich zur Alternative mit einer eigenen API-Adresse.

Für die eigene Adresse erst den Schlüssel vorbereiten

Als konkretes Beispiel verwende ich Crazyrouter. Mir ist wichtig, die Einrichtung vom Konto bis zum Modelleintrag zusammenhängend zu erklären. So bleibt nachvollziehbar, von welchem Dienst die einzelnen Angaben stammen.

Über die Registrierung bei Crazyrouter lässt sich ein Konto anlegen. Dazu gehören die aktuell abgefragten Angaben wie Benutzername, Passwort und E-Mail-Adresse sowie die Bestätigungsschritte auf der Seite. Mit einem bestehenden Konto melde ich mich direkt an.

Danach öffne ich die Tokenverwaltung und erstelle einen API-Schlüssel für den Modellzugriff. Ohne aktive Anmeldung führt dieser Link zunächst zur Anmeldeseite.

Ich würde dem Schlüssel einen eindeutigen Namen wie „Harness Desktop“ geben. So erkenne ich seinen Zweck später in der Verwaltung. Falls eine Gültigkeitsdauer, ein Nutzungslimit oder eine Einschränkung auf bestimmte Modelle gesetzt ist, gehört das zur Auswahl des Schlüssels dazu.

In Harness eine erkennbare Verbindung anlegen

Nach dem Erstellen kopiere ich den vollständigen Schlüssel. Zurück in Harness öffne ich Einstellungen → Modelle → Modellanbieter hinzufügen → Benutzerdefinierte Modell-API. Zuerst vergebe ich die Provider ID, beispielsweise crazyrouter, sofern diese Kennung noch frei ist. Als Anzeigenamen verwende ich Crazyrouter.

Diese beiden Angaben beschreiben den gespeicherten Anbieter. Die ID dient als Kennung der Konfiguration, der Anzeigename als lesbare Bezeichnung im Menü. Möchte ich später nur die sichtbare Bezeichnung ändern, würde ich den Anzeigenamen bearbeiten und die bestehende Kennung beibehalten.

Danach folgen die eigentlichen Verbindungsdaten. Für dieses Beispiel lautet die API-Adresse https://crazyrouter.com/v1. Als Protokoll wähle ich OpenAI Chat Completions. In das Schlüsselfeld kommt der gerade bei Crazyrouter erstellte API-Schlüssel.

Die Bezeichnung OpenAI beschreibt an dieser Stelle das Format der Anfragen. Darüber kann auch ein DeepSeek-Modell angesprochen werden, wenn der Dienst dieses Modell mit dem gewählten Format anbietet. Anbieter, Protokoll und Modell sind deshalb drei unterschiedliche Angaben.

Ich würde die Adresse genau bis zum angegebenen Basispfad eintragen. Einen vollständigen Pfad für eine einzelne Chat-Anfrage muss ich hier nicht ergänzen. Ebenso gehört zu dieser Adresse der Schlüssel des entsprechenden Dienstes; der offizielle DeepSeek-Schlüssel ist für den offiziellen Zugang bestimmt.

Das gewünschte Modell aus dem Katalog übernehmen

Harness kann verfügbare Modelle abrufen und zur Auswahl anbieten. Daneben gibt es die Möglichkeit, einen Modelleintrag über seine ID hinzuzufügen. Für das Beispiel nehme ich die ID direkt aus dem Katalog des Anbieters.

Ich öffne die Modellübersicht von Crazyrouter, filtere nach DeepSeek und suche die gewünschte Modellkarte. Über deren Kopiersymbol übernehme ich den Modellbezeichner. Zurück im noch geöffneten Formular der benutzerdefinierten API wähle ich anschließend „Modell hinzufügen“ und füge den Wert in das Feld für die Modell-ID ein.

Ich bevorzuge das Kopieren, weil die genaue Version Teil des Bezeichners sein kann. Einen übersichtlichen Anzeigenamen kann ich unabhängig davon vergeben. Die Modell-ID bleibt in der Schreibweise erhalten, die der Dienst vorgibt. Preise, Verfügbarkeit und die Freigabe für meinen Schlüssel prüfe ich anhand des aktuellen Angebots.

Zum Schluss speichere ich den Anbieter und öffne eine neue Unterhaltung. Im Modellmenü wähle ich die Gruppe crazyrouter und darin das hinzugefügte DeepSeek-Modell.

Ich achte dabei zuerst auf die Anbietergruppe: Im Beispiel gehört das Modell zur Gruppe crazyrouter. Ein gleichnamiger Eintrag unter DeepSeek würde den offiziellen Zugang auswählen. Nach der Auswahl sehe ich neben dem Eingabefeld nach, welches Modell für die Unterhaltung eingestellt ist.

Weiterführend: Offizielle Dokumentation zu Modellanbietern in Harness.