Qwen 3.8 Max API-Preise: 16 Thinking-Tokens statt Abschalten

Qwen 3.8 Max kostet $2 pro Million Input-Tokens und $6 pro Million Output-Tokens. Die günstigste zuverlässige Konfiguration ist jedoch nicht die, die die API auf den ersten Blick nahelegt. Mit reasoning_effort: "none" fiel die Trefferquote bei unserer zweistufigen Rechenaufgabe von 4/4 auf 1/6. Ein hartes Budget von nur 16 Thinking-Tokens brachte sie wieder auf 6/6 und verbrauchte im Schnitt ein Fünftel weniger Output-Tokens als die Standardeinstellung. In der Launch-Woche gab es große Versprechen zur Leistungsfähigkeit, aber kaum überprüfbare Belege: keine Model Card, keine öffentliche Benchmark-Tabelle und nur interne Evals. Auf Hacker News wurde das schnell kritisiert. Das Abrechnungsverhalten lässt sich dagegen mit jedem API-Key messen. Wir haben qwen3.8-max am ersten Tag über das Synthorai-Gateway getestet: sämtliche akzeptierten Thinking-Optionen, den Reasoning-Aufschlag je Einstellung, Mindestgröße und Aufbauzeit des impliziten Caches, das versprochene Kontextfenster von 1M Tokens und die Unterschiede zu Qwen 3.7.

TL;DR

• Die sieben Werte für reasoning_effort bei qwen3.8-max ergeben praktisch vier Verhaltensweisen: aus, ein Limit von 4,096 Tokens, ein Limit von 16,384 Tokens und unbegrenzt.
• thinking_budget wird exakt eingehalten: Fordert man 16 Tokens an, zeigt der Zähler 16. Das Maximum liegt bei 262,144.
• Ohne Thinking fiel die Trefferquote bei zweistufigen Rechenaufgaben auf 1/6. Mit einem Budget von 16 Tokens lag sie bei geringeren Kosten wieder bei 6/6.
• Der implizite Cache ist in weniger als 0.3 Sekunden aufgebaut und Cache-Reads kosten $0.25/1M. Prompts unter etwa 4,300 Tokens werden jedoch nicht gecacht.
• Die Input-Limits gelten exakt und führen bei Überschreitung zu einem Fehler: 991,808 ohne Thinking, 983,616 mit Thinking.

Was bewirken die Thinking-Optionen von Qwen 3.8 Max tatsächlich?

Drei Parameter funktionieren, aber nicht so, wie es die Dokumentation beschreibt. Laut Drittanbieter-Dokumentation unterstützt reasoning_effort drei Werte: low, medium und xhigh, wobei xhigh der Standard ist. Die von uns getestete API akzeptiert sieben: none, minimal, low, medium, high, xhigh und max. Bei einem ungültigen Wert gibt die Fehlermeldung genau diese Allowlist zurück. Zusätzlich werden das native thinking_budget (eine positive Ganzzahl bis 262,144) und enable_thinking (Boolean) an den Provider durchgereicht und dort validiert. Ein Budget von 0 oder 262,145 führt zu einem 400-Fehler, der den zulässigen Bereich nennt.

Bei gewöhnlichen Aufgaben lassen sich die Effort-Stufen nicht unterscheiden. Bei einfachen Fragen, zweistufigen Rechenaufgaben und einem mittelschweren Kombinatorikproblem verbrauchten low, medium, high, xhigh und die Standardeinstellung Reasoning-Tokens innerhalb derselben schwankenden Bandbreite. Erst bei einer Aufgabe, die Zehntausende Thinking-Tokens benötigt, zeigen sich Unterschiede. Bei einem Primzahlproblem mit 45,129 Reasoning-Tokens ohne Limit griffen die Grenzen schließlich:

