Claude Sonnet 4.6

Claude Sonnet 4.6 (claude-sonnet-4-6) ist der Sonnet-Snapshot, der die 200k-Kontextgrenze durchbrochen hat. Eine Million Token Kontextfenster. Text- und Vision-Eingabe. Das Mid-Tier-Modell, das erstmals in der Claude-Familie sehr lange Eingaben zu einer vernünftigen Wahl machte, ohne für die Opus-Stufe zu zahlen.

Die treffendste Beschreibung: Sonnet 4.6 ist das Modell, nach dem man greift, wenn man Sonnet-typische Zuverlässigkeit und Ablehnungshaltung will, aber einen Workload hat, der nicht in 200k Token passt. Das ist eine engere Bandbreite von Anwendungsfällen als die allgemeine Sonnet-Linie — aber eine Bandbreite, für die es vor diesem Snapshot keine gute Antwort gab.

Was das Million-Token-Fenster wirklich bringt

Eine Million Token reichen für einen vollständigen Quartalsbericht, ein mittelgroßes Monorepo oder einen mehrmonatigen Chat-Thread. Die Marketing-Aussage ist real. Die praktische Frage ist dieselbe wie bei jedem Long-Context-Modell: hält die Aufmerksamkeitsqualität über den gesamten Puffer stand, oder verliert das Modell den Faden zu Anfang platzierten Fakten, wenn das Ende voll ist.

Sonnet 4.6 hält die Aufmerksamkeit gut über die 200k-Marke hinaus, an der der Rest der Sonnet-Linie stößt. Jenseits von etwa 600.000 Token dehnt sich die Latenz aus, und Streaming-Token-pro-Sekunde sinkt. Detaillierte Zahlen ändern sich jede Iteration; das aktuelle Bild finden Sie auf /benchmarks/speed.

Zwei praktische Konsequenzen: Erstens ist das lange Fenster für dokumentübergreifende Sorgfaltsprüfung, vollständige Repo-Code-Reviews und lange Konversations-Threads wirklich nutzbar — keine bloße Spezifikationszahl für eine Präsentation. Zweitens sollte man dennoch über Prompt-Caching für wiederholte Abfragen gegen dasselbe große Korpus nachdenken. 800.000 Token Kontext bei jedem Aufruf neu zu laden ist zeitaufwendig, selbst wenn der API-Aufruf selbst sauber gelingt.

Vergleich mit Opus 4.7 bei langen Kontexten

Sowohl Sonnet 4.6 als auch Opus 4.7 bringen Million-Token-Fenster mit. Der Unterschied ist, was man erwarten würde:

• Opus 4.7 ist sorgfältiger, vorsichtiger und reasont längere interne Schritte durch, bevor es antwortet.
• Sonnet 4.6 ist bei gleicher Eingabe schneller und produziert Antworten näher an der ersten plausiblen Interpretation, ohne Alternativen durchzuarbeiten.
• Bei reinem Retrieval — „Finde diese Tatsache in diesem 800k-Token-Dokument" — liegen die beiden nah beieinander. Bei der Synthese über viele verstreute Fakten gewinnt Opus in der Regel.
• Für kostensensitive Long-Context-Workloads, bei denen Top-of-Stack-Reasoning nicht spezifisch benötigt wird, ist Sonnet 4.6 die richtige Wahl.

Testen Sie beide mit eigenen Prompts. Die Deltas bei realen Workloads entsprechen selten den öffentlichen Benchmark-Lücken.

Vision-Eingabe, die ihr Gewicht trägt

Sonnet 4.6 behält den Vision-Stack der 4.x-Linie. Dokument-Screenshots, gescannte PDFs als Seitenbilder, Dashboard-Aufnahmen, Diagramme. Tabellenextraktion ist sauber. Diagramme mit vernünftigen Beschriftungsgrößen werden korrekt beschrieben.

Dieselben Schwachstellen wie im Rest der Claude-Familie. Handschrift ist unbeständig. Dichte wissenschaftliche Abbildungen mit winzigen Achsenbeschriftungen werden teilweise falsch gelesen. Alles, bei dem ein Mensch hineinzoomen müsste, profitiert von einem Verifikationsschritt.

Für Workloads, die Vision-Eingabe mit dem langen Kontextfenster kombinieren — etwa ein gesamtes PDF als Seitenbilder zusammen mit strukturierten Metadaten — ist Sonnet 4.6 eine der fähigeren Optionen im Feld. Gemini 3 Pro Preview konkurriert hier auf etwa gleichem Niveau.

Einordnung in die Modelllandschaft

Das ehrliche Wettbewerbsbild für Sonnet 4.6:

