Claude Haiku 5.5 kostet laut Anthropic-Listenpreis ein Zwanzigstel von Sonnet – warum Routing die Modellwahl schlägt

Die Modellwahl ist erledigt. Die Routing-Entscheidung nicht. Anthropic hat am Mittwoch, 7. Oktober 2026, Claude Haiku 5.5 vorgestellt, und wer jetzt nur auf die Preisliste schaut, hat die halbe Geschichte verstanden.

Die Kernaussage vorweg: Claude Haiku 5.5 kostet laut Anthropic-Preisliste rechnerisch ein Zwanzigstel des Sonnet-5.5-Listenpreises (bei Prompts bis 100.000 Tokens, ohne Caching) und erreicht auf Anthropics eigenem OSWorld-2.1-Benchmark (Offline-Subset) rechnerisch rund 86 Prozent des Sonnet-Werts (dm-Rechnung). Auf Terminal-Bench 4.0 sind es dagegen rechnerisch nur rund 56 Prozent des Sonnet-Werts. Genau zwischen diesen beiden Zahlen entscheidet sich, ob Ihre Agenten-Architektur rechnet oder nicht.

Heute ist Donnerstag, der 8. Oktober 2026. Die ersten Teams diskutieren vermutlich schon, ob sie „einfach alles auf Haiku“ umstellen. Machen Sie das nicht. Und bauen Sie auch nicht weiter „ein Modell für alles“ auf Sonnet, nur weil es bequem ist. Beides ist dieselbe Denkfaulheit mit unterschiedlichem Vorzeichen.

Mein Argument in einem Satz: Die Marge steckt im Routing zwischen Modellen, nicht in der Wahl des einen Modells. Ein großes Modell plant, ein kleines führt aus. Wie Sie das sauber bauen, was die Zahlen hergeben und wo sie aufhören, zeige ich Ihnen weiter unten.

Was Anthropic auf die Preisliste geschrieben hat

Beginnen wir mit den harten Daten. Anthropic beschreibt Haiku 5.5 in der Ankündigung „Introducing Claude Haiku 5.5“ als Modell für „high-volume, cost-sensitive tasks“. Es bewältige schnelle, repetitive Workloads zuverlässig, etwa Zusammenfassungen, Compactions, Datenbankabfragen und Klassifikationen. Außerdem passe es gut zu Opus 5.5 und Sonnet 5.5 als Subagent bei Coding-Arbeit. Laut Anthropic ist es das bislang schnellste Claude-Modell bei Standardgeschwindigkeit, Opus im Fast Mode ausgenommen.

Jetzt die Preise, jeweils pro 1 Million Tokens. Haiku 5.5 kostet bei Prompts bis 100.000 Tokens 0,10 $ Input und 0,50 $ Output. Über 100.000 Tokens sind es 0,50 $ und 2,50 $. Cache-Reads liegen bei 0,01 $ beziehungsweise 0,05 $, Cache-Writes bei 0,125 $ beziehungsweise 0,625 $. Sonnet 5.5 steht bei 2,00 $ Input und 10,00 $ Output, Cache-Reads 0,10 $, Cache-Writes 2,50 $. Der Vorgänger Haiku 4.5 lag bei 1,00 $ Input, 5,00 $ Output, 0,10 $ Cache-Reads und 1,25 $ Cache-Writes.

Die dm-Rechnung dazu: 0,10 $ geteilt durch 2,00 $ ergibt 1/20. 0,50 $ geteilt durch 10,00 $ ergibt ebenfalls 1/20. Haiku 5.5 kostet also ein Zwanzigstel des Sonnet-5.5-Listenpreises, und zwar bei Prompts bis 100.000 Tokens ohne Caching. Mit Caching verschiebt sich das Bild: Cache-Reads zu 0,01 $ gegen 0,10 $ ergeben 1/10. Über 100.000 Tokens stehen 0,50 $ und 2,50 $ gegen 2 $ und 10 $, also 1/4. Ich sage bewusst „Listenpreis“. Was Sie am Monatsende zahlen, hängt an Tokenmengen, Schrittzahlen und Wiederholungen. Davon steht in den Quellen nichts.