Alle Beobachtungen passen zu einem Modell: Jede Effort-Stufe steht für ein vordefiniertes Thinking-Budget, und die sieben Bezeichnungen ergeben vier verschiedene Verhaltensweisen. Die erste ist „aus“: none und enable_thinking: false verhalten sich identisch. Minimal und low teilen sich dasselbe Limit von 4,096 Tokens. Medium vervierfacht es auf 16,384. High, xhigh, max und die Standardeinstellung bilden die vierte Stufe. Bei dieser Aufgabe erreichte keine davon ein Limit; je nach Lauf wurden zwischen 35K und 45K Tokens verbraucht, was bei dieser Tiefe der üblichen Streuung entspricht. Sollten sich die drei höchsten Stufen überhaupt unterscheiden, liegt die Grenze oberhalb von 45K Thinking-Tokens und damit tiefer, als der meiste Production-Traffic je kommt. Die Angabe in der Dokumentation, xhigh sei der Standard, passt zu allen Messwerten. Der Unterschied ist deutlich: Jeder begrenzte Lauf lieferte eine falsche Antwort, jeder unbegrenzte eine richtige. Solange eine Aufgabe unter dem Limit bleibt, verhalten sich die Stufen identisch. Deshalb scheint der Regler bei alltäglichem Traffic wirkungslos. Oberhalb des Limits wird das Thinking mitten in der Aufgabe abgeschnitten. Wer ein bestimmtes Limit braucht, sollte die Presets überspringen und thinking_budget direkt setzen. Der nächste Abschnitt untersucht diesen Parameter genauer.

Wie funktioniert thinking_budget tatsächlich?

Das Limit wird token-genau durchgesetzt, ist eine Obergrenze statt einer Quote und kann bei mittlerer Größe höhere Kosten verursachen als ganz ohne Limit. thinking_budget ist der native Integer-Parameter von DashScope (1 bis 262,144, dokumentierter Standard 131,072, übernommen aus der Open-Weight-Familie Qwen3). Er legt die maximale Anzahl an Reasoning-Tokens für einen Call fest. Werte von 0 oder 262,145 werden mit einem 400-Fehler abgelehnt, der den zulässigen Bereich nennt. Unterhalb der Obergrenze ändert sich nichts: Ein Budget von 8,192 verbrauchte bei einer Aufgabe, die von sich aus nur einige Hundert Tokens benötigt, 331 beziehungsweise 485 Tokens, genau wie ohne gesetztes Budget. Sobald die Obergrenze erreicht wird, greift sie token-genau: Budgets von 16, 64 und 256 stoppten das Reasoning in jedem Lauf exakt bei 16, 64 beziehungsweise 256 Tokens.

Interessant ist, was an dieser Grenze passiert. Das Modell bricht die Aufgabe nicht ab. Es beendet das Reasoning und erledigt den Rest in der sichtbaren Antwort. Bei einer mittelschweren Kombinatorikaufgabe, der Anzahl der Domino-Parkettierungen eines 2x12-Rasters, lieferten alle Budgets die richtige Antwort. Die Gesamtkosten entsprechen jedoch nicht dem erwarteten Verlauf:

Die Kurve verläuft nicht monoton. Ein Budget von 256 Tokens kostete 2.5x so viel wie die Ausführung ohne Budget: Das Modell begann innerhalb seines Budgets eine Reasoning-Kette, wurde mitten im Gedankengang abgeschnitten und leitete die Antwort anschließend im sichtbaren Kanal noch einmal Schritt für Schritt her. Das kleinste Budget schnitt besser ab als die mittleren, weil 16 Tokens für einen echten Ansatz nicht ausreichen und das Modell direkt zu einer kompakten sichtbaren Lösung übergeht. Daraus folgen drei Regeln. Erstens sind sehr kleine Budgets bei einfachen bis mittelschweren Aufgaben ein wirksamer Hebel: Mit 16 Tokens erzielte unser Batch aus zweistufigen Rechenaufgaben 6/6 und verbrauchte insgesamt 98-161 Tokens statt 126-207 mit der Standardeinstellung. Zweitens sollte man bei Traffic mit unbekannter Aufgabentiefe keine mittleren Limits verwenden. Sie landen in einem ungünstigen Bereich, in dem echtes Reasoning abgeschnitten wird und man die Arbeit doppelt bezahlt. Die Zeilen mit 4,096 und 16,384 Tokens bei der komplexen Aufgabe zeigen denselben Effekt in größerem Maßstab; dort waren auch die Antworten falsch. Drittens verändert ein erreichtes Budget die Form des Outputs: Begrenzte Läufe zeigen den Rechenweg in der Antwort. Das ist relevant, wenn ein Parser nur ein nacktes Ergebnis erwartet.

Wie viel von der Dokumentation zum Launch bestätigt sich in Messungen?