Gegenüber Opus 4.7: Sonnet 4.6 ist schneller und günstiger zu betreiben, Opus 4.7 reasont bei komplexen Aufgaben sorgfältiger. Für Workloads, bei denen das Modell Fakten aus einer langen Eingabe ziehen und zusammenfassen soll, ist Sonnet meist ausreichend. Für Workloads mit mehrstufigem Reasoning über eine lange Eingabe ist Opus die bessere Wahl.

Gegenüber Gemini 2.5 Pro und GPT-5-Mid-Tier: Sonnet 4.6 gewinnt bei Ablehnungskonsistenz und europäischsprachiger Verwaltungsprosa. Gemini gewinnt bei nativer Multimodalität über Bilder hinaus. GPT-5-Mid-Tier gewinnt bei reiner Geschwindigkeit für kurze Gesprächsrunden.

Das Kategorie-Bild finden Sie auf /benchmarks/leaderboard und /benchmarks/intelligence.

Wann es das falsche Werkzeug ist

Workloads, bei denen 200k Token ausreichen. Sonnet 4.5 ist günstiger zu betreiben und verhält sich innerhalb seines Fensters ähnlich. Die Million-Token-Fähigkeit kostet etwas an Latenz und operationeller Komplexität, das man nicht zahlen sollte, wenn man es nicht braucht.

Echtzeit-Sprache. Keine Audio-Eingabe. Den Voice-Pipeline-Leitfaden finden Sie auf /usecases/voice.

Hochvolumige günstige Klassifizierung. Mid-Tier-Rechenleistung auf long-context-fähigen Modellen ist der falsche Aufwand für Millionen kurzer Prompts. Claude Haiku 4.5 oder eine der kleineren Gemini-Flash-Varianten erledigt das für eine andere Kostenstufe.

Code-Generierung unter sich schnell entwickelnden Frameworks. Konservativer Output-Stil. Für IDE-passendes Arbeiten deckt die Übersicht auf /usecases/code die Alternativen ab.

Self-Hosted-Deployment oder Fine-Tuning. Anthropic liefert keine Gewichte. Die Open-Weight-Übersicht auf /usecases/local ist der richtige Ausgangspunkt, wenn diese Anforderungen gelten.

Deployment-Hinweise

Standard-Anthropic-API. REST. Streaming. System-Prompts verhalten sich vorhersagbar. Tool-Use ist zuverlässig genug, um Produktionsagenten darauf aufzubauen.

EU-Datenresidenz bleibt der wiederkehrende Streitpunkt. Anthropics Inferenz läuft auf AWS und Google Cloud, und die öffentliche API bietet für kein Claude-Modell einen Regionsauswahlparameter. Ohne Enterprise-Vertrag ist ein ausschließlich EU-basierter Inferenzpfad nicht garantiert. Enterprise-Verträge können Residenzklauseln aushandeln. Bei strikten Residenzanforderungen sind die Open-Weight-Optionen auf /usecases/local der richtige Ausgangspunkt.

Logs werden standardmäßig 30 Tage für die Missbrauchsüberwachung aufbewahrt. Eingaben werden nicht für das Training verwendet, sofern Sie dem nicht zustimmen. Zero-Retention ist eine Vertragsverhandlung, kein Einstellungsschalter.

Wann Sie es einsetzen sollten

Greifen Sie zu Claude Sonnet 4.6, wenn:

• Der Workload regelmäßig 200k Token Eingabe überschreitet.
• Sie Sonnet-typische Geschwindigkeit und Ablehnungshaltung wollen, nicht Opus-Tier-Reasoning-Tiefe.
• Sie dokumentübergreifende Sorgfaltsprüfung, vollständige Repo-Code-Reviews oder andere Aufgaben durchführen, bei denen das lange Fenster sich bezahlt macht.
• Europäischsprachige Verwaltungs- oder Rechtstexte Teil der Eingabe sind.

Wählen Sie etwas anderes, wenn:

• Der Workload komfortabel in 200k Token passt. Verwenden Sie Sonnet 4.5.
• Sie Top-of-Stack-Reasoning über die lange Eingabe brauchen. Wechseln Sie zu Opus 4.7.
• Sie Sub-Cent-Kosten pro Aufruf bei kurzen Prompts benötigen. Wechseln Sie nach unten zu Haiku.
• Audio, Sprache oder Video Teil des Workloads ist.

Zusammenfassung: Sonnet 4.6 ist die richtige Antwort für Long-Context-Mid-Tier-Workloads. Es ist nicht die richtige Antwort für alles — und das ist in Ordnung. Für seine spezifische Bandbreite gehört es zu den stärksten Modellen auf dem Markt.

Testen Sie es mit einem eigenen Long-Context-Prompt unter /live-test. Der Unterschied zwischen Modellen ist am deutlichsten, wenn die Eingabe groß genug ist, um sie zu belasten.

Letzte technische Überprüfung: 2026-05-22 — Tokonomix.ai