Qwen3.6-Max-Preview: Next-Generation-Modell mit verbessertem agentischem Coding und stärkerem Weltwissen

• Als Nachfolger von Qwen3.6-Plus verbessert es gegenüber dem Vorgänger deutlich das agentische Coding sowie Weltwissen und Befolgung von Anweisungen
• Erreicht in 6 wichtigen Coding-Benchmarks die Bestwerte und bestätigt damit eine starke Verbesserung der Leistung als Coding-Agent
• Unterstützt die Funktion preserve_thinking, die bei agentischen Aufgaben den Denkprozess aus vorherigen Turns in den Nachrichten bewahrt
• Bei Benchmarks zum Weltwissen wurden unter anderem SuperGPQA um +2,3 und QwenChineseBench um +5,3 verbessert, bei der Befolgung von Anweisungen wurde bei ToolcallFormatIFBench +2,8 erreicht
• Interaktive Tests sind in Qwen Studio möglich; über die API von Alibaba Cloud Model Studio soll es als qwen3.6-max-preview aufrufbar sein

---

Wichtige Verbesserungen

• Gegenüber Qwen3.6-Plus wurden die Fähigkeiten im agentischen Coding stark verbessert: SkillsBench +9.9, SciCode +6.3, NL2Repo +5.0, Terminal-Bench 2.0 +3.8
• Weltwissen (world knowledge) gestärkt: SuperGPQA +2.3, QwenChineseBench +5.3
• Befolgung von Anweisungen (instruction following) verbessert: ToolcallFormatIFBench +2.8
• Bestwerte in 6 wichtigen Coding-Benchmarks erreicht: SWE-bench Pro, Terminal-Bench 2.0, SkillsBench, QwenClawBench, QwenWebBench, SciCode

Modellmerkmale und Ansatz

• Ein exklusiv gehostetes Modell, das über Alibaba Cloud Model Studio bereitgestellt wird
• Verbesserte Leistung bei realen Agenten (real-world agent) und Wissenszuverlässigkeit (knowledge reliability)
• Kann in Qwen Studio sofort interaktiv getestet werden
• Der API-Modellname ist qwen3.6-max-preview und wird bald in der Alibaba Cloud Model Studio API verfügbar sein

API-Nutzung und Funktionen

• Unterstützt branchenübliche Standardprotokolle wie OpenAI-kompatible chat completions und responses API sowie Anthropic-kompatible Schnittstellen
• Mit der Funktion preserve_thinking kann der Reasoning-Prozess (reasoning content) aus vorherigen Turns erhalten bleiben; für agentische Aufgaben empfohlen
• Bei Einstellung von enable_thinking: True können Reasoning-Inhalte und Antwort getrennt per Streaming empfangen werden
• Base-URLs der API nach Regionen verfügbar: Peking, Singapur, USA (Virginia)

Entwicklungsstatus

• Derzeit in der Phase eines Preview Release, wird laufend iterativ verbessert; weitere Verbesserungen sind in späteren Versionen geplant

[GN⁺]

Hacker-News-Kommentare

