Claude Sonnet 4 unterstützt jetzt 1 Million Token Kontext

 (anthropic.com)
2 Punkte von GN⁺ 2025-08-13 | 1 Kommentare | Auf WhatsApp teilen
  • Claude Sonnet 4 von Anthropic bietet jetzt einen Kontext von bis zu 1 Million Token und kann damit große Codebasen oder zahlreiche Dokumente auf einmal verarbeiten
  • Durch die verbesserte Kontextunterstützung sind vielfältige Einsatzmöglichkeiten möglich, darunter Analyse großer Codebasen, Verarbeitung umfangreicher Dokumentensammlungen und die Entwicklung kontextstabiler Agenten
  • Bei Prompts mit mehr als 200.000 Token steigen die API-Preise, Kosten lassen sich jedoch durch Prompt Caching und Batch-Verarbeitung senken
  • Die Bestandskunden Bolt.new und iGent AI haben mit dieser Funktion Produktivität und AI-Fähigkeiten deutlich verbessert
  • Der Long-Context-Support für Sonnet 4 ist derzeit als Beta über die Anthropic API und Amazon Bedrock verfügbar und soll bald auch für Google Cloud erscheinen

Unterstützung für 1 Million Token Kontext

  • Claude Sonnet 4 über die Anthropic API unterstützt jetzt einen Kontext von bis zu 1 Million Token
  • Damit ist es möglich, in einer einzigen Anfrage kompletten Code mit mehr als 75.000 Zeilen oder mehrere Forschungsarbeiten gemeinsam zu verarbeiten
  • Die Beta-Funktion für 1 Million Token Kontext ist derzeit über die Anthropic API und Amazon Bedrock verfügbar; Vertex AI von Google Cloud soll bald folgen

Längerer Kontext, breitere Einsatzmöglichkeiten

  • Analyse großer Codebasen: Eine komplette Codebasis (inklusive Quelldateien, Tests und Dokumentation) kann auf einmal geladen werden, sodass Projektstruktur verstanden, Zusammenhänge zwischen Dateien erkannt und auf Basis des Systemdesigns Vorschläge zur Codeverbesserung gemacht werden können
  • Dokumentenübergreifende Zusammenfassung: Hunderte von Rechtsverträgen, Forschungsarbeiten oder technischen Spezifikationen lassen sich gesammelt analysieren, wobei Beziehungen zwischen den Dokumenten erhalten bleiben und umfassende Erkenntnisse gewonnen werden können
  • Kontextstabile Agenten: Auch über Hunderte Tool-Aufrufe und mehrstufige Workflows hinweg können vollständige API-Dokumentation, Tool-Definitionen und Interaktionsverläufe einbezogen werden, um dialogbasierte Agenten mit konsistentem Zustand zu entwickeln

API-Preismodell

  • Prompts mit bis zu 200.000 Token: Eingabe 3 $/1 Million Token, Ausgabe 15 $/1 Million Token
  • Prompts mit mehr als 200.000 Token: Eingabe 6 $/1 Million Token, Ausgabe 22,5 $/1 Million Token
  • Mit Prompt Caching lassen sich Latenz und Kosten reduzieren
  • In Kombination mit Batch-Verarbeitung sind beim Kontext von 1 Million Token zusätzlich bis zu 50 % Kosteneinsparung möglich

Praxisbeispiele von Kunden

  • Bolt.new

    • Bolt.new integriert Claude in eine webbasierte Entwicklungsplattform und treibt damit Innovation im Web Development voran
    • "Dank des 1-Million-Kontextfensters von Sonnet 4 können Entwickler größere Projekte mit hoher Genauigkeit bearbeiten"

  • iGent AI

    • iGent AI mit Sitz in London, Großbritannien, wandelt über den AI-Partner Maestro Gesprächsinhalte in ausführbaren Code um
    • "Mit dem Kontext von 1 Million Token in Sonnet 4 wird eine zuvor unmögliche autonome Softwareentwicklung Realität, wodurch Sessions über mehrere Tage hinweg auf realen Codebasen möglich werden"