Dann die Zahl, die überall zitiert werden wird: rund 75 Prozent. Laut Anthropic kostet Haiku 5.5 im Schnitt rund 75 Prozent weniger im Betrieb – aber gegenüber dem Vorgänger Haiku 4.5, nicht gegenüber Sonnet. Das sind zwei verschiedene Vergleichsbasen. Die 1/20 ist ein Listenpreis-Verhältnis zwischen zwei aktuellen Modellen. Die 75 Prozent sind ein Betriebskostenvergleich zwischen alter und neuer Haiku-Generation. Wer beides nebeneinanderstellt, als wäre es dieselbe Kennzahl, rechnet sich etwas schön.

Zur Einordnung der 75 Prozent: Laut Fußnote liegt der Listenpreis 90 Prozent unter Haiku 4.5 bis 100.000 Tokens und 50 Prozent darüber. Der neue Tokenizer, ähnlich dem von Sonnet 5.5 und Opus 5.5, braucht etwas mehr Tokens pro Aufgabe. Das ist in die 75 Prozent bereits eingerechnet. Laut Anthropic ist Haiku 5.5 bei Aufgaben mit Prompts bis 100.000 Tokens besonders preiswert; solche Prompts machten rund 90 Prozent der Anfragen an Haiku 4.5 aus.

Auch Sonnet wurde am selben Tag billiger. Die Cache-Reads kosten seit dem 7. Oktober 0,10 $ statt 0,20 $. Laut Anthropic sinken dadurch die Kosten von Sonnet 5.5 bei den meisten agentischen Aufgaben um rund 20 Prozent. Wir bei digital-magazin.de haben am 29. September die Frage durchgespielt, ob Sonnet 5.5 wirklich günstiger ist – dort aus Dev- und Consumer-Sicht, hier geht es um Enterprise-Architektur. Das Ergebnis dieser Preisrunde: Auch das große Arbeitstier wird billiger. Am Listenpreis-Verhältnis von 1/20 für Input und Output ohne Caching ändert das nichts – die Senkung wirkt nur dort, wo Cache-Reads anfallen.

Eine Randnotiz: Anthropic hat außerdem neue monatliche API-Credits angekündigt (Max 5x 100 $, Max 20x 200 $, Team bis 500 $ pro Monat, gepoolt über alle Nutzenden). Nett, aber keine Architekturfrage.

86 und 56 Prozent des Sonnet-Werts: Beide Zahlen gehören auf den Tisch

Jetzt zu den Benchmarks. Alle folgenden Werte stammen aus Anthropics eigenen Messungen, nicht aus unabhängigen Tests. Auf OSWorld 2.1 (Offline-Subset) erreicht Haiku 5.5 72,4 Prozent, Haiku 4.5 kommt auf 15,7 Prozent, Sonnet 5.5 auf 83,9 Prozent. Auf Terminal-Bench 4.0 liegt Haiku 5.5 bei 39,2 Prozent, Haiku 4.5 bei 0,0 Prozent, Sonnet 5.5 bei 70,6 Prozent.

Die dm-Rechnung: 72,4 geteilt durch 83,9 ergibt rund 0,86. Auf OSWorld 2.1 (Offline-Subset) erreicht Haiku 5.5 also rechnerisch rund 86 Prozent des Sonnet-Werts. Und 39,2 geteilt durch 70,6 ergibt rund 0,56. Auf Terminal-Bench 4.0 sind es rechnerisch rund 56 Prozent des Sonnet-Werts. Beachten Sie die Formulierung: Das sind Anteile an einem Benchmark-Wert, keine pauschale „Leistung“. Wer daraus eine pauschale Leistungsquote macht, hat nichts verstanden.

Seien wir ehrlich: Dieselben zwei Modelle, zwei völlig verschiedene Bilder. Bei der einen Aufgabenfamilie liegt der kleine Bruder nah dran, bei der anderen klafft ein Abstand. Welche Familie ist Ihr Agent? Das entscheidet über alles Weitere.