• Ich finde es etwas lustig, wie sehr sich Leute nur auf SOTA-Vergleiche versteifen. Ich habe Fälle gesehen, in denen glm 5.1 Dinge geschafft hat, die Opus nicht konnte, und ich habe auch erlebt, dass es besseren Code geschrieben hat. qwen max habe ich noch nicht ausprobiert, aber ich habe auch gesehen, wie ein lokales 122b-Modell Dokumente besser gelesen und präziser verarbeitet hat. Benchmarks sind am Ende nur ein Teil des Bildes, und in der Praxis hat jedes Modell andere Stärken. Man sollte also nicht so darüber reden, als würde man Hammer und Schraubenschlüssel einfach nur nach Über- oder Unterlegenheit vergleichen

  • Ich nutze GLM-5.1 in einem privaten Projekt über pi.dev von Ollama Cloud und bin ziemlich zufrieden. Im Unternehmen verwenden wir pi.dev zusammen mit Claude Sonnet und Opus 4.6. Claude Code ist auch gut, aber seit dem letzten Update musste ich zu oft compact ausführen, was lästig war. Bei pi.dev hat mir MCP tool calling nicht gefehlt, weil die API-Integration gut funktioniert hat. Im Gegenteil, beim Erstellen von Websites hatte ich sogar den Eindruck, dass GLM-5.1 besser ist als Claude Opus, und auch auf der Full-Stack-Entwicklungsplattform, die ich gerade baue, liefert es sehr gute Ergebnisse
  • GLM 5.1 war für mich das erste Modell, bei dem ich wirklich das Gefühl hatte, dass chinesische Modelle aufgeholt haben. Deshalb habe ich sogar mein Claude-Max-Abo gekündigt, und ehrlich gesagt vermisse ich es überhaupt nicht. Wenn die Meinungen inzwischen so auseinandergehen, sind wir wohl an einem Punkt angekommen, an dem weniger die absolute SOTA-Überlegenheit zählt als vielmehr Domäne und Nutzungsmuster
  • Der fast einzige Grund, warum ich weiter Claude und ChatGPT nutze, ist tool calling. Dazu kommen nützliche Funktionen wie skills. Ich habe auch qwen und deepseek ausprobiert, aber manchmal konnten sie nicht einmal ordentlich Dokumente ausgeben. Mich würde interessieren, wie andere mit solchen Tools Dokumente oder Excel verarbeiten, und wenn es gut klappt, würde ich auch gern wechseln
  • Vor ein paar Monaten hat Qwen3-Coder deutlich besseren Rust-Code erzeugt als Claude Opus oder Google Gemini. Besonders beeindruckt hat mich, dass es sogar Code mit Rust-x86-64-Vektorerweiterungen ausgegeben hat. Ich habe es über Harnesses wie den Zed editor oder die trae CLI aufgerufen, und das hat mich wirklich sehr überrascht
  • Die Benchmark-Werte der Modelle liegen insgesamt ziemlich nah beieinander, und die Unterschiede sind klein. In so einer Situation halte ich es für vernünftig, nach anderen Kriterien auszuwählen. In meinem Fall würde ich sofort zu jedem Anbieter wechseln, sobald es ein brauchbares JetBrains-Plugin gibt