Nutzung und Ausblick

  • Die Long-Context-Funktion wird Beta-Nutzern der Anthropic API mit Tier 4 und individuellen Preismodellen bereitgestellt und soll in den kommenden Wochen auf mehr Nutzer ausgeweitet werden
  • Sie wird auch von Amazon Bedrock unterstützt, und Support für Google Cloud Vertex AI soll bald folgen
  • Auch für andere Claude-Produktlinien ist die Einführung von Long Context geplant
  • Weitere Details finden sich in der offiziellen Dokumentation und Preisübersicht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-08-13
Hacker-News-Kommentare

  • Ich habe das Gefühl, dass für professionelle Software-Engineering-Arbeit ein LLM mit wirklich starker Fähigkeit zur Kontextwahrung dringend nötig ist. Ankündigungen, dass ein neues Modell ein bisschen besser geworden ist, sind im Arbeitsalltag nicht besonders spannend. Der Preis ist aber der wichtigste Entscheidungsfaktor. Es ist zwar gut, wenn mein Codebase vollständig ins Kontextfenster passt, aber da der Preis stark gestiegen ist, halte ich es derzeit für sinnvoller, den Kontext besser zu verwalten. Dass ich das Kontextfenster stark nutze, ist für den Anbieter profitabel, aber wie effektiv Sonnet den Fokus tatsächlich halten kann, müsste separat bewertet werden, daher ist sein realer Wert für mich schwer einzuschätzen.

    • Der Kontext liegt im Repo, und man muss akzeptieren, dass ein LLM nie immer den gesamten benötigten Kontext haben kann. Gerade große Repos passen nicht komplett auf eine Maschine. Um eine bestimmte Aufgabe abzuschließen, muss man zur Fokussierung irrelevante Informationen entfernen; wenn man alles hineingibt, leidet der Fokus eher. Früher war das Fenster zu klein, und ich finde es immer noch zu klein, aber letztlich braucht man die Fähigkeit, das Repo durch die richtigen Fragen zu verstehen.

    • Wenn man zu viel Kontext hineingibt, steigt das Risiko, dass das LLM sich selbst verwirrt. Bei langem Kontext ohne Reset verliert es leichter den Fokus.

    • Ich denke, man sollte die AI darauf trainieren, nur mit abstrahierten Informationen statt mit dem gesamten Codebase zu arbeiten. Auch Menschen arbeiten nicht mit dem gesamten Code im Kopf, also muss ein LLM das ebenfalls nicht.

    • Nachdem ich in den letzten Wochen mit Claude Code gearbeitet habe, bin ich zu dem Schluss gekommen, dass der praktische Wert agentischer AI eher negativ ist. In 6–8 Monaten werde ich es aber wohl noch einmal versuchen.

    • Ich glaube nicht, dass der Einsatzzweck einfach darin besteht, mehr Code auf einmal in den Kontext zu packen. Für manche Aufgaben gibt es zwar einen notwendigen Mindestkontext, aber ein 1M-Kontext-Modell verlangt auch neue Arten, Daten einzuspeisen. Die eigentliche Stärke dieses Modells liegt bei Deep-Dive-Problemen wie langfristiger iterativer Exploration, In-Context-Learning und Rekonstruktion. Es gibt breit angelegte Aufgaben wie API-Änderungen über 100 Dateien hinweg, aber auch tiefgehende Aufgaben, bei denen man 15 Ansätze ausprobiert, um eine Lösung zu finden. Sonnet 1M scheint besonders bei Letzterem einzigartig stark zu sein.

  • Für Nutzer, die sich wegen Claude Code und des Tokenverbrauchs Sorgen machen, wurden ein paar Tipps vorgeschlagen:

    1. Viel vom Codebase laden, indem man den für die Aufgabe nötigen Kontext einsammelt.
    2. An jedem logischen Haltepunkt zweimal Escape drücken, um zu einem Checkpoint mit vollem Kontext zurückzukehren (ohne diese Tokens erneut zu verbrauchen).
    3. Claude mitteilen, dass „der Entwickler Aufgabe X abgeschlossen hat“, das in den Kontext aufnehmen und Feedback einholen (bei Code, den angeblich jemand anders geschrieben hat, zeigt es mehr Probleme auf als beim eigenen). Wenn man mehrere Chats parallel nutzen will, kann man mit /resume denselben Thread laden und per doppeltem Escape zu einem kontextreichen Punkt zurücksetzen.

    • Ich sage Claude dann: „In einer anderen Session hast du Aufgabe X geschrieben“, und nutze diesen Kontext, um Fragen zu stellen oder Änderungen anzufordern.

    • Ich mache das auch oft, aber es funktioniert nicht immer gut. Manchmal ist es hilfreicher, Claude mit dem gesamten Gesprächskontext zu nutzen.

    • Die Wartezeit sinkt deutlich. Man muss nicht darauf warten, dass ein neues Claude den Kontext von Grund auf neu lädt.

    • Das fühlt sich ein bisschen wie Astrologie für Programmierer an, weil man sonst nicht weiß, was passiert, wenn der Agent am Codebase arbeitet.

    • Interessant ist die Frage, warum Claude mehr Probleme findet, wenn man sagt, der Code sei von einem anderen Entwickler geschrieben worden.

  • Die bisher nützlichste Anwendung in Claude Code war für mich die direkte Frage: „Gibt es Bugs im aktuellen diff?“ Dann analysiert der Chatbot die Änderungen sehr gründlich, findet subtile Bugs schnell, für die sonst viel Zeit und viele Deployments nötig wären, und listet detailliert verschiedene Punkte zur Verbesserung der Korrektheit des Codes auf.

    • Faszinierend ist, dass es genauso funktioniert, wie ich es möchte, ohne dass ich extra sagen muss, es solle „tiefer nachdenken“.

    • Aus meiner Erfahrung auch bei nicht programmatischen Aufgaben ist es nicht besonders kreativ, aber als kritischer und gründlicher Leser hervorragend.

    • Es wurde auch vorgeschlagen, diese Funktion konkret als Hook in Claude Code umzusetzen.

    • Ich werde diese Methode selbst ab morgen ausprobieren.

  • Meine bisherigen Erfahrungen mit den aktuellen Tools sind folgende:

    1. Beim Einstieg in eine neue Sprache, ein neues Framework, Utility oder ein Greenfield-Projekt sind sie sehr hilfreich. Danach frage ich mich beim Parsen des Codes zwar, ob ich dem vertrauen kann, aber weil ich zu faul bin, alles selbst zu interpretieren, glaube ich ihm oft einfach, weil es „funktioniert“.
    2. In Sprachen oder Frameworks, die ich bereits gut kenne, sinkt die Produktivität eher. Die Zeit, passenden Kontext für den Prompt zu schreiben, ist ähnlich hoch oder sogar höher als die Zeit, den Code selbst zu schreiben. In bestimmten Situationen funktioniert es zwar, aber es produziert leicht merkwürdigen Code, der irgendwie nach einem Junior wirkt. Wer wenig Erfahrung hat, bemerkt die Probleme möglicherweise nicht sofort. Ich habe es mit Typescript, Kotlin, Java und C++ für Websites, ESPHome-Komponenten, Backend-APIs, Node-Skripte und andere Umgebungen genutzt. Mein Fazit: gut für Hobbys, Skripte und Prototypen, aber für Enterprise-Code noch nicht ausreichend.

    • Bei mir war es ähnlich (Cline + Sonnet & Gemini über 1 Jahr). Dann bin ich auf Claude Code gestoßen und hatte den echten Durchbruch, nachdem ich vor allem gelernt hatte, den Kontext wirklich sauber zu verwalten. Der Schlüssel ist, AI nicht als Codegenerator, sondern als Architekt und Implementierer zu behandeln. In letzter Zeit lasse ich CC immer zuerst ein Designdokument für die geplante Aufgabe schreiben und weise es an, sich auf Code und Dokument zu beziehen. Ich prüfe das dann und stelle klar, ob die Richtung stimmt. Danach teile ich die Arbeit in Chunks und unterteile jeden Chunk weiter. Wenn die anfängliche Definition steht, lösche ich den Kontext, lasse für jeden Schritt das Dokument lesen und dann implementieren. Falls nötig, korrigiere ich die Richtung oder überarbeite das Dokument und starte nur diesen Schritt neu. Für jeden Schritt wird committet, der Kontext geleert und dann geht es zum nächsten Schritt. So kann ich Features, die früher 2–3 Tage dauerten, in weniger als einem Tag bauen. Am Ende bekomme ich validierte Dokumentation, Unit-Tests, Storybook, Accessibility (arai usw.) und allgemein gut ausgearbeitete Ergebnisse. Zum Schluss lasse ich den Code noch von einem anderen Modell reviewen. Auch wenn ich gerade noch keine überwältigende Geschwindigkeit erreiche, sehe ich das als Investition in meine Fähigkeiten für eine Zukunft mit weiter reifenden Tools.

    • Für mich fühlt sich dieses Tool ein wenig an wie das frühere rails new-Scaffolding bei Ruby on Rails. LLMs sind ideal für Bereiche, in denen sie nur die offizielle Dokumentation eines Tools gut verstehen müssen, also beim Erstellen des anfänglichen Projektgerüsts. Bei Legacy-Systemen oder Projekten mit vielen externen Anforderungen sind sie weniger nützlich. Für schnelllebige Tools wie Databricks sind sie fast wertlos. Wenn sich Namen, Syntax oder Funktionen seit den Trainingsdaten geändert haben, gibt es nur dann überhaupt eine Chance, wenn man aktuelle Dokumentation aktiv in den Prompt einbindet.

    • Mein Workflow nutzt Claude Desktop zusammen mit dem Filesystem des mcp-Servers. Ich gebe Claude die Pfade der relevanten Dateien und sage ihm, es solle die Aufgabe lösen. Claude liest und analysiert die Dateien selbst und nimmt die nötigen Änderungen oder Ergänzungen vor. Normalerweise reicht es, wenn ich ein paar Build-Fehler einkopiere, dann korrigiert es den Rest wieder. Beeindruckend ist auch, dass es neuen Code schreibt und dabei den bestehenden Codestil beibehält. Ich habe das mit Typescript und C# genutzt; nach meiner Erfahrung bleibt das Ergebnis nicht auf Hobby-Niveau.

    • Ich bin kein Programmierer, habe aber Arbeit, für die ich Python- und bash-Code brauche. Außerdem betreibe ich einige persönliche Projekte und Websites. Dank Claude Code kann ich jetzt kleine Projekte umsetzen, die früher wegen fehlender Fähigkeiten und Zeit unmöglich waren. Inzwischen kann ich sogar meine emacs-Umgebung selbst verbessern; Lisp-Funktionen erzeugt es mühelos. Für mich ist das das perfekte Tool. Es löst Dinge, bei denen ich festhing, und macht mein Leben leichter.

    • Ich habe es mit Typescript, Go, SQL und Rust verwendet. Rust war so komplex, dass alles voller Fehler war, und ich will das Projekt einfach schnell fertigbekommen (wobei das Projekt selbst ohnehin sehr schwierig ist). Go ist so simpel, dass ich damit extrem produktiv bin, etwa doppelt so schnell. Typescript ist solide für React-Komponenten und Animationen, SQL/PostgreSQL ebenso. Ich hasse das Boilerplate bei Stored Procedures, und das LLM reduziert das, was auch meinen Handgelenken zugutekommt.

  • Dass es immer mehr Optionen gibt, ist eindeutig gut, aber gleichzeitig kann die Qualität der LLM-Ergebnisse sinken, wenn man zu viel Kontext hineingibt, weil das Modell leichter zerstreut wird. Wenn Nutzer diesen Trade-off nicht verstehen und sich nur auf den Automatikmodus verlassen, mache ich mir Sorgen um die Qualität des mit Claude Code geschriebenen Codes.

    • Es wurden auch ein paar lesenswerte Links genannt

    • Bisher ist langer Kontext nicht in Claude Code integriert. Es hieß, man prüfe „Möglichkeiten, langen Kontext auch in anderen Produkten einzusetzen“. Vermutlich ist ihnen das Problem bereits bewusst und sie denken über eine Lösung nach. Es wirkt, als wollten sie erst eine Lösung liefern, bevor Nutzer in teureren Tarifen zusätzliche Kosten verursachen.

    • Jemand fragte, welche Alternativen man empfehlen würde. Man gewöhne sich zwar an Claude Code, sei aber bei Best Practices noch unsicher.

    • Das Chroma-Team untersucht dieses Problem, und es sollen demnächst quantitative Daten veröffentlicht werden.

  • Es wurde gefragt, ob Opus nicht besser sei, und erwähnt, dass man einen großen Unterschied spüre, wenn wegen erschöpfter Tokens zwangsweise auf Sonnet umgeschaltet werde. Aus Sicht von jemandem, der inzwischen Erfahrung gesammelt hat, viele Ideen besitzt, aber Mühe mit dem Coden hatte, sei seit Claude sowohl die Umsetzung von Ideen als auch Testing und Bugfixing regelrecht beflügelt.

    • Gleichzeitig besteht die Sorge, dass die eigenen Entwicklungsfähigkeiten verkümmern könnten, wenn man sich dauerhaft nur auf Claude Code verlässt.

  • Ein großes Problem von Chat-Apps (ChatGPT, Claude.ai) sind merkwürdige Effekte rund um das Kontextfenster, etwa plötzliches Abschneiden, Zusammenfassungen oder das erneute Einfügen von „Geister-Snippets“. Es wäre vermutlich angenehmer, wenn Nutzer selbst entscheiden könnten, ob sie den Kontext fortführen oder einen neuen Chat beginnen wollen, aber in der Realität geht das wegen Tarif- und Compute-Limits kaum anders. Tatsächlich kann man den vollständigen Kontext nur über Developer-Tools (Google AI Studio) oder per API umwickelte Chat-Apps zuverlässig vollständig senden. Wenn man eine eigene Chat-App baut, könnte man zum Beispiel in jede Nachricht einen Zeitstempel einfügen und das LLM anweisen, „alle 10 Minuten den Inhalt dieses Zeitraums als neue Zeile in einer Markdown-Tabelle zusammenzufassen“.

    • Statt eines Zeitrasters wurde auch vorgeschlagen, lieber „nach Nachrichten“ zu arbeiten, also etwa: „Fasse jede 10. Nachricht in blah-blah.md zusammen.“

  • Ich denke, dieser Tarif ist der erste Fall, in dem offen anerkannt wird, dass die Kosten mit steigender Tokenzahl beinahe „quadratisch“ ansteigen. Es sieht so aus, als würde ein LLM-Anbieter erstmals eine nichtlineare Preisstruktur abbilden. Das ähnelt den Inference-Scaling-Gesetzen, die wir bereits kennen.

  • Es wurde auch auf eine verwandte Diskussion hingewiesen

  • Die Funktion ist zwar cool, aber ich frage mich, wie sich die Inferenzgeschwindigkeit verbessern ließe. Mir persönlich reichen 200K Kontext, wenn dafür die Antwortgeschwindigkeit höher wäre. Ich denke, viele wären zufrieden, wenn Agenten deutlich schneller arbeiten würden, selbst bei kleinerem Kontextfenster (derzeit wartet man 2–3 Minuten pro Prompt).