Anthropic selbst zieht die Grenze eindeutig, hier in meiner sinngemäßen Übersetzung: Sonnet 5.5 und Opus 5.5 blieben die bessere Wahl für komplexe agentische Coding-Aufgaben, wie sie Terminal-Bench 4.0 misst. Haiku 5.5 eigne sich dagegen am besten für enger umrissene Aufgaben, die mit früheren Claude-Versionen womöglich zu teuer gewesen wären – etwa Compaction, Zusammenfassung oder Subagent-Arbeit. Der Hersteller sagt also das Gegenteil von „Haiku ersetzt Sonnet“. Lesen Sie das ruhig zweimal.

Dazu passt ein Frühtest von GitHub. Laut GitHub-Changelog ist Haiku 5.5 in Copilot allgemein verfügbar. In frühen Tests habe es bei vielen Coding-Aufgaben mit Claude Sonnet 5 gleichgezogen und dabei deutlich weniger Tokens und Schritte gebraucht. Vorsicht: Verglichen wurde mit Sonnet 5, nicht mit Sonnet 5.5, und es ist ein GitHub-eigener Frühtest. Als Hinweis taugt das, als Freibrief nicht. Abgerechnet wird bei nutzungsbasierter Abrechnung zum Listenpreis des Anbieters.

Routing schlägt Modellwahl: Planer groß, Ausführer klein

Das Muster ist nicht neu, aber jetzt wird es ökonomisch interessant. Der AWS Machine Learning Blog formuliert es so: „Opus 5.5 plans and makes the judgment calls, and Haiku 5.5 carries out well-defined tasks quickly and at scale.“ Und weiter: Weil es schnell und kosteneffizient sei, könne man viele Haiku-Subagenten parallel laufen lassen. Das ist eine Aussage eines Herstellerpartners, keine neutrale Studie. Sie beschreibt aber genau die Architektur, über die wir reden.

AWS nennt als Aufgaben für Haiku 5.5 das Routing von Anfragen, Klassifizieren, Zusammenfassen und kleine Änderungen über viele Dateien. Verfügbar ist das Modell auf Amazon Bedrock (unter anderem mit EU-Inferenzprofil) und auf Claude Platform on AWS. Für europäische Unternehmen dürfte der EU-Inferenzpfad keine Fußnote sein, sondern oft die Eintrittskarte – meine Einschätzung, keine AWS-Aussage.

Ein sehr anschauliches Routing-Bild liefert Rogo, zitiert auf der Anthropic-Seite. Alex Wang, Applied AI, sagt (meine Übersetzung): Während ein größeres Modell die Präsentation baue, gehe ein Haiku-5.5-Subagent in den 10-K-Jahresbericht und ziehe die Segmentumsatzzeile, die die Präsentation braucht. Das sei genau genug, dass man ihm dort vertraue, und schnell und billig genug, dass man es oft laufen lassen könne. Ein kuratiertes Herstellerzitat, ja. Aber es zeigt die Arbeitsteilung in einem Absatz: Das große Modell trägt die Verantwortung für das Ganze, das kleine holt die gut umrissene Zahl.

Ähnlich Cognition: Walden Yan beschreibt, dass Haiku 5.5 in Devin Fusion als „Sidekick“ mit Opus 5.5 als Lead arbeite; der FrontierCode-Score für das Gespann liege bei 66,2. Beachten Sie: Das ist der Wert des Gespanns, nicht der von Haiku allein. Hier sehen Sie den Punkt. Das Team gewinnt, nicht das Einzelmodell.

Routing hört übrigens nicht an der Modellgrenze auf. Haiku 5.5 ist der erste Haiku mit einstellbarem Effort. Laut Anthropic können Nutzende damit zwischen Kosten und Intelligenz abwägen. Das heißt: Die Entscheidung „wie viel Denkaufwand darf dieser Schritt kosten?“ beginnt schon innerhalb eines Modells. Meiner Einschätzung nach wird genau das die unterschätzte Stellschraube. Wer Effort pauschal auf Anschlag stellt, verschenkt genau diesen Hebel.