Etwa die Hälfte. Diese Aufteilung ist relevant, weil sich derzeit kaum eine andere Aussage zum Launch unabhängig prüfen lässt. Alle folgenden Werte stammen aus unseren eigenen Messungen und Tests:

Das Muster spricht für die Abrechnungsebene: Alles, was die Kosten bestimmt, ist präzise und wird korrekt durchgesetzt. Die Parameterdokumentation hinkt dagegen dem tatsächlichen Verhalten der API hinterher.

Spart das Abschalten von Thinking Geld?

Es spart Tokens, kostet aber Korrektheit. Nur zwei Zeilen weiter liegt ein besserer Kompromiss. In unserem reproduzierbaren Batch mit zweistufiger Arithmetik, 1850 Kisten mit je 24 Teilen, davon 75% verschickt und 3,120 angekommen, erzielte die Standardeinstellung 4/4 bei 126-207 Completion-Tokens pro Call. reasoning_effort: "none" erzeugte Antworten mit 4-5 Tokens und kam auf 1/6. Derselbe Prompt mit thinking_budget: 16 erreichte 6/6 bei 98-161 Completion-Tokens. Für diese Aufgabenklasse war das günstiger als die Standardeinstellung und ebenso zuverlässig. Einstufige Arithmetik blieb auch mit none bei 3/3. Für Lookups und Transformationen mit einem einzigen Schritt ist das Abschalten daher sicher; Probleme entstehen bei mehrstufigen Aufgaben. Das ist keine Regression in 3.8: qwen3.7-max erreichte im identischen Batch ohne Thinking 3/6.

Bei schwierigen Aufgaben lässt sich der im Budget-Abschnitt beschriebene ungünstige Bereich direkt in Dollar beziffern. Beim komplexen Primzahl-Lauf verbrauchte das low-Preset zunächst seine 4,096 Thinking-Tokens und anschließend weitere 13,882 Tokens für eine sichtbare Prüfung der Kandidaten. Die Antwort war trotzdem falsch: $0.11 für ein falsches Ergebnis gegenüber $0.27 für das richtige Ergebnis der Standardeinstellung. Bei schwierigen Aufgaben zeigt das vollständige Abschalten denselben Effekt: Ohne Thinking gaben sowohl 3.8 als auch 3.7 in jeweils einem Lauf eine 13-15K Tokens lange Aufzählung in der sichtbaren Antwort aus. Ein Modell traf die richtige Anzahl, das andere verfehlte sie um genau eine Primzahl. Ein Budget, das mitten im Reasoning greift, kann die Gesamtkosten erhöhen und gleichzeitig die Qualität senken. Begrenzen Sie Thinking nur bei Aufgaben, von denen Sie wissen, dass sie einfach sind. Komplexe Aufgaben sollten ohne knappes Limit laufen.

Ist das Kontextfenster mit 1M Tokens real?

In der Praxis ja, mit exakten und transparenten Grenzen. Die API akzeptiert ohne Thinking bis zu 991,808 Input-Tokens und mit Thinking bis zu 983,616. Beide Limits werden klar durchgesetzt: Ein zu großer Request wird nicht stillschweigend gekürzt, sondern mit einem 400-Fehler abgelehnt, der das exakte Limit nennt. Der Needle-Recall funktionierte bei allen getesteten Größen von 161K, 677K und 919K Tokens. Der eingefügte Override-Code wurde innerhalb von 11 bis 63 Sekunden wortgetreu zurückgegeben. Ein Request mit 919K Tokens kostet zum Listenpreis etwa $1.84. Das Kontextfenster ist also real, aber ein Call über die volle Länge sollte eine bewusste Architekturentscheidung und kein Standard sein.

Was leistet der implizite Cache, und wo liegt die Mindestgröße?

Der Cache wird schneller aufgebaut als jeder andere von uns gemessene, verlangt aber ungewöhnlich große Prompts. Bei einem wiederholten, gesalzenen Prompt mit 6,103 Tokens erfolgte bereits beim nächsten Request 0.3 Sekunden später ein Hit. Anders als bei Gemini mit einer Aufbauzeit von mehreren Dutzend Sekunden muss hier kein Warm-up berücksichtigt werden. Ohne erneutes Priming gab es nach +5 und +15 Minuten weitere Hits; nach +45 Minuten war der Eintrag verschwunden. Die nutzbare Lebensdauer liegt damit bei 15 bis 45 Minuten ohne Zugriff. Reads kosten $0.25 pro Million Tokens, also das 0.125-Fache des Input-Preises. Für Writes gibt es keinen Aufschlag. Der Rabatt erschien automatisch im Feld cached_tokens und in den gemessenen Kosten.

