00:00:00Kein einzelnes Claude-Modell reicht allein aus. Opus besitzt die Denkfähigkeit, verbraucht aber Ihre
00:00:04Limits. Sonnet ist schnell, stößt aber bei schwierigeren Entscheidungen an Grenzen. Die Lösung ist nicht,
00:00:10sich für eines zu entscheiden. Es geht darum, alle zusammen zu nutzen. Claude Code macht das bereits.
00:00:14Es orchestriert die Modelle eigenständig. Aber Anthropic hat gerade etwas veröffentlicht, das
00:00:18nicht nur Token spart, sondern auch kleinere Modelle fast so leistungsfähig wie die großen macht.
00:00:23Wenn Sie mit Claude bauen, haben Sie das vielleicht bemerkt. Wann immer Sie Opus eine Aufgabe geben
00:00:28und es feststellt, dass nicht so viel Aufwand nötig ist, gibt es diese an Sonnet oder Haiku weiter
00:00:32und delegiert Aufgaben an kleinere Modelle, um die Token-Nutzung zu steuern. Doch es gibt ein Problem
00:00:37bei diesem Ansatz. Wie im letzten Video erwähnt, hat Anthropic die Ratenbegrenzungen gesenkt,
00:00:42sodass sich Ihr 5-Stunden-Fenster in Stoßzeiten schneller füllt. Zudem verbraucht Opus selbst bei
00:00:47einfachen Aufgaben viele Token, wodurch Ihr Kontextlimit mit Opus schneller erreicht ist.
00:00:52Anthropic hat den Spieß umgedreht und etwas namens "Advisor-Strategie" herausgebracht.
00:00:55Diese Strategie funktioniert so: Sie geben dem Sonnet-Modell die Rolle des Ausführenden
00:01:00und nutzen Opus rein als Berater, der nur konsultiert wird, wenn der Ausführende Hilfe benötigt.
00:01:05Es sind zwei Agenten beteiligt. Der Ausführende ist Ihr Hauptagent auf Sonnet; er übernimmt
00:01:10alle Tool-Aufrufe, Codeänderungen und Ausgaben. Der Berater läuft auf Opus und sein einziger
00:01:15Job ist es, den Ausführenden zu leiten, wenn dieser feststeckt. Der Berater schreibt nie Code.
00:01:20Als Anthropic diesen Ansatz testete, übertraf er Sonnet allein auf dem SWE-Bench.
00:01:25Diese Kombination übertraf Sonnet allein sowohl in der Leistung als auch bei den Kosten.
00:01:31Es kostet deutlich weniger als Opus als Hauptagent, da Opus nur aufgerufen wird,
00:01:36wenn es wirklich darauf ankommt, nicht bei jeder Iteration. Nun denken Sie vielleicht,
00:01:40dass wir bereits viele bessere Frameworks haben, warum also diesen Aufwand betreiben?
00:01:45Der Grund ist, dass die meisten Frameworks nicht auf Kosten- und Token-Effizienz ausgelegt sind.
00:01:50Obwohl sie funktionieren, versagen sie dabei, Claude länger und effizienter laufen zu lassen,
00:01:54da sie primär auf den App-Bau fokussiert sind, statt auf die Token-Optimierung.
00:01:59Mit diesem Setup können Sie eine App mit einem schwächeren Modell bauen und den
00:02:04Prozess token-effizienter gestalten. Das knüpft an das Problem mit den Limits an.
00:02:09Wir haben bereits ein Video zu Claudes Limits gemacht und geraten, auf kleinere Modelle zu wechseln.
00:02:13So hängt es zusammen: Sonnet verbraucht viel weniger Token und Aufwand als Opus
00:02:19für dieselbe Aufgabe. Opus ist sehr groß und leistungsstark und verbraucht daher viele
00:02:24Token für simple Aufgaben. Sonnet erledigt diese effizienter. Wenn man Opus nur nutzt,
00:02:30um die Lücke bei schweren Entscheidungen zu schließen, entsteht der wahre Effekt.
00:02:35Man nutzt die Power nur, wenn nötig. Das macht die Gesamtnutzung token-effizienter
00:02:40und man schafft mehr innerhalb der Limits. Wir teilen hier alles über KI-Produkte,
00:02:45also abonnieren Sie den Kanal für zukünftige Videos. Wir wollten nun testen,
00:02:50wie sich das bei einer App verhält, die bereits mit Sonnet gebaut wurde.
00:02:55In Claude Code haben wir den Advisor-Befehl mit Opus 4.6 als Berater-Modell gesetzt.
00:03:00Unser Hauptagent war der Ausführende, den ich bereits auf Sonnet eingestellt hatte.
00:03:05Die App sollte Echtzeit-Synchronisation haben. Während Verschieben und Skalieren klappte,
00:03:10funktionierte das Löschen gar nicht. Wir versuchten es mehrfach mit Sonnet allein zu debuggen,
00:03:16aber das Problem blieb bestehen. Nachdem wir Opus als Berater aktiviert hatten,
00:03:20gaben wir Claude den Prompt mit dem Problem. Da Sonnet bereits gescheitert war,
00:03:25entschied es sich diesmal, den Berater hinzuzuziehen, statt es selbst zu versuchen.
00:03:30Der Berater analysierte die bisherige Konversation. Er lieferte die exakten Änderungen
00:03:34und zeigte genau auf, wo die Sync-Logik fehlerhaft war und was restrukturiert werden musste.
00:03:40Der Ausführende nahm diesen Rat an und setzte die Korrekturen ohne Umwege um.
00:03:45Wir testeten es auf mehreren Geräten und das Problem war gelöst. Beide Seiten
00:03:50zeigten Löschungen korrekt an, selbst wenn ein Element auf der einen Seite ausgewählt war
00:03:55und auf der anderen gelöscht wurde, was vorher nicht funktionierte.
00:04:00Mit Sonnet allein hätte es viel mehr Iterationen gebraucht, da Sonnet
00:04:05ein schwächeres Modell ist und komplexe Logik kaum allein bewältigt.
00:04:09Andererseits hätte Opus allein viel mehr Token verbraucht und wäre langsamer gewesen.
00:04:15Sonnet mit Opus als Berater machte den Prozess viel effizienter.
00:04:20Insgesamt half diese Strategie, Sync-Probleme viel schneller zu beheben. Aber zuvor
00:04:25noch ein Wort von unserem Sponsor Juni von JetBrains.
00:04:30Als Entwickler kennen Sie den Kampf mit dem Kontextwechsel zwischen Terminal, IDE und CI.
00:04:36Die meisten Agenten binden Sie an eine Umgebung oder ein LLM. Juni CLI ist anders.
00:04:41Es ist ein LLM-agnostischer Coding-Agent, der überall funktioniert: Terminal, IDE, GitHub,
00:04:47CI/CD und Task-Manager. Ein Agent für alles. Delegieren Sie echte Arbeit an ihn:
00:04:54Tests schreiben, Backends bauen, Refactoring oder automatisierte Code-Reviews.
00:04:59Aktuell bietet JetBrains ein Early-Access-Programm mit 50 $ Gemini-Guthaben an,
00:05:04plus BYOK-Support für Ihr bevorzugtes Modell. Voller Zugriff auf alle Features.
00:05:10Klicken Sie auf den Link im Kommentar. Wir wollten nun testen, ob Sonnet
00:05:15den Berater auch bei großen UI-Änderungen konsultiert. Wir hatten eine App
00:05:20und wollten deren UI auf eine andere Bibliothek umstellen. Zudem wollten wir
00:05:25viele UI-Änderungen auf einmal machen, um zu sehen, wie das Zusammenspiel funktioniert.
00:05:31Zuerst analysierte es das aktuelle Layout mittels Playwright MCP. Anstatt direkt
00:05:36mit dem Code zu beginnen, konsultierte es den Berater für den besten Ansatz,
00:05:41da es eine kritische Änderung war, die die App unbrauchbar machen könnte.
00:05:46Der Berater meldete, dass die neue Bibliothek Versionskonflikte mit dem Projekt habe.
00:05:50Bevor die UI-Arbeit beginnen konnte, musste Claude dies lösen. Sonnet erledigte das,
00:05:55stellte sicher, dass die Abhängigkeiten passten, und prüfte via Playwright,
00:06:00ob die App noch fehlerfrei lief. Danach begann es mit den UI-Änderungen,
00:06:04wie vom Berater vorgeschlagen, Komponente für Komponente.
00:06:09Das neue UI war viel interaktiver und wirkte deutlich professioneller.
00:06:14Es gab noch kleine Fehler, aber die Verbesserung war klar. Doch hier zeigten sich Grenzen.
00:06:18Der gesamte Prozess dauerte etwa 31 Minuten. Opus allein wäre schneller gewesen,
00:06:23da es Aufgaben besser parallelisieren und orchestrieren kann. Sonnet arbeitete
00:06:27alles sequenziell ab, ohne die Arbeit in parallele Sub-Agenten aufzuteilen.
00:06:32Für eine einfache App sind 31 Minuten zu lang. Kleine Änderungen
00:06:37erledigt es zwar allein ohne Berater, was für Tweaks richtig ist. Aber für
00:06:43große Änderungen an der ganzen App ist Opus direkt oft besser, da es
00:06:48deutlich mehr Zeit und Mühe spart. Nun wollten wir testen, ob es ein
00:06:53neues Feature in eine bestehende Codebasis korrekt implementiert.
00:06:58Wir wollten eine neue Seite mit einer anderen Funktion hinzufügen. Wir gaben
00:07:03den Prompt und erwarteten die Nutzung des Beraters, aber Sonnet implementierte
00:07:08alles allein ohne Rücksprache. Es behandelte es als Routineaufgabe,
00:07:13was es angesichts des Umfang nicht war. Beim Testen fanden wir diverse Probleme.
00:07:17Änderungen wie Überschriften oder Farben wirkten sich auch auf Komponenten
00:07:22außerhalb des Vorschaufensters aus, was nicht passieren sollte. Zudem sollte es
00:07:27direkt synchronisieren, ohne dass wir jedes Mal "Run" drücken müssen.
00:07:31Wir gaben einen neuen Prompt und wiesen an, den Berater zur Fehlerbehebung zu nutzen.
00:07:37Daraufhin rief es den Berater-Agenten auf. Dieser analysierte die Implementierung
00:07:41und fand die Ursache: die falsche Komponentenwahl. Er erklärte, was
00:07:46geändert werden musste und warum der alte Ansatz die Probleme verursachte.
00:07:51Der Ausführende setzte dies um. Beim erneuten Testen funktionierte das Streaming.
00:07:56Änderungen waren sofort sichtbar. Das Problem mit den übergreifenden Effekten
00:08:00war ebenfalls gelöst. Manchmal klappt es wie geplant, aber oft hält der
00:08:06Ausführende Aufgaben für zu simpel und fragt den Berater nicht. Dann muss man
00:08:10selbst nachhelfen. Das Modell schätzt Komplexität oft anders ein als man selbst,
00:08:16was zu Bugs führt, die der Berater sofort erkannt hätte.
00:08:20Wenn Ihnen unser Content gefällt, drücken Sie den Hype-Button, das hilft uns sehr.
00:08:25Bei verteilten Zuständen brauchte dieser Ansatz dennoch mehrere Prompt-Runden.
00:08:30Die Strategie hilft, hat aber Grenzen, die man kennen sollte. Für einfache
00:08:35bis mittlere Apps spart die Advisor-Strategie viele Iterationen,
00:08:40die man sonst bräuchte, um Sonnet an seine Grenzen zu bringen. Wenn Sie
00:08:44gelegentlich tiefes Denken, aber meist einfache Umsetzung brauchen, ist dies
00:08:49eine gute Struktur. Sie schaffen mehr innerhalb Ihrer Token-Limits,
00:08:54ohne das Modell ständig zu gängeln oder ganz auf Opus zu setzen.
00:08:58Für komplexe Apps mit vielen Abhängigkeiten ist Opus als Hauptagent besser.
00:09:02Selbst wenn Sonnet dem Rat folgt, kann es den falschen Weg wählen,
00:09:07da ihm die Tiefe fehlt, um Folgen verschiedener Ansätze abzuwägen.
00:09:11Der Berater verkleinert die Lücke, schließt sie aber nicht ganz. In diesen Fällen
00:09:16kostet das Hin und Her mehr Zeit als Opus von Beginn an. Die Strategie ist nützlich
00:09:20bei knappen Token-Limits und wenn nicht permanent Opus-Niveau nötig ist.
00:09:25Wenn beides zutrifft, lohnt sich das Setup. Das bringt uns zum Ende.
00:09:30Wenn Sie den Kanal unterstützen möchten, nutzen Sie den Super Thanks Button.
00:09:36Wie immer danke fürs Zuschauen und bis zum nächsten Mal.
00:09:40[Segment leer - Platzhalter]
00:09:45[Segment leer - Platzhalter]
00:09:50[Segment leer - Platzhalter]
00:09:54[Segment leer - Platzhalter]
00:09:58[Segment leer - Platzhalter]
00:10:03[Segment leer - Platzhalter]
00:10:08[Segment leer - Platzhalter]
00:10:12[Segment leer - Platzhalter]