Wie sieht das konkret aus? Nehmen Sie einen Support-Agenten. Ein eingehendes Ticket wird zuerst klassifiziert: Rechnungsfrage, Störung, Kündigung. Das ist ein klar umrissener Schritt mit endlicher Auswahl, ein typischer Haiku-Job. Danach wird die bisherige Kommunikation zum Kundenkonto zusammengefasst, ebenfalls Haiku. Eine Datenbankabfrage zum Vertragsstatus, formuliert aus einem Schema, auch Haiku. Aber die Entscheidung, ob ein Sonderfall Kulanz verdient und wie die Antwort ausfallen soll? Die gehört dem Planer. Der Planer sieht die verdichteten Ergebnisse, nicht den Rohmüll.

Ein zweites Beispiel: Compaction. Lange Agentenläufe füllen ihren Kontext mit Werkzeugausgaben. Ein kleines Modell, das den Verlauf regelmäßig verdichtet, ist laut Anthropics eigener Positionierung genau dafür gedacht. Das große Modell arbeitet dann mit einem schlanken Kontext weiter. Wie das Zusammenspiel gemischter Modelle auf einer Plattform aussehen kann, haben wir bei gemischten Modell-Workflows mit SageMaker und AgentCore beschrieben.

Ich erinnere mich an ein Projekt, in dem ein Team monatelang über „das richtige Modell“ gestritten hat. Gelöst wurde der Streit nicht durch ein Benchmark-Ranking, sondern durch einen Zettel an der Wand: Welche Schritte hat unser Agent eigentlich? Die Mehrheit davon war Routine. Das war der Moment, in dem die Diskussion aufhörte, ideologisch zu sein.

Eine Million Calls: die Rechnung – und was sie nicht beweist

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptPhotorealistic photo of a long data center aisle with rows of unbranded server racks and small status lights, cool blue light, symmetrical perspective, no people, no logos, no readable text, no labels, no watermarks, 16:9

Jetzt rechnen wir. Nicht als Business Case, sondern als Größenordnung. Die Annahmen, alle offen:

• Eine Million Calls, je Call 5.000 Input- und 500 Output-Tokens.
• Alle Prompts liegen unter 100.000 Tokens.
• Kein Caching, kein Batch, Listenpreise der Claude Platform.
• Gleiche Tokenzahl für beide Modelle. Anthropic beschreibt den Tokenizer von Haiku 5.5 als ähnlich dem von Sonnet 5.5, reale Schritt- und Tokenzahlen pro Aufgabe können trotzdem abweichen.
• Keine Retries, keine Kosten für Cache-Writes, keine Infrastruktur- oder Personalkosten.

Haiku 5.5: 5 Milliarden Input-Tokens mal 0,10 $ pro Million ergeben 500 $. 500 Millionen Output-Tokens mal 0,50 $ pro Million ergeben 250 $. Zusammen 750 $.

Sonnet 5.5: 5 Milliarden mal 2,00 $ pro Million ergeben 10.000 $. 500 Millionen mal 10,00 $ pro Million ergeben 5.000 $. Zusammen 15.000 $. Die Differenz beträgt 14.250 $.

Klartext: Das Verhältnis ist exakt 1:20, weil beide Listenpreise 1:20 stehen. Die Rechnung illustriert die Größenordnung, sie beweist keine Ersparnis. Sie sagt nichts darüber, ob Haiku die Aufgabe im ersten Anlauf löst, ob es mehr Schritte braucht oder ob ein Mensch nachbessern muss. Wer aus 14.250 $ eine Einsparung ableitet, rechnet mit Zahlen, die niemand hat.

Zwei Sensitivitäten. Sind 4.000 der 5.000 Input-Tokens Cache-Reads, kostet die Million Calls bei Haiku 390 $ und bei Sonnet 7.400 $, rund 1:19. Sonnet halbiert sich dabei fast, weil ein Cache-Read dort nur ein Zwanzigstel des Input-Listenpreises kostet (Cache-Writes nicht eingerechnet). Liegen die Calls bei 120.000 Input- und 1.000 Output-Tokens und damit über der 100k-Schwelle, sind es 62.500 $ gegen 250.000 $, also 1:4. Der Faktor 20 ist kein Naturgesetz, er ist ein Sonderfall.