Der Haken ist die Mindestgröße. Ein Prompt mit 4,221 Tokens führte nie zu einem Hit, einer mit 4,360 Tokens dagegen schon. Jeder erste Hit umfasste exakt 4,096 Tokens. Unterhalb von ungefähr 4.3K Prompt-Tokens steht dieser Cache faktisch nicht zur Verfügung. Das unterscheidet ihn deutlich vom Minimum von 1,024 Tokens bei Claude und vom automatischen Caching kleiner Blöcke bei Kimi K3. Oberhalb der Mindestgröße werden Hits in Blöcken von 128 Tokens quantisiert. Wir beobachteten 4,096, 8,320, 12,544 und 16,768. Der gecachte Anteil des vorbereiteten Präfixes lag jedoch nur zwischen 51% und 96%. Bei einem langen Präfix sollte man daher mit einem Rabatt für den Großteil kalkulieren, nicht für den gesamten Inhalt.

Fällt bei strukturiertem Output und Tool Calls der Reasoning-Aufschlag an?

Standardmäßig ja. Gleichzeitig lässt er sich dort am sichersten vermeiden. Strikter json_schema-Output funktioniert und wird tatsächlich durchgesetzt: Dieselbe Extraktion ohne Schema kam in Markdown-Codeblöcken zurück. Mit der Standardeinstellung verbrauchte die Extraktion von vier Rechnungsfeldern 252 Reasoning-Tokens, bevor 57 Tokens JSON ausgegeben wurden. Mit reasoning_effort: "none" entstand korrektes, valides JSON mit insgesamt 54 Tokens, eine Reduktion um den Faktor 5.7x. thinking_budget: 16 lag dazwischen. Bei der Tool-Auswahl zeigte sich dasselbe Verhalten: Ohne Thinking rief das Modell mit einem Drittel der Standard-Tokenmenge die richtige Funktion auf. Einstufige Extraktion und Routing sind genau die Anwendungsfälle, in denen das Abschalten sicher ist. Bei $6/1M Output summiert sich diese Einsparung schnell.

Für Agent-Entwickler ist noch ein Abrechnungsdetail wichtig: Die API gibt die vollständige Gedankenkette in reasoning_content zurück. Laut Dokumentation müssen Multi-Turn-Clients sie unverändert mitsenden. Erzwungen wird das nicht. Wir haben Turns mit vollständigem, fehlendem und absichtlich manipuliertem Reasoning erneut gesendet. Alle drei Varianten wurden akzeptiert, ohne Auswirkungen auf die Genauigkeit kurzer Reasoning-Ketten. Erneut gesendetes Reasoning wird als normaler Input abgerechnet. Bei Multi-Turn-Traffic spart das Weglassen daher tatsächlich Geld, solange die eigenen Evals keinen Qualitätsverlust zeigen.

Was wurde von Qwen 3.7 übernommen, und was hat sich geändert?

Der Tokenizer ist unverändert, bestehende Token-Budgets lassen sich direkt übernehmen. Identische englische, chinesische und japanische Texte sowie Code-Korpora ergaben bei qwen3.8-max, qwen3.7-max, qwen3.7-plus, qwen3.6-flash und qwen3.5-flash identische Tokenzahlen. Die sprachabhängige Kostenplanung aus unserer Tokenizer-Studie nach Sprache gilt daher unverändert.