• Ich nutze im Unternehmen seit einigen Monaten regelmäßig Claude Code und habe es vor Kurzem auch gut für ein kleines privates Website-Projekt eingesetzt. Letztes Wochenende habe ich zum ersten Mal auch Self-Hosting ausprobiert. Mich würde interessieren, ob jemand nach ausreichend Erfahrung mit CC oder Codex eine halbwegs zufriedenstellende Self-Hosting-Konfiguration gefunden hat. Ich habe mit 32GB DDR5, AMD 7800X3D, RTX 4090 sowie Windows- und WSL-Umgebung verschiedene Kombinationen aus ollama, docker desktop model runner, pi-coding-agent, opencode und Gemma 4, Qwen, GLM-5.1 getestet. Da der Grundverbrauch an RAM schon hoch war, konnte ich gute Modelle wie Gemma4-31B nicht ausführen. Unter reinem Windows gab es oft Probleme mit der Dateipfadbehandlung, und die Variante, pi oder opencode unter WSL laufen zu lassen und das Modell über docker desktop zu betreiben, hat einigermaßen funktioniert. Die gefühlte Leistung war im Vergleich zu CC aber viel zu langsam, und auch die Tool-Reife wirkte bei der CC-Harness-Seite deutlich besser. Ich habe so viel Zeit in das Setup gesteckt, dass ich es am Ende nicht lange praktisch nutzen konnte, aber es war trotzdem ein interessantes Experiment

  • Es wäre gut, einmal ein MoE-Modell auszuprobieren und Inferenz auf die CPU auszulagern. Beispiele wären Gemma 4 26b-a4b oder qwen3.6 35b-a3b. 32GB RAM sind mit anderen laufenden Apps zwar etwas knapp, aber wenn genug System-RAM vorhanden ist, läuft es ziemlich gut. Man kann auch einige Layer auf die GPU legen, aber bei der Kombination aus MoE-Modellen und llama.cpp gab es Probleme. Wenn man stattdessen den KV cache auf der GPU hält, bekommt man recht gute Geschwindigkeit und kann trotzdem ein brauchbares Kontextfenster beibehalten. Ich habe lokal sehr beeindruckende Ergebnisse gesehen. Ich würde außerdem dringend empfehlen, llama.cpp direkt unter WSL2 zu klonen und ein Frontier-Modell wie Claude Code Installation und Tuning übernehmen zu lassen. Apps auf Basis von llama.cpp legen nicht alle Optionen und Flags offen, und schon ein einziges falsches Flag kann die Leistung stark ruinieren, etwa wenn dadurch kein Kontext-Cache funktioniert. Wenn man direkt aus dem Source baut, kann man bei Problemen sofort den tatsächlichen Code prüfen. Mit dieser Maschine sollten bei Gemma 4 mindestens 20–40tok/s drin sein, also genug für den praktischen Einsatz, und qwen3.6 könnte wegen der 3b aktiven Parameter noch schneller sein
  • Das Problem, das du gerade hast, hängt wahrscheinlich damit zusammen, dass wegen VRAM-Mangel nicht das ganze Modell auf einmal geladen werden kann. llmfit wäre vielleicht ebenfalls einen Versuch wert

• Ich mache mir Sorgen, dass sich dieses Feld in die Richtung bewegt, erst kostenlose Angebote herauszugeben, um sich einen Namen zu machen, und später alles proprietary zu machen. Trotzdem hoffe ich, dass es weiterhin Open Weights gibt. Der Tag, an dem niemand mehr Open Weights veröffentlicht, wäre wirklich bitter. In so einer Welt würde es für normale Menschen wahrscheinlich noch schwieriger werden, ihre eigene compute direkt zu besitzen

  • Das ist meiner Meinung nach eine zu starke Verallgemeinerung. Viele US-Modelle waren von Anfang an geschlossen, während Modelle außerhalb der USA, besonders chinesische Modelle, anfangs deutlich offener waren. Teilweise war es dort sogar umgekehrt: erst proprietary, später offen. So etwas gab es auch bei einigen größeren Qwen-Modellen
  • Für mich wirkt das wie eine Bewegung auf Ebene der nationalen Strategie. Es sieht so aus, als wolle man durch die fortlaufende Veröffentlichung konkurrenzfähiger kostenloser Modelle den moat schwächen, den westliche Unternehmen mit proprietären Modellen aufbauen wollen. Solange dieses für China vorteilhafte Narrativ bestehen bleibt, halte ich eine vollständige Rückkehr zu proprietary für eher unwahrscheinlich
  • Auch aus Sicht der Chip-Hersteller dürfte es in ihrem Interesse sein, dass die Möglichkeit erhalten bleibt, lokale Modelle auszuführen
  • Genau. Für chinesische Forschungslabore ist Open Source meiner Ansicht nach eine Art Geschäftsstrategie. Ihnen fehlen andere wirksame Marketingmittel, um Modelle und Inferenzdienste bekannt zu machen, daher wählen sie diesen Weg. Dieser Beitrag ist dazu ebenfalls lesenswert
  • Für mich war die Struktur schon immer ähnlich. Im Grunde ist das auch SaaS, mit dem Unterschied, dass das niedrigste Abo moderner Frontier-Labs heute fast wie eine kostenlose Testversion wirkt