Und genau deshalb ist Context Engineering der zweite Hebel neben dem Routing. Wer Prompts schlank hält und Caches sinnvoll nutzt, verändert beide Spalten der Rechnung. Wie das praktisch geht, steht in unserem Stück dazu, wie Context Engineering KI-Kosten senkt.

Mythos und Realität: Was die Kundenzitate hergeben

Die Anthropic-Seite enthält eine Reihe von Kundenstimmen. Das sind kuratierte Herstellerzitate. Sie sind nicht erfunden, aber sie sind ausgesucht. Gehen wir sie durch, Mythos gegen Realität.

Mythos: „AlphaSense verarbeitet 8 Millionen Calls pro Woche, also spart das Modell Millionen.“ Realität: Daniel Campos nennt „Ask in Document“ eine ihrer großen Kostenquellen mit etwa 8 Millionen Calls pro Woche in Produktion. Bei 400 getesteten Queries sei Haiku 5.5 laut AlphaSense eine statistisch gesicherte Verbesserung gegenüber Haiku 4.5 gewesen, 0,84 gegenüber 0,76 – die Metrik wird nicht benannt. Eine Kostenangabe gibt es nicht. Tokenmengen und Modellmix sind unbekannt. Das Volumen ist ein Maßstab, kein Kostenbetrag.

Mythos: „Asana hat bewiesen, dass Haiku 5.5 alles schneller macht.“ Realität: Aaron Vinh spricht von über 30 Prozent weniger Latenz bei Task-Abschlüssen und bis zu 2,5-mal schnellerer Inferenz pro Agent-Turn – gegenüber „dem Modell, das wir heute nutzen“. Welches Modell das ist, sagt Asana nicht. Ohne Vergleichsbasis ist die Zahl eine Richtung, kein Maßstab.

Mythos: „Box und HubSpot belegen die Qualität.“ Realität: Yashodha Bhavnani berichtet von 11 Punkten mehr als Haiku 4.5 bei etwa halber Latenz, in frühen Tests. Ze’ev Klapow nennt 92,8 Prozent auf der eigenen CRM-Testsuite, gemittelt über drei Läufe. Beides sind eigene Suiten. Sie sagen Ihnen, dass es bei diesen Firmen auf deren Aufgaben funktioniert hat. Auf Ihren Aufgaben wissen Sie es erst, wenn Sie es gemessen haben.

Ich finde die Zitate trotzdem nützlich – als Hypothesenliste. Sie zeigen, wo Teams Haiku einsetzen wollen: Dokumentenfragen, Task-Abschlüsse, CRM-Aufgaben, Subagenten. Mehr nicht. Und ehrlich gesagt ist das schon eine Menge.

Wo Routing teuer wird

Jetzt die Schattenseite. Routing ist kein Gratisgeschenk. Es kostet Entwicklungszeit, Beobachtbarkeit und Disziplin. Und es wird teuer, wenn Sie das falsche Modell an die falsche Stelle setzen.

Der deutlichste Beleg steht oben: Auf Terminal-Bench 4.0 erreicht Haiku 5.5 in Anthropics eigener Messung 39,2 Prozent, Sonnet 5.5 kommt auf 70,6 Prozent. Die dm-Rechnung ergibt rund 56 Prozent des Sonnet-Werts. Anthropic sagt selbst, komplexes agentisches Coding bleibe bei Sonnet 5.5 und Opus 5.5 besser aufgehoben. Wer alles stumpf auf Haiku legt, zahlt zwar weniger pro Token, aber möglicherweise mehr pro erledigter Aufgabe. Ob das so kommt, weiß ich nicht – die Quellen nennen keine Retry-Zahlen, und ich erfinde keine. Der Punkt ist: Sie wissen es auch nicht, bevor Sie gemessen haben.