Zwei Punkte haben sich geändert. Erstens hat 3.8-max einen festen Prompt-Overhead, den die anderen Modelle nicht aufweisen: Dieselbe Nachricht mit nur einem Zeichen zählte bei 3.8-max als 49 Prompt-Tokens, bei allen anderen getesteten Qwen-Modellen als 11. Das entspricht einem festen Aufschlag von +38 Tokens pro Call. Bei langen Prompts ist das vernachlässigbar, bei kurzen und häufigen Requests dagegen messbar. Zweitens ist Thinking immer verfügbar und kein separater Modus mehr. Dafür gibt es den oben beschriebenen Regler mit sieben Stufen und den exakten Budgetparameter; die Optionen von 3.7 waren gröber. Zur Einordnung der Preise, da während der Preview zwei Modelle kursierten: Die Token-Plan-Abos für $6 bis $68 pro Monat mit hohen Rabatten außerhalb der Spitzenzeiten gelten für Alibabas eigene Apps, nicht für die API. Über die API gilt der Listenpreis von $2/$6. Unser Gateway-Zähler stimmte während der gesamten Studie bei jedem Call bis auf die vierte Dezimalstelle damit überein.

FAQ

Kann Thinking bei Qwen 3.8 Max abgeschaltet werden?

Ja, vollständig: reasoning_effort: "none" oder enable_thinking: false eliminiert sämtliche Reasoning-Tokens. Verwenden Sie diese Einstellung nur für Aufgaben mit einem einzigen Schritt. Bei zweistufiger Arithmetik erreichte sie in unserem Batch 1/6, während ein thinking_budget von 16 Tokens bei vergleichbarem oder geringerem Tokenverbrauch 6/6 erzielte. Für mehrstufigen Traffic sollte die kleinste Einstellung daher ein kleines Budget sein, nicht das vollständige Abschalten.

Wie groß muss ein Prompt für den Cache von Qwen 3.8 Max mindestens sein?

In unseren Tests etwa 4,300 Tokens: Ein Prompt mit 4,221 Tokens führte nie zu einem Hit, einer mit 4,360 Tokens dagegen schon. Erste Hits umfassen immer exakt 4,096 Tokens. Unterhalb dieser Grenze gibt es keinen Rabatt. Oberhalb davon kosten Reads $0.25/1M ohne Aufschlag für Writes, und der Eintrag ist bereits 0.3 Sekunden nach dem Priming lesbar.

Unterstützt Qwen 3.8 Max reasoning_effort?

Sieben Werte werden akzeptiert: none, minimal, low, medium, high, xhigh und max. Die Stufen verhalten sich jedoch wie Limits für das Thinking-Budget und unterscheiden sich erst, wenn eine Aufgabe das jeweilige Limit überschreitet. Für deterministische Kontrolle sollte thinking_budget direkt gesetzt werden. Es wird token-genau durchgesetzt, lehnt 0 ab und reicht bis 262,144. Client-Tools sind sich derzeit uneinig, welche Stufen existieren. Die obige Liste entspricht den Werten, die die API am ersten Tag akzeptiert hat.

Muss reasoning_content bei Multi-Turn-Unterhaltungen zurückgesendet werden?

Laut Dokumentation ja, von der API geprüft wird es nicht. In unseren Tests wurden fehlende und sogar manipulierte Reasoning-Verläufe ohne Fehler und ohne Genauigkeitsverlust bei kurzen Reasoning-Ketten akzeptiert. Erneut gesendetes Reasoning wird als normaler Input abgerechnet. Das Weglassen ist daher ein legitimer Kostenhebel, solange die eigenen Evals bei langen Ketten keinen Qualitätsverlust zeigen.

Gemessen am 2026-08-03 über das Synthorai-Gateway mit qwen3.8-max und Vergleichsläufen auf qwen3.7-max, qwen3.7-plus, qwen3.6-flash und qwen3.5-flash: Tests zu akzeptierten Reglerwerten, ungültigen Werten und den Grenzen von max_tokens; eine komplexe Aufgabe mit natürlichem Verbrauch von 45K Tokens zum Erreichen der Effort-Limits; ein festes reproduzierbares Batch für den Genauigkeitseinbruch mit n=4-6 pro Variante und Salt; gesalzene Cache-Paare im Abstand von 2-3s sowie gestaffelte Zeitabstände; Needle- und Overflow-Tests mit 161K-919K Tokens; identische Tokenizer-Zählungen auf vier Korpora. Die Dollarbeträge stammen aus den abgerechneten Kosten des Gateway-Zählers zu Listenpreisen von $2/$6 pro 1M. Rabatte, Preise und Verhalten während der Preview können sich ändern; gleichen Sie die Angaben mit Ihren eigenen Nutzungsdaten ab.

← Zurück zum Blog