• Heute ist auch Kimi K2.6 erschienen, daher finde ich einen Vergleich der beiden ziemlich naheliegend. Schon beim Preis wirkt Qwen teurer: 1,3 Dollar für Input und 7,8 Dollar für Output, während Kimi bei 0,95 Dollar für Input und 4 Dollar für Output liegt. Im Ankündigungsbeitrag überschneiden sich außerdem nur zwei Benchmarks, und sowohl bei SWE-Bench Pro als auch bei Terminal-Bench 2.0 lag Kimi leicht vor Qwen. Natürlich hat jedes Modell andere Stärken und Benchmarks sind nicht alles, aber rein nach den Zahlen wirkt Kimi attraktiver

  • Ich habe den Eindruck, dass chinesische Modelle mit den steigenden Preisen etwas an Reiz verloren haben. Und seit Gemma-4 erschienen ist, bleiben meiner Meinung nach nicht mehr viele Modelle auf der Pareto-Front. Das entspricht auch meinem subjektiven Eindruck, und die Statistiken des Arena-Leaderboards sind ebenfalls einen Blick wert

• Die Ironie dieser Ankündigung steckt für mich schon im Namen selbst. Max-Preview ist proprietary und nur in der Cloud verfügbar. Für mich ist das wirklich wichtige Qwen die Serie mit Open Weights, die Leute auf ihrer eigenen Hardware ausführen. Ich betreibe 32B und 72B lokal auf zwei A4000. Es gibt zwar noch eine Lücke zu gehostetem Max, aber man sieht, wie sie mit jeder Veröffentlichung kleiner wird. Deshalb ist die wirklich spannende Frage nicht, wie Max im Vergleich zu Opus abschneidet, sondern ab wann das Open-Weight-Tier für die meisten Workloads das Cloud-Tier praktisch bedeutungslos macht

• Während alle nur SOTA hinterherjagen, erledige ich meine gesamte Coding-Arbeit mit MiniMax M2.5 für 10 Dollar im Monat, indem ich mehrere parallele Sessions laufen lasse, und stoße dabei fast nie an Limits

  • Wenn es um ernsthafte Arbeit geht, ist der Unterschied zwischen 10 und 100 Dollar im Monat für die meisten professionellen Entwickler kaum der Rede wert. Es gibt Ausnahmen wie Studierende oder Nutzer in Ländern mit niedrigem Einkommen, aber ich finde es immer merkwürdig, wenn gut bezahlte Entwickler bei den Tool-Kosten übermäßig sparen. Selbst die heutigen SOTA-Modelle halte ich für mehr als nur einmalige Aufgaben noch nicht für vollständig zuverlässig, und dann zusätzlich ein schwächeres Modell überwachen zu müssen, nur um 10 bis 100 Dollar im Monat zu sparen, ist für mich überhaupt nicht attraktiv. Bei self-hosted Modellen experimentiere ich gern für leichte, entbehrliche Aufgaben, aber bei wirklich wichtiger Arbeit möchte ich meine Zeit nicht verschwenden
  • Mich würde interessieren, wofür genau diese 10 Dollar bezahlt werden. Ich würde gern fragen, ob es OpenRouter ist
  • Mich würde interessieren, wie das praktisch genutzt wird. Verwendest du opencode oder ein anderes Frontend?

• Ich habe mir auch Qwens Dokumentation zum Context Caching angesehen und Opus, Codex und Qwen gemeinsam getestet. Dabei hatte ich schon den Eindruck, dass Qwen bei vielen Coding-Aufgaben stark ist. Worauf ich am meisten achte, ist aber das Verhalten in langen Sessions. Qwen wirbt zwar mit großen Kontextfenstern, aber die tatsächliche Effizienz bei langem Kontext scheint stark von der Art des Context Caching abzuhängen. Laut offizieller Dokumentation werden sowohl implizites als auch explizites Caching unterstützt, aber die TTL liegt nur bei wenigen Minuten, und es gibt Einschränkungen wie prefix-basiertes Matching und Mindestanzahl an Tokens. Wegen dieser Einschränkungen könnte die Cache-Wiederverwendung in Workflows, bei denen der Kontext ständig wächst, etwa bei Coding-Agenten, deutlich schlechter funktionieren als erwartet. Deshalb mögen die Kosten pro Token niedrig aussehen, aber in langen Sessions kann die cache hit rate sinken und die Neuberechnung zunehmen, wodurch sich die tatsächlichen Kosten höher anfühlen. Trotzdem war Qwen bei sicherheitsbezogenen Aufgaben meiner persönlichen Erfahrung nach teilweise besser als Opus. Für kürzere Aufgaben auf Ebene einzelner Methoden oder Funktionen ist Qwen nach meiner Erfahrung viel besser als Opus, aber insgesamt wirkt es für mich eher wie ein Generator auf Funktionsebene als wie ein autonomer End-to-End-Coding-Assistent à la Claude

  • Trotzdem halte ich es für best practice, lange Sessions kurz zu halten und neu zu starten. In den Claude Code Best Practices von Anthropic steht ebenfalls: „Eine saubere neue Session mit besserem Prompt ist fast immer besser als eine lange Session, in der sich Änderungen angesammelt haben.“
  • Soweit ich zuletzt geprüft habe, senkt context caching nur Kosten und Latenz, verändert aber nicht, welche Tokens tatsächlich ausgegeben werden

• Wenn ich sehe, dass Qwen sich mit Opus 4.5 vergleicht, fällt es mir schwer, das ganz wohlwollend zu sehen. Ich verstehe zwar, dass Opus 4.7 als ganz neues Modell fehlt, aber Opus 4.6 gibt es nun schon seit einiger Zeit

  • Für mich war Opus 4.5 der erste Punkt, an dem ich bei vielen Problemen dachte, das Modell sei gut genug. Davor hat mich der Einsatz von KI bei Entwicklungsarbeit wegen Halluzinationen am Ende eher Zeit gekostet und war keine produktive Wahl. Aber selbst wenn die Entwicklung bei Opus 4.5 stehen geblieben wäre, hätten wir schon damals unglaublich viele reale Aufgaben sehr schnell erledigen können. Ich glaube nicht, dass Softwareentwicklung jemals wieder komplett zu reinem Hand-Coding zurückkehrt. Wenn also etwas auf dem Niveau von Opus 4.5 oder leicht darüber zu einem Zehntel des Preises angeboten wird, kann das für viele Menschen sehr attraktiv sein. Natürlich ist es für westliche Entwickler auch sehr wertvoll, mehr als 100 Dollar im Monat für Opus 4.7 zu zahlen, weil die Zeit, die schwächere Modelle verschwenden, viel teurer ist. Ich werde daher wohl noch eine Weile bereit sein, einen Aufpreis für Modelle zu zahlen, die weniger Zeit verschwenden und mit weniger Prompt-Korrekturen bessere Ergebnisse liefern. Gleichzeitig ist das Tempo der Veränderungen wirklich erstaunlich, und inzwischen sind selbst offene Modelle auf einem Niveau angekommen, das mit Frontier-Modellen von vor zwei Jahren konkurrieren kann. Qwen 3.6 MoE 35B A3B oder große Gemma-4-Modelle lassen sich auf normaler Hardware wie leistungsstarken Macbooks, Strix Halo oder aktuellen GPUs mit 24GB oder 32GB betreiben und kosten nicht einmal viel mehr als Entwickler-Laptops aus der Zeit vor der KI. Sie schreiben Code, verfassen ziemlich gute Texte, nutzen Tools und bieten genügend Kontextlänge für reale Arbeit. An Opus 4.5 reichen sie noch nicht ganz heran, aber es ist schon sehr beeindruckend. Ich selbst mische für Sicherheit und Code-Reviews bereits mehrere Modelle, und auch wenn für die meiste Softwareentwicklung Claude Code und Opus für mich noch immer am besten sind, bin ich durchaus bereit, Qwen zu verwenden. Auch die kleineren Modelle sind gemessen an ihrer Größe sehr gut, daher sind meine Erwartungen an die großen Modelle entsprechend hoch
  • Wenn Geld wirklich gar keine Rolle spielt, reicht es am Ende wahrscheinlich, einfach nur auf maximale Leistung wie bei Codex 5.4 oder Opus 4.7 zu schauen. Für viele Menschen ist aber das Verhältnis von Kosten zu Qualität ein sehr wichtiger Faktor. Selbst unter Claude-Abonnenten können viele Opus 4.7 wegen Kosten- und Nutzungslimits nicht ständig verwenden und greifen stattdessen zu Sonnet oder älteren Opus-Versionen. Wenn man also die Kurve von Qualität zu Wert betrachtet, ist so ein Vergleich durchaus sinnvoll
  • In den letzten Monaten war die Leistung von Opus 4.6 für mich zu schwankend, deshalb wollte ich nicht unnötig Tokens verschwenden
  • Als Sonnet 4.6 erschien, habe ich mein Standardmodell von Opus auf Sonnet umgestellt. Für mein Empfinden lag Sonnet 4.6 ungefähr auf Opus-4.5-Niveau. 4.6 und 4.7 sind zwar besser, aber bei den meisten Aufgaben ist der Sprung nicht groß genug, sodass Kosteneinsparung inzwischen eine völlig vernünftige Entscheidung ist. Wenn günstigere Modelle dieses Niveau erreichen, ist das umso bedeutender, und GLM 5.1 wirkt ebenfalls schon ziemlich nah dran, weshalb ich es oft nutze. Aus dieser Perspektive finde ich auch einen Vergleich mit Opus 4.5 gerechtfertigt
  • Vergleiche sollte man mit den ähnlichsten Gegenstücken anstellen. Und wenn Benchmarks direkt vom Anbieter veröffentlicht werden, ist es selbstverständlich möglich, dass genau die Frameworks ausgewählt werden, in denen das eigene Modell gut abschneidet, während ungünstige weggelassen werden. Deshalb halte ich am Ende unabhängige Benchmarks für das Einzige, worauf man sich wirklich verlassen kann