Deshalb zählt die Kennzahl Kosten pro erledigter Aufgabe. Ein Gedankenspiel: Ein Schritt kostet wenig und gelingt selten, ein anderer kostet das Zehnfache und gelingt fast immer. Welcher ist billiger? Das hängt davon ab, was ein Misserfolg nach sich zieht – Wiederholung, Eskalation, menschliche Nacharbeit. Token-Preise erzählen diese Geschichte nicht.

Der Gegenmechanismus ist eine Eskalationsregel. Sie definiert, wann ein Schritt vom kleinen zum großen Modell wandert. Typische Auslöser: eine fehlgeschlagene Validierung der Ausgabe, eine niedrige Selbstbewertung, ein Werkzeugaufruf mit unerwartetem Ergebnis, eine Aufgabe außerhalb des vorgesehenen Schemas oder einfach eine Obergrenze an Versuchen. Welche davon passt, entscheiden Ihre Daten, nicht mein Bauchgefühl. Aber ohne irgendeine davon geht Haiku nicht in Produktion.

Und der Effort-Regler? Er gehört in dieselbe Logik. Erst niedrig starten, bei Bedarf hochschalten, danach das Modell wechseln. Eine Stufenleiter statt einer Weiche.

Fünf Regeln für Entscheidende, bevor Haiku in Produktion geht

1. Zerlegen Sie Ihren Agenten in Schritte. Schreiben Sie auf, welche Schritte er hat: klassifizieren, zusammenfassen, Datenbank abfragen, Kontext verdichten, planen, Code ändern. Ordnen Sie jeden Schritt einer Schwierigkeit zu. Erst danach reden Sie über Modelle.
2. Messen Sie Kosten pro erledigter Aufgabe, nicht pro Token. Zählen Sie Versuche, Eskalationen und menschliche Nacharbeit mit. Ein günstiger Token, der drei Anläufe braucht, ist kein günstiger Token. Wie weit Nutzung und Ergebnis auseinanderliegen können, zeigt unser Stück über Usage ohne Outcome.
3. Bauen Sie die Eskalationsregel zuerst. Legen Sie fest, wann ein Haiku-Schritt zum Sonnet- oder Opus-Schritt wird, bevor der erste produktive Call läuft. Begrenzen Sie Wiederholungen. Protokollieren Sie jede Eskalation.
4. Testen Sie auf Ihren eigenen Aufgaben. Hersteller-Benchmarks und Kundenzitate sind Hypothesen. Bauen Sie eine kleine Testmenge aus echten Fällen, lassen Sie beide Modelle darüber laufen und vergleichen Sie Ergebnis, Schritte und Kosten. Wiederholen Sie das bei jedem Modellwechsel.
5. Nutzen Sie die Hebel in der richtigen Reihenfolge. Erst Prompt- und Cache-Gestaltung, dann Effort-Stufen, dann Modellrouting. Prüfen Sie dabei die 100.000-Token-Schwelle, denn dort kippt das Preisverhältnis von 1:20 auf 1:4.

Die harte Wahrheit: Die meisten Teams werden das nicht tun. Sie werden ein Modell wählen, eine Folie bauen und hoffen. Ich finde das verständlich und trotzdem falsch.

Meiner Einschätzung nach ist Haiku 5.5 weniger eine Modellnachricht als eine Architekturnachricht. Sie zwingt uns, Agenten nicht mehr als Monolith zu denken. Wir bei digital-magazin.de werden in den kommenden Wochen genau darauf schauen, welche Teams ihre Agenten-Schritte tatsächlich kennen. Wer weiß, was sein Agent tut, kann entscheiden, wer es tun darf.

Der Punkt ist: Die Modellwahl ist erledigt – es gibt ein günstiges, schnelles, kleines und ein kräftiges, teureres, großes Modell, und beide haben ihren Platz. Offen bleibt, wer in Ihrem System wann welche Arbeit bekommt. Wissen Sie das heute für jeden Schritt Ihres Agenten?