• Bei chinesischen Anbietern in letzter Zeit erkenne ich ein Muster. Erstens scheinen sie dazu überzugehen, Modelle closed source zu halten, und zweitens erhöhen sie die Preise ziemlich deutlich. Manchmal sind das fast 100 Prozent

  • Es klingt etwas seltsam, so zu tun, als wäre das eine Besonderheit chinesischer Unternehmen. Ich habe nicht den Eindruck, dass Firmen aus anderen Ländern sich grundsätzlich anders verhalten
  • Qwen max war von Anfang an cloud only, und bei einem Modell mit über 1T Parametern sind hohe Kosten kaum vermeidbar
  • Ich würde zurückfragen, was daran anders sein soll als bei US-Anbietern, wenn Preise stark erhöht werden
  • Ich würde fragen, ob das auch auf Modelle wie GLM 5.1, DeepSeek V3.2 oder das gerade erschienene Kimi K2.6 zutrifft. Auf solche Beispiele scheint das nämlich nicht besonders gut zu passen
  • Diese Vorgehensweise mögen US-Unternehmen doch ebenfalls ausgesprochen gern

• Interessant ist, dass man die gesamte lokal ausführbare Qwen-Modellfamilie kennen kann und über die Cloud-Modelle trotzdem praktisch nichts weiß. Ich kannte nur die 3.5-Reihen und vielleicht ein 3.6-Modell, und den Namen Plus habe ich jetzt zum ersten Mal gehört

  • Wenn ich mich richtig erinnere, gibt es die Plus-Serie schon seit der Veröffentlichung von Qwen chat. Ich meine, ich hätte spätestens Anfang letzten Jahres selbst ein Plus-Modell